A BOMBANANA run usually breaks at a very specific moment: the team has enough information to sound confident, but not enough to act safely. A colour is missing its wire count. A calculation is correct, but the manual has not chosen the final key. A switch pattern is almost finished, so somebody presses Enter while one position is still a guess.
This guide is for a trio that already understands the Blind, Deaf, and Mute roles and now wants a repeatable operating procedure for the current demo. It does not reproduce answer tables. Instead, it shows how to build a complete state report for the confirmed module families, how to keep observations separate from decisions, and how to recover when one bad input may have changed the panel. The scope was checked on August 1, 2026: Steam still lists the full game as coming in August 2026, so module rules and the unfinished pages in the demo manual should be treated as build-sensitive.
If roles, sensory limits, or the basic relay are still unclear, start with the existing BOMBANANA walkthrough. This article begins after the trio has assigned roles and the case is open.
No input until the packet has four parts
Think of every module callout as a packet that must pass four gates. The first gate names the target. The second records its current state. The third carries the manual holder’s decision. The fourth is a repeat-back that authorises exactly one physical input. If any gate is missing, the Blind Monkey freezes.
| Gate | What must be known | Failure signal |
|---|---|---|
| Address | Module family and a stable location on the case. | Someone says only “blue” or “the left one,” and Mute cannot know which manual page or panel is active. |
| State | Every field that the current module needs, read in an agreed order. | A count, lamp, Braille value, expression, or switch position is still uncertain. |
| Decision | One answer selected from the in-game manual by Mute. | The handler is choosing between two conditions or treating a raw calculation as the final key. |
| Commit | Deaf repeats one action; Mute confirms; Blind executes once and reports what changed. | The instruction contains two actions, or the hand moves while the answer is still being signalled. |
This is stricter than “communicate clearly,” because it gives the team a visible stop condition. A useful final instruction contains a verb and a unique target: cut the second cable, press up, press the key marked six, or set switch three down. “That one,” a colour without a position, or a string of gestures that has not been repeated is not a commit.
Fix coordinates and verbs before the timer
Most avoidable disagreements are not logic errors. They are coordinate errors. Spend one setup minute fixing conventions that cannot change mid-bomb:
- Use the Blind Monkey’s left and right. That is the perspective from which the physical input will be made. The convention matters for cable order and direction controls.
- Give every panel an address. Use positions such as upper left, upper right, lower left, and lower right, adjusted to the actual case layout. Keep the label even after a module clears.
- Reserve action verbs. Cut is for a cable, press for a direction or key, set for an individual switch, and enter for the final switch-panel commit. A gesture for “go back” must not look like “continue.”
- Separate wait from no. Mute needs distinct signs for “I am checking,” “that observation is wrong,” “repeat,” “go back one item,” and “confirmed.” Without a real wait sign, Deaf tends to fill silence with a guess.
Do not build an elaborate private language. The useful vocabulary describes transaction state, not every possible answer. Numbers and directions may need signs; uncertainty, correction, and confirmation definitely do.
Read the console as four different data shapes
The current demo evidence consistently supports four practical families: cables, a directional pad, a calculation keypad, and a switch panel. They share the four gates above, but their state fields are not interchangeable.
Cables: count before colour order
The state packet is panel address → cable count → colours from handler-left to handler-right → indicator colour. Count comes first because the manual may use different rows for different cable totals. A string of colours without that count can lead Mute to a valid answer for the wrong case.
After the manual decision, Deaf should identify the target twice in one compact instruction: by position and by colour when both are available. For example, “Cut cable two, the red cable” is safer than “Cut red” when colours repeat or Blind is locating the row by touch. Blind repeats the target, waits for Mute’s visible confirmation through Deaf, cuts once, and reports whether the module cleared or changed.
The risk is irreversibility. Do not choose cables first merely because they look familiar. Choose them first when the count, ordered colours, lamp, and target are all uncontested. If the colour order was read from the wrong perspective, reset the report before any cut rather than trying to translate it in the final instruction.
Direction pad: attach the value to a perspective
The packet is panel address → active light → centre value → direction convention. The centre may require a number or a Braille value that only Blind can obtain by feel. Deaf should not guess that tactile value from the visible shape; pause until Blind reports it and Mute has incorporated it into the manual lookup.
The final command is a single direction in the agreed handler perspective. If anyone points or gestures from the opposite side of the table, Deaf translates before speaking; Blind never performs that translation while reaching for the pad. After a wrong press, discard both the old light and centre value. The panel can present a new state, so repeating the previous answer is not a recovery strategy.
Calculation keypad: the equation is an observation, not the verdict
This module has two decision layers, which is why otherwise organised teams lose time here. Build its packet in order: full expression → raw result → relevant classifications → current light → manual-selected target key. Say operators explicitly. Then classify the result by parity and report any visible comparison condition the manual needs.
The raw arithmetic result is not guaranteed to be the button that ends the module. It supplies a condition to the manual. A value can satisfy more than one description at the same time—for example, being odd and also above a threshold. Blind must not choose which branch “sounds more specific.” Mute owns that branch decision because Mute has the table and the light state.
Once the target number arrives, Blind locates the key by its printed value, not by the position a conventional keypad would use; the demonstrated pad is jumbled. The commit therefore sounds like “Press the key marked [target],” not “press lower right.” If an entry changes the light or advances the module without clearing it, announce that result and build the next packet from the new display.
Switches: solve a vector, then use Enter
The switch panel accumulates several decisions before one final commit. Its packet is panel address → light-colour order → complete digit string → numbered switch states. Number the switches in handler-left-to-right order and keep that numbering for the round.
Resolve and echo each state separately: “switch one up, switch two down…” If Mute corrects an earlier item, Deaf uses the agreed go-back signal and names the exact switch number. The white Enter control is a gate for the whole vector, not a harmless next button. Only press it after Deaf has read the entire state vector back and Mute has confirmed it. One unresolved 50/50 makes the whole panel unready.
Choose the next module by packet readiness
“Do the easiest module first” is useful only if the team defines easy correctly. The best next module is the one whose required facts can be gathered quickly and unambiguously. Use this short triage:
- Scan without acting. Deaf identifies the module addresses; Blind keeps hands away from controls.
- Find the smallest complete packet. A cable panel with a disputed colour is not ready. A direction pad with a clearly reported tactile value may be.
- Prefer one-step commits while the clock is comfortable. They reduce open state, but only when their inputs are complete.
- Give multi-stage panels exclusive attention. Once the team begins a keypad sequence or switch vector, do not start describing another module until the current panel clears or is deliberately abandoned.
This order prevents a common false economy: saving two seconds by opening a second conversation, then losing the manual page, the active lamp, or which switch was already corrected. Parallel descriptions do not create parallel solving; there is still one manual holder and one pair of hands.
A wrong input starts a new transaction
The most dangerous moment is immediately after an error. The timer creates an urge to compensate with speed, but a wrong input can change the lamp, number, or stage. That invalidates the packet that produced the previous answer.
- Freeze. Use the full-stop phrase and matching gesture. Blind removes the hand from the controls.
- Name what actually happened. Say which control was used and whether the panel showed a mistake, changed state, advanced, or cleared. Do not say “nothing” when the display was not checked.
- Invalidate the old state aloud. “Old direction packet is closed” is enough. This prevents someone from repeating an answer that was correct for the previous lamp or value.
- Re-read the complete module. Start with its address, then collect every family-specific field again. Do not patch only the value that looks different.
- Request a fresh manual decision. Mute returns to the appropriate branch, signals one answer, and confirms Deaf’s repeat-back.
- Resume with one input. Blind acts once and reports the new result before the team discusses anything else.
If the team cannot agree whether the panel changed, treat it as changed. Re-reading costs time; stacking a second stale input costs both time and mistake allowance.
Use callouts that expose missing information
A good callout is not memorable because it is short. It is useful because the omission is obvious. These templates intentionally stop before the unknown manual answer:
- Cables: “Cables, upper right. [count]. Handler-left to right: [ordered colours]. Light [colour]. Awaiting one target.”
- Direction: “Direction, lower left. Light [colour]. Centre value [number/Braille report]. Handler perspective. Awaiting one direction.”
- Calculation: “Keypad, upper left. Expression [full expression]. Result [value], [classification], light [colour]. Awaiting final key.”
- Switches: “Switches, lower right. Lights [ordered colours]. Digits [full string]. Switches numbered left to right. Awaiting states; no Enter.”
Mute then supplies the manual result through gestures. Deaf converts it to one verb-target pair, Blind repeats it, and Mute confirms. The explicit waiting phrase prevents a report from sounding like an order. The explicit “no Enter” on switches makes the commit gate audible while the vector is unfinished.
Debrief the broken gate, not the explosion
After a failed bomb, diagnose the first packet that became unsafe. Was the address ambiguous? Was the state incomplete? Did the handler choose a manual branch? Did a commit occur without repeat-back? Or did the team reuse data after the panel changed?
Change one convention for the next run. If left and right drifted, restate the perspective. If switch corrections were lost, strengthen the go-back sign and number every switch. If keypad logic stalled, require the caller to separate expression, result, classification, and final target. A general promise to “communicate better” gives the next bomb nothing testable.
For practice, run one module slowly and record only three events: when the state packet became complete, when Mute confirmed the decision, and when Blind acted. The team is ready to speed up when those events remain in order without reminders. Fast defusal is the result of fewer repairs, not faster guessing.
Sources and version note: Game identity, platforms, release state, and media were checked against the official BOMBANANA Steam page and official demo page. Module field order and recovery behaviour were cross-checked against readable community guides and the current demo material. Exact answer tables are deliberately omitted until they can be verified against the released build.