The decision engine overwrites itself. That is why the log exists.

The mechanism

A live cockpit is a function of its inputs, and functions have no history.

The decision engine is built as a calculation surface: gate state, daily expectancy, four weekly structural reads, override cap and throughput mode go in, and a final tier, pool, per-trade average and directive come out. Every one of those outputs is a formula evaluated against the current contents of the input cells. Nothing is stored. The moment a weekly status is updated for the new week, every downstream output recalculates, and the previous cycle's tier, pool, overlay caps and directive cease to exist anywhere in the workbook. This is correct behaviour for a live surface — the whole point is that it always shows the current authorisation — and it means the surface is structurally incapable of answering what it said last Tuesday.

The consequence

An unlogged cycle is unauditable, permanently and immediately.

Most record-keeping failures are recoverable with effort — the information exists somewhere and can be reconstructed from adjacent sources. This one is not. The tier that was authorised for a given cycle is not derivable from the trades that were taken, because the operator may have deployed less than authorised, or used a throughput override, or been capped by an overlay that has since relaxed. It is not derivable from the current engine state, because the inputs have moved. It is not derivable from the journal, which records what happened rather than what was permitted. If the log entry was not made at the time, the question of what the system authorised for that cycle has no answer, and the doctrine states this plainly: without the snapshot, decisions cannot later be audited for coherence.

What the snapshot has to contain

The record captures the inputs, not only the verdict.

Because the point is reconstruction rather than record-keeping, the log stores the engine's view as well as its output. Identity fields fix the cycle in time. Input fields preserve the gate and the structural statuses — what the engine saw. Core outputs preserve the tier, pool and per-trade average — what was authorised. Overlay fields preserve the composite and diagnostic caps and the final structural cap, which is what shows whether the cycle was capped, suppressed or promoted. Exposure fields preserve open carryover, active open risk, remaining capacity and effective fresh deployment. The asymmetry is deliberate: storing only the tier would record the conclusion and discard the reasoning, and the question that gets asked in review is almost never what was decided but whether the decision was coherent given what was known.

Why not just trust the engine

The live surface will confidently answer a question about the past, incorrectly.

There is a specific failure mode worth naming, because it is the natural thing to do when the log is missing. An operator wanting to know what was authorised three weeks ago opens the engine and reads the tier. The engine renders a tier — it always does — computed from the current inputs, and nothing about the display indicates that it is a statement about now rather than then. The reading is not marked as stale because there is no notion of staleness on a surface with one state. This is the same hazard the contradiction engine addresses by pairing selected week with latest available week, and the throttle handles it differently: rather than making the currency visible, it moves the historical question entirely into the log, so the engine is never the right place to ask it.

The timing

The capture point is after the cycle and before the next setup.

The workflow places logging in the after-the-cycle block, ahead of updating the console with results and reviewing the dashboard, and the placement matters because the window is genuinely bounded. Once weekly setup begins for the following cycle — reviewing structural outputs, translating them into status selections, updating the engine's input block — the previous state is destroyed. The log entry has to exist before that happens. In practice this makes logging the closing act of a cycle rather than an administrative task to be caught up on later, and catching up is not available: a week of unlogged cycles cannot be reconstructed from memory with any accuracy, because the fields being recorded are precisely the ones an operator does not naturally retain.

• The engine holds one state and destroys it on the next input update.
• Authorisation is not recoverable from the journal, the account, or the current engine.
• Log after the cycle and before the next setup — the window closes, it does not reopen.

The key idea

Live surfaces and records are different objects and should not be asked to be one.

There is a recurring temptation in workbook design to make the working surface also the archive, on the reasonable grounds that duplicating information invites divergence. The throttle resolves it the other way and is right to: the engine is optimised to be correct about now, and correctness about now is achieved by recalculating, which is exactly the property that destroys history. Separating the two means each can do its job without compromise — the engine always shows the current authorisation, and the log always shows what was authorised then. The cost is one deliberate act at the end of every cycle, and the thing it buys is the ability to ask whether the system has been governing well rather than merely whether the account is up.