A renamed dropdown entry can silently disconnect the engine from its own doctrine.

The dependency

Gate names and tier names are identifiers wearing the costume of prose.

The engine resolves a gate state into a maximum tier cap by matching the selected label against the configuration table, and it resolves a tier into a cycle pool percentage the same way. Those matches are exact-string comparisons, so the readable words in a dropdown are simultaneously the human-facing name and the machine-facing key. Change Deep-Floor to Deep Floor, or add a trailing space, and the selection no longer matches its row. What follows depends on how the lookup was written: it may return an error, or it may return the wrong row, or it may fall through to a default that happens to be permissive. Only the first of those announces itself. The other two produce a complete, plausible, fully formatted deployment directive computed against a capital state the account is not in.

The second failure

A pool percentage that stopped pulling from the budget panel looks identical to one that didn't.

The integrity checks name a companion defect: confirm that cycle pool formulas pull from the pool budget panel rather than from broken or deleted ranges. This is the ordinary consequence of editing a spreadsheet over time — a row inserted here, a range extended there — and it is dangerous for the same reason as label drift. The output cell still contains a number, the number still carries a percent sign, and the tier name beside it is still correct, because tier naming and pool lookup are separate formulas that can fail independently. An operator reading the directive sees an authorised tier and an authorised pool that agree in appearance and no longer agree in derivation. Nothing in the deployment decision that follows can detect it, because every downstream step is correctly computing from the value it was handed.

The third and fourth

Two checks that guard specific doctrines rather than specific cells.

The remaining integrity checks are narrower and each protects a rule rather than a formula. The first is that smart exposure calculations reduce remaining capacity using active open risk rather than floating profit — wiring the wrong one produces a panel that treats an unrealised gain as though it had freed capacity, which is the exact confusion the open-trade doctrine exists to prevent, reintroduced at the level of a cell reference. The second is that the full-tier throughput override raises a warning when total active risk after new trades would exceed the authorised pool. That check is what makes the override an exception rather than a silent path: the mode is permitted to exceed the pool, and it is not permitted to do so quietly. A workbook that has lost the warning still permits the override and has stopped announcing it.

The honest gap

The gate selection is a manual link in an otherwise wired chain.

One further point belongs here because it is disclosed in the manual rather than discovered later. In this build the gate state is a selected input in the decision engine, and operationally that selection should come from the account's equity peak and current drawdown band — calculated externally, or added as a dedicated block in a future build. So the single highest-authority input in the stack currently arrives by hand. That does not weaken the doctrine, and it does relocate the risk: the gate cannot be wrong through a formula error because there is no formula, and it can be wrong through a stale selection, which no integrity check catches. Until the link is wired, the gate belongs on the same footing as any typed field — confirmed against the drawdown reading at the start of every weekly setup, not carried forward because it was right last week.

When to run them

The checks belong after edits, not on a schedule.

These are not periodic maintenance. Every defect described here is introduced by a change — a renamed label, an inserted row, a repaired formula, a version upgrade — and none of them appear spontaneously. The efficient discipline is therefore to attach the checks to the act that causes them rather than to a calendar: after any edit to the configuration tab, after any structural change to the workbook, and after loading a new version. The manual's instruction to read the orientation tab first after any major version change is the same discipline stated for the same reason. Running the four checks costs a couple of minutes and confirms that the readable surface and the underlying wiring still agree, which is the one property no amount of reading the output can establish.

• Labels are join keys; a rename is a logic change with no error message.
• Tier name and pool percentage fail independently and still look consistent.
• Run the checks after edits and version changes, not on a schedule.

The key idea

The most dangerous defects are the ones that keep producing output.

A governance system fails loudly when it refuses to run and quietly when it runs on a broken connection, and only the second kind survives long enough to matter. Everything in this brief describes the second kind: a directive that renders, formats and reads exactly as it should while resting on a lookup that stopped matching or a range that stopped existing. The defence is not vigilance while reading the output, because the output is by construction indistinguishable. It is a short list of checks aimed at the wiring itself, run whenever the wiring was touched.