Human oversight is a design requirement, not a paragraph
Built into the loop, not bolted onto the docs — the override is a typed, recorded thing.
Human oversight is the obligation everyone quotes and almost no one builds. The EU AI Act asks for it; SR 11-7 gestures at it; the NIST AI RMF documents it. None of them tell you that oversight is a thing the system has to do, not a thing the policy mentions.
The mistake is to treat oversight as a sentence in the model card: "a human reviews flagged outputs." A sentence is not oversight. Oversight is a mechanism the system carries: a typed override, recorded in the chain, attributable to a person, replayable alongside the output it corrected. Without the mechanism, the sentence is decoration; with it, the sentence is a claim the manifest backs.
What oversight actually is
An override is first-class data in DEINO — an AxisOverride, a typed, recorded value, not a comment in a Slack thread. The reviewer exists; the override exists; the timestamp exists; the chain links them. The reviewer is not a role described in a doc; they are an identity bound to a hash that the manifest carries. When an examiner asks "who changed this and when," the answer is a field, not a reconstruction.
The three tiers read oversight differently
The force behind the requirement matters. Under the EU AI Act, human oversight is binding law for high-risk systems — Article 14 obliges it, and it is not optional. Under SR 11-7, oversight is supervisory guidance — model risk management expects it, but it reads as expectation, not statute. Under the NIST AI RMF, oversight is voluntary documentation — useful, and useful precisely because it is not oversold as law. A defensible posture names the tier behind each line; lumping them reads as someone who does not know which one applies.
A sentence in a model card is not oversight. Oversight is a mechanism the system carries — typed, recorded, replayable.
Built into the loop, not bolted onto the docs
The reason oversight has to be in the loop is that a bolted-on oversight process decays. The reviewer signs off in a spreadsheet that lives elsewhere; the model gets swapped; the spreadsheet stays; the link rots; six months later the examiner asks and nobody can find it. An AxisOverride sealed in the hash chain does not rot — it is part of the same record as the output, and the chain verifies it the same way it verifies everything else. Oversight that survives an audit window is oversight that is part of the substrate.
- AxisOverride is a typed value: who, what, when, against which output — sealed in the chain, not reconstructed from memory.
- EU AI Act Art. 14 = binding law; SR 11-7 = supervisory guidance; NIST AI RMF = voluntary. Name the tier; do not lump.
- Bolted-on oversight decays; in-loop oversight survives the audit window because the chain carries it.
- The reviewer is an identity bound to a hash, not a role described in a document.
What oversight does not get you
Oversight does not get you accuracy. The override records that a person corrected the output; it does not record that the correction was right. Calibration of the underlying forecast is a separate, gated loop — shadow runs against a realized timeline, scored with Brier and log-loss via deino-eval, with Gate 1b requiring a beat on a disclosed baseline before any forecast side is positioned as accurate. Oversight and calibration are different obligations; the manifest answers the first, the loop earns the second. We are pre-revenue, building the POC; the override field exists, and the calibration loop is inert until it is filled.
Oversight is not a paragraph that says a human was there. It is a field that proves it — and the field is what an examiner reads, because the paragraph is what everyone writes.
— compliance design note