Keep responsibility traceable.
Know who is responsible for an AI system, including when the work passes between companies.
Prevents Harm that falls into the gap between suppliers, with no one left to answer for it.
Proposed
What it asks
Every consequential AI system should have an identifiable organisation responsible for its operation, and a clear account of the responsibilities held by its suppliers. The person affected should have somewhere to go when something fails.
Consider a hiring service assembled from a foundation model, a candidate database, and an agent that ranks applicants. The employer controls the decision to use the ranking. The agent provider controls its workflow. The data supplier controls the information it supplies and what it says about that information. The model developer controls the underlying release and its documented limitations. Those responsibilities overlap, but they need not disappear into the overlap.
Each participant should document the decisions it controls, preserve the evidence needed to investigate failures, and identify the organisation receiving that responsibility at the next handoff. For the data supplier, this includes origin, permission to use the data, known gaps, and a process for corrections. A claim that a dataset is representative needs an explanation of whom it represents and for which purpose.
This obligation does not make every supplier responsible for every downstream act. It does require a usable record of who knew what, who could change what, and who decided to proceed. An organisation deploying a system should remain answerable for that deployment even when its investigation later identifies a supplier’s fault.
Proposed
What compliance looks like
- A named operator for every consequential system.
- Records of material decisions, data provenance and permissions.
- Documented responsibilities at every handoff between suppliers, including software dependencies, gateways, tool servers and research contributions.
Illustrative
The case that tests it
Researchers can check a result. Can they build on it?
Researchers receive a new mathematical result. They can check the proof, but struggle to understand its ideas or use them in their own work. Finding a result, checking the proof and sharing the ideas are three different contributions. What should the team claiming the breakthrough help others learn, and who gets credit for which part?
What should accompany the result?
Checking that a proof follows its rules is not the same as explaining why it works. This comparison asks how a team should share its work; it does not certify any particular proof.
Understanding is not a requirement that every reader personally reconstruct every proof. The practical question is whether a community has the materials, expertise and support to inspect and develop it. These are proposed responsibilities, not a certification of scientific merit.
Our inferenceAn accountable research claim should include a plan for explanation, scrutiny and continued stewardship, with a record of who contributed what.
Reported
What the case draws on
Provider account
A claimed solution.
- Reported
- 8 September 2026
OpenAI published a claimed Navier-Stokes solution with a Lean formalization. Publishing a formalization is not the same as this site independently checking the theorem, its assumptions, or its correspondence to the prize problem.
The company also discusses concurrent work and possible indirect contributions from de-identified product-use data. Its account does not establish improper use of another researcher’s work. Correctness, provenance, permission and credit remain distinct questions.
Researcher’s post
Understanding is the purpose.
- Reported
- 7 September 2026
In a post on related Alpöge and Buckmaster work, Terence Tao emphasises developing mathematical understanding and insight, describing problem-solving as a proxy for that goal. He highlights the effort to make AI-assisted arguments readable.
That post predates OpenAI’s announcement. It is not a verdict on OpenAI’s proof.
Reported
On the record
- Records disclosure announced
- Patients’ reports
Patients wait in pain for approval.
After suing for records, EFF reported that clinicians described patients waiting in pain and cancelled procedures in Medicare’s AI-assisted WISeR authorization program.
September 8 dates EFF’s disclosure announcement; the patient reports are from March 2026. These are clinicians’ accounts, not individual court findings. CMS requires clinical review of denials; delays span the whole process, not just an AI model.
- Research announcement
A proof offered for scrutiny.
OpenAI announced a claimed solution to the Navier-Stokes problem and released a written proof and Lean formalization.
This is the developer’s claim, not a statement of independent mathematical acceptance. A September 10 update addresses provenance; attribution and verification remain separate questions.
Proposed
Where it can fail
- Records become paperwork if no one has the authority or resources to investigate and repair harm.
- Supply chains are too complex to trace.
- The obligation asks for a usable record of who knew what, who could change what, and who decided to proceed, not for every supplier to answer for every downstream act.
- Responsibility will just be pushed onto the smallest supplier.
- The organisation deploying a system stays answerable for that deployment, even when its investigation later finds a supplier at fault.