The log stores what the system allowed and what the operator actually did.

Two facts, not one

Authorisation and execution are independent and both are worth keeping.

A cycle produces two distinct facts about deployment. The first is what the system authorised: a tier, a pool, a per-trade average, and after the exposure chain, a smart-suggested fresh trade count and per-trade risk. The second is what the operator actually deployed. These can differ for legitimate reasons — a throughput override was selected, or fewer setups met the plan's criteria, or the operator imposed a manual cap. They can also differ for illegitimate ones. Storing only the authorisation records the system's behaviour; storing only the execution records the operator's; storing both, side by side, is what allows the relationship between them to become a subject. The log field that makes override use visible is precisely a smart-suggested-versus-effective pairing.

The direction of the gap

Deploying less than authorised and more than authorised are opposite findings.

A gap has a sign and the sign carries most of the information. Effective deployment below the suggestion means the operator declined available capacity, which is nearly always benign — fewer setups qualified, or a manual cap was in force, or judgement said the conditions were poor. It costs forgone upside and breaches nothing. Effective deployment above the suggestion means the exposure chain's answer was overridden, which is the sanctioned exception path and carries the requirement of a written justification. Reading the two directions as one quantity called compliance loses this entirely. An operator whose deployment is consistently under the suggestion is running a more conservative system than the one on paper; an operator consistently over it has stopped running the governed system at all. Neither is visible from a single cycle.

What it makes measurable

Directive compliance becomes a rate rather than a recollection.

With both values stored across many cycles, questions that would otherwise be answered from memory acquire arithmetic answers. How often does the effective decision match the suggestion? When it does not, which way does it go? Is the divergence concentrated in particular gate states, or after particular kinds of cycle? The dashboard reads exactly this material as signal agreement and deployment behaviour, and its stated review use is detecting overuse or underuse of risk tiers — both directions, named as separate concerns. None of it is available without the pairing. An operator asked to estimate their own compliance rate will produce a number, and the number will be shaped by which cycles were memorable rather than by which were representative.

The clustering question

Where the divergences fall matters more than how many there are.

A count of departures is the least interesting statistic the pairing supports. What matters is their distribution against context, because a cluster is a signature and an isolated instance is a decision. Overrides concentrated after winning streaks describe confidence tracking recent outcomes. Departures concentrated under compressed gates describe an operator resisting the governance layer at exactly the point it is doing its job. Departures spread evenly with no contextual pattern are most likely what they claim to be — a series of independent judgements about individual cycles. The log stores the gate and the structural statuses alongside the deployment fields specifically so the context is attached, which is what converts a list of departures into an answerable question about when they happen.

Why it must be stored, not derived

The suggestion cannot be reconstructed afterwards.

It is tempting to think the authorised figure could be recomputed later from the inputs, making the second column redundant. It cannot, for the same reason the engine has no memory: the smart suggestion is a function of the tier, the pool and the open exposure at that moment, and open exposure in particular is a transient quantity that no longer exists once the positions have closed. There is no record anywhere else of what active open risk stood at when the cycle was authorised. The executed side survives in the journal and the account; the authorised side survives only in the log. That asymmetry is why the pairing has to be captured at the time rather than assembled during review, and why an incomplete log degrades in a specific direction — leaving the operator's behaviour visible and the system's authorisation invisible.

• Under the suggestion is forgone upside; over it is an override. Opposite findings.
• Compliance is a rate computed from two stored columns, not a remembered impression.
• The executed side survives elsewhere; the authorised side exists only in the log.

The key idea

A governance system that does not measure its own adherence is a suggestion.

Every rule in the panel is enforced by arithmetic right up to the point where the directive leaves the workbook and a person decides whether to follow it. That last step is not enforceable and should not be — the operator has to retain the ability to deploy less, and the exception layer exists so that deploying more is possible but expensive. What can be done is to measure it. Storing authorisation and execution as two facts means the final unenforceable step is nonetheless observed, and observation is what keeps an unenforceable step from quietly becoming an unconstrained one.