Human oversight documentation is the auditable record proving that real, identifiable people reviewed and shaped a model during training, and as recursive self-improvement moves up the regulatory agenda it is shifting from internal good practice toward a likely compliance requirement. What an auditor adds to the picture is provenance. It is no longer enough to assert that humans were in the loop. You have to show which humans, that they were distinct real people rather than sybils or one-shot contractors, that their judgement held up over time, and that every contribution they made is attributable, timestamped and tamper-evident. That is a different and harder thing than having had good intentions about oversight, and most training pipelines are not built to produce it.

We closed last week on a question and this week opens by taking it seriously. The regulatory ground is already moving. The EU AI Act requires human oversight for high-risk AI systems under Article 14, and a leading safety-focused lab spent recent weeks arguing publicly for caution over systems that might begin to improve themselves without a human in the loop. Put those two together and the live question is no longer whether humans should oversee frontier training. It is whether labs will soon have to evidence that they did, to someone whose job is to disbelieve them until shown otherwise.

From “we had humans in the loop” to “prove it”

There is a quiet but enormous distance between those two sentences. The first is a description of a process. The second is a demand for evidence, and evidence has properties that good intentions do not. It has to point at specific people. It has to survive the claim that those people were not who the lab says they were, or were the same handful of contractors wearing different names, or drifted in their judgement halfway through the project and nobody noticed. An auditor is not satisfied by a methodology section. They want the underlying record, and they want to be able to test it.

Most teams cannot produce that record today, not because they were careless but because the tools they used were never designed to leave one. Crowd platforms issue worker IDs that mean nothing outside the platform and vanish when the contract ends. Internal review is logged, if at all, in systems that the reviewing team controls and can therefore edit. Consistency is measured at onboarding and rarely tracked after. None of this is dishonest. It simply is not provenance, and the gap only becomes visible the moment a third party asks to see the proof.

Attestation is a claim; provenance is a record

The cleanest way to see the problem is to separate two things that usually get bundled together. Attestation is a lab saying, in effect, trust us, qualified humans reviewed this. Provenance is a record that lets someone who does not trust the lab check the claim for themselves. Attestation scales beautifully and proves nothing. Provenance is harder to produce and is the only thing an auditor can actually act on.

This distinction is not new to anyone who works in regulated industries. A pharmaceutical company cannot tell an inspector that its batch records are fine and expect that to end the conversation. The records have to exist, be attributable to named, qualified individuals, be timestamped, and be tamper-evident, so that the inspector can reconstruct what happened without taking the company’s word for it. Frontier AI training is drifting toward the same standard for the same reason: the stakes have risen far enough that self-attestation is no longer considered adequate. The interesting part is that the AI field already has the primitives to produce real provenance. They are just not yet wired into the evaluation pipeline.

What an auditor would actually ask for

Strip the compliance language away and an audit of human oversight reduces to a short list of questions about the people who did the overseeing. Each one is answerable today with a credential rather than a promise.

1. Which humans, specifically? Not a head-count, named and persistent identities you can point to across the whole project. A Decentralized Identifier gives each evaluator a stable identifier they control and no platform owns, so the record survives the contract.
2. Were they distinct real people? Anti-sybil proof of personhood is what stops a pool of fifty reviewers turning out to be five operators behind fifty accounts. Without it, the oversight head-count is theatre.
3. Was their judgement consistent? A longitudinal consistency record, carried by the evaluator rather than locked in the lab’s database, shows whether the same person reached the same judgement on equivalent cases over the life of the project, and whether drift was caught.
4. Is each judgement attributable and fixed in time? Signed, timestamped Verifiable Credentials make an individual judgement traceable to the individual who made it, and to when, so the audit trail cannot be quietly rewritten afterwards.
5. Can a compromised reviewer be flagged? A Bitstring Status List provides revocation, so if an evaluator is later found to have gamed the process their prior work can be marked rather than silently trusted.
6. Is the evidence portable, or hostage to one vendor? Records that only exist inside one platform fail the moment that platform changes terms or disappears. Portable, self-custodied credentials keep the evidence with the people and the project, not the supplier.

Read that list back and the striking thing is how little of it is speculative. Every item maps onto a primitive that the standards bodies settled years ago: Decentralized Identifiers, Verifiable Credentials with selective disclosure, anti-sybil personhood, and the Bitstring Status List for revocation. The Decentralized Identity Foundation maintains the interoperability work that keeps such credentials portable across platforms. What has been missing is not the technology but the reason to deploy it. Compliance is rapidly becoming that reason.

The substrate, reframed

For most of the past year the case for verifiable evaluator identity has been a quality argument: you get better evaluation when you can prove your evaluators are real, distinct and consistent. That argument still holds. What is changing is that the same infrastructure is starting to answer a second question from a different and less forgiving audience. A regulator does not care whether your evaluation was high quality in the abstract. They care whether you can prove who did it and stand behind the record. The remarkable thing is that the answer to both questions is the same stack.

Ontology is the substrate that produces that record, through ONT ID and ONTO Wallet. It is worth being precise about the claim. Ontology is not a compliance-as-a-service product and does not audit anyone; it provides the identity and credential primitives that let evaluators carry a portable, verifiable record of who they are and what they judged. Whether a given lab needs that record for quality, for an auditor, or for both is the lab’s call. The point of this week is that the second reason is arriving faster than most people expected, and the teams that already treated evaluator provenance as infrastructure will find they built their compliance evidence by accident. Tomorrow we take the same question into agentic systems, where the human in the loop becomes a human at specific checkpoints and documenting which ones is harder still.