The override is logged, not inferred

The override is where oversight becomes concrete or stays fictional. A system that "supports human oversight" in its docs but logs the override in a separate spreadsheet has an oversight process that exists only as long as the spreadsheet is found, the reviewer remembers, and the link between the spreadsheet and the output is still intact. Six months later, none of those are guaranteed. An override sealed in the hash chain is not inferred from memory; it is read from the record.

The override is first-class data

In DEINO an override is an AxisOverride — a typed, recorded value, not a comment in a thread. It carries who (an identity bound to a hash), what (the field changed and to what), when (a timestamp in the chain), and against which output. The chain links the override to the output it corrected, so the two cannot drift apart. An examiner asking "who changed this?" gets a field; an examiner asking "can I see it?" gets the same record as the output. The override is not a story told alongside the decision; it is part of the decision’s record.

Inference is the failure mode

The failure mode is not "the override was not recorded"; it is "the override was recorded somewhere that has to be inferred from." Inference is what an examiner does when the record is incomplete, and inference is where defensibility ends — because an inferred answer is a reconstructed answer, and a reconstructed answer is one a reviewer can dispute. A sealed answer is not disputed; it is read. The difference between "the log suggests the reviewer approved it" and "the chain shows the reviewer approved it" is the difference between a review that passes and one that does not.

"The log suggests the reviewer approved it" is an inference. "The chain shows the reviewer approved it" is a record. One is disputed; the other is read.

The tiers and the override

The override obligation tracks the tiers. Under the EU AI Act (binding law), human oversight for high-risk systems requires the ability to intervene, and the record of intervention is part of compliance. Under SR 11-7 (supervisory guidance), model risk management expects overrides to be logged and attributable. Under NIST AI RMF and ISO/IEC 42001 (voluntary), override documentation is governance. The binding tier requires the override to exist; the substrate makes it readable. Lumping the tiers reads as someone who does not know which one obligates the override; naming the force reads as someone who does.

• AxisOverride is a typed value: who, what, when, against which output — sealed, not inferred.
• The override is linked to the output in one chain; the two cannot drift apart.
• Inference is where defensibility ends; a sealed record is where it holds.
• Binding law requires the override; the substrate makes it readable; voluntary tiers document it.

What the logged override does not certify

The logged override certifies that a person intervened and what they changed; it does not certify that the intervention was correct. Certified ≠ True: the manifest attests provenance and reproducibility, not the truth of the override. The override could itself be wrong, and the chain would still show it — which is the point. The chain is honest about the intervention, including interventions that were mistakes; that honesty is what makes the rest of the record credible. We are pre-revenue, building the POC; the override field is part of the manifest, and calibration of the underlying forecast is a separate gated loop (Gate 1b).

An override that has to be inferred is an override that can be denied. An override sealed in the chain is an override that can only be read — and that is the only kind that survives a review.

— oversight design note