BOMBANANA! Blind Monkey Guide

Blind Monkey is the only player who can touch the bomb. Every input goes through your hands — but you cannot see colors, read screens, or track the bomb's visible state. You can hear the team and speak to them; sight is your only missing sense. This guide covers what you can verify independently, how your findings travel back to the manual, what "confirmed" requires before you act, and what to do the moment something goes wrong. It does not cover the callout format (Deaf Monkey's job) or the manual answer (Mute Monkey's job).

What Blind can feel but not see

Blind Monkey's exclusive input is tactile: what you can determine by touch alone, without any visual readout. This channel is reliable — you are the only player who can use it — but it only covers physical properties, not the meaning of what you find.

What Blind reads independently	What Blind cannot access without Deaf
Wire count and left-to-right order by feel	Wire colors — you cannot distinguish them tactilely
Braille-style dot pattern, one position at a time	Screen text, symbols, and displayed values
Button and module position by location on the panel	LED state — whether it is green, red, or off
Which module panel your hands are currently on	Mistake counter total — you have no independent readout

The mistake counter gap matters most under pressure. You have no way of knowing how many errors the team has accumulated, which means you cannot independently judge how cautious to be. Deaf Monkey holds that information; they should call it out when it changes, not only when asked.

How your findings reach the manual

Act on Deaf's instruction, not on your own interpretation. The first thing to internalize is that your tactile findings only become useful after they reach Mute Monkey's manual — which requires you to send them back out.

You speak your findings aloud. Mute Monkey hears you directly and works the manual. The full chain:

1. You touch the module and say the finding — for example: "three wires, left to right", then the colours as Deaf calls them
2. Mute hears you, looks up the manual answer, and gestures it to Deaf
3. Deaf watches the gesture and speaks the answer and the act signal aloud
4. You hear Deaf and act

If step 1 is skipped or too vague, Mute cannot look up anything — the failure players describe as "other roles guessing at the value" happens because the spoken report was missing or unclear, not because Mute is impatient. Lead every report with the module name so Mute knows which manual page to open before you describe the state.

A split worth locking in before the round: you can hear the whole team, but only Deaf can see the bomb's colours and LEDs, and only Mute holds the manual. So your spoken report supplies the tactile facts — wire count, order, dot patterns — while Deaf supplies the visual facts Mute needs. If either of you goes quiet, Mute works with half the picture.

What to lock in before the timer

These six items must be resolved before the round starts. Each one exists because Blind Monkey cannot see the bomb change under your hands — resolving a signal mismatch under timer pressure is worse than any extra thirty seconds spent now.

1. Orientation lock. Confirm that "left" and "right" always mean Blind Monkey's left and right — not Deaf's. Define "near" and "far" too: Blind's near side is the side closest to the main panel. Orientation disagreement mid-round costs a module because the same callout produces opposite actions from different reference frames.
2. Report lead-in. Agree that every tactile report opens with the module name — "wires:", "keypad:" — so Mute knows which manual page to turn to before you describe the state, instead of hunting once you have already spoken.
3. Act signal. One word Deaf says that means "input now." Not "go," not "okay," not "ready" — a single agreed term with no other use. Example: "act."
4. Stop signal. One word that freezes you immediately until Deaf explicitly clears it. Example: "hold." Without a stop signal, Deaf has no way to pause you mid-motion if the game state changes between the callout and your action.
5. Wrong signal. One word that means "wrong input just happened" — your cue to release the module and wait for the re-read sequence (see: After a wrong input).
6. Repeat signal. One short word you say to mean "say the last callout again" — example: "again" — so you can ask for a re-read without a full sentence while the timer runs.

The act-gate

Acting at the right moment is what this entire role reduces to. The challenge is not knowing what to do — Deaf tells you that — but knowing whether the chain actually completed before Deaf spoke.

Three conditions must all be true before you touch anything:

1. Deaf spoke a specific action — not a question back to Mute, not a hesitation ("it's the… hold on"), not a repeat request
2. The callout referenced the module your hands are currently on — not a module from a previous step
3. No stop signal is active — if Deaf called "hold" at any point, it stays in effect until Deaf says the act signal

The temptation that breaks this gate: Deaf says something that sounds like the answer, so you move. But Deaf might have been relaying an uncertain answer — Mute was still gesturing "repeat" when Deaf spoke, meaning the manual answer had not fully landed yet. From your side of the chain, a partial answer and a confirmed answer sound identical. The only protection is waiting for all three conditions, not just condition one.

A reasonable habit — though not an in-game rule — is to say "act?" back after condition one if you are unsure, prompting Deaf to give the explicit act signal. This adds half a second and removes the ambiguity.

Stop and confirm

Time pressure is the main reason the act-gate breaks. These four conditions require a full stop regardless of how much time remains. Stopping costs two seconds. A wrong input can reset the module state entirely and cost ten.

Condition	Why stopping is required	What to say
Deaf gave an instruction but you did not hear a clear act signal	The callout may be incomplete — Mute's gesture confirmation may not have reached Deaf yet	"hold — confirm?"
The module state changed after the last callout	The instruction no longer matches what your hands are on — acting inputs against a stale description	"hold — re-read"
Two callouts came in rapid succession	You cannot distinguish which instruction is current; acting picks one arbitrarily	"hold — which one"
Your hands are on the wrong module	The input would land on the wrong panel; confirming first prevents a mismatch	"hold — wrong module"

A stop signal does not restart the callout sequence — it pauses it. Deaf responds to any "hold" by re-confirming the act signal when ready. The temptation to skip the stop: the timer is running and stopping feels like wasting progress. Stopping on a wrong module still uses no mistakes. Acting on a wrong module does.

After a wrong input

A wrong input can change the LED state, the displayed module number, or which stage of a multi-step module is active. You cannot see any of these changes. Recovery distributes the re-read so no role waits on another:

1. Say the agreed wrong signal and release the module — do not attempt to correct immediately
2. Deaf announces "wrong" aloud so Mute hears and stops working on the current solution
3. Deaf re-reads the current module state from visual: LED color, displayed number, stage indicator — in that order — and speaks it
4. Mute re-checks the manual with the updated state and re-signals the new answer
5. Deaf speaks the new answer and the act signal; you act

Do not touch the module between steps 1 and 5. Touching the bomb while Deaf is re-reading risks a second wrong input on an already-changed module state.

Not every element changes after a wrong input. If the LED did not change and the module number did not change, step 3 only needs to cover the stage indicator. Deaf calling out only what changed — not the full module description from scratch — keeps the recovery shorter.