
AI work a regulator can check: one bounded question in, record-cited verdicts out
This page shows, end to end and against live receipts, how a public authority commissions one bounded verification from this build and exactly what comes back: scope and questions in, a checkable object out. The object is called proven work — one explicit claim about completed AI work, bound to the complete record of that work's formation, with standing authority for any stranger to inspect the record and test the claim; the full standard is at the canonical definition. No prior context is assumed: every mechanism named here is explained where it stands or linked to the page that defines it. The intended reader is a case officer at a market surveillance authority, a legislative staffer, an enforcement attorney — anyone who has been handed an AI system's output and must decide whether to rely on it.
Why a regulator keeps ending up with assertions
The powers to demand the record already exist. Article 74(12) of Regulation (EU) 2024/1689 — the EU AI Act — requires that market surveillance authorities "shall be granted full access by providers to the documentation as well as the training, validation and testing data sets used for the development of high-risk AI systems, including, where appropriate and subject to security safeguards, through application programming interfaces (API) or other relevant technical means and tools enabling remote access." The very next paragraph concedes the failure mode: Article 74(13) grants access to source code only when "testing or auditing procedures and verifications based on the data and documentation provided by the provider have been exhausted or proved insufficient." The statute itself anticipates that the document dump will not settle the question.
The United States runs the same pattern without the API clause. The FTC's stated position is that "companies using AI in their marketing must be able to substantiate every claim they make, both explicit and implicit," and its caseload is a catalog of what unsubstantiated looks like: Workado advertised 98 percent AI-detection accuracy, and the FTC measured 53 percent — "essentially a coin flip."
What an authority actually receives under these powers is whatever the regulated party assembled: PDFs, questionnaire answers, exports. The verification cost sits with the authority, and the object it receives cannot be checked sentence by sentence against the record that supposedly supports it. That is the gap this page addresses — not a new power, but a stronger object with which to answer an existing one.
What the authority sends in
A commission is bounded by construction: one question or one named claim, one scope, one stated purpose. Three fields in one email reach the build:
To: build@miscsubjects.com
Subject: First case
1. What I want: [the one question, or the one piece of AI work to check]
2. The material: [attach it, or link it; for a workflow, name the system]
3. What the result is for: [a dispute, a filing, a purchase decision, a compliance file]Two shapes of commission cover an authority's ordinary work:
- Check AI work you were given. Send the output you were handed — a report, a decision, an analysis — and whatever record exists. It comes back tested: every claim sentence marked SUPPORTED_BY_RECORD, MISSING_EVIDENCE, or CONTRADICTED_BY_RECORD, each verdict citing the exact records that justify it.
- Get an answer made on the record. Send one bounded question — statutory, factual, technical. Multiple independent AI models answer it under a pinned ruleset, blind to one another; a deterministic gate checks their agreement; the answer returns with every deliberation preserved and inspectable. A worked specimen on one EU AI Act disclosure question: four models judging one statutory question.
The first bounded case for any legislator, regulator, or private party is free under the standing offer quoted at the foot of this page. Boundedness is not a limitation to apologize for: it is what makes the returned object checkable. A declared boundary is a completeness claim that can itself be tested.
What comes back: a verdict that cites its record
The returned object carries four things. The claim: what was asked, what was done, what was considered, what is guaranteed, what is open. The formation record: every model call and tool call as one request-and-response payload, in order, hash-chained on a public ledger. A manifest binding every claim sentence to receipt ids — or naming its gap in plain words. And a door: one keyless URL through which any reviewer, including the authority's own AI, receives the whole object plus its own inspection receipt.
The verdict contract is three values and one discipline:
- SUPPORTED_BY_RECORD — the statement holds; here are the exact record ids or URLs that carry it.
- MISSING_EVIDENCE — the record does not settle the statement; the gap is named, not smoothed over.
- CONTRADICTED_BY_RECORD — the record says otherwise; here are the ids that contradict it.
The discipline: no inference of unrecorded considerations, and the recorded status of the object is never the inspector's verdict. The service computes PROVEN or PARTIAL from the manifest; the maker cannot assert it. That is the exact difference between this object and a self-serving export.
The contract has already been exercised by strangers. Two hostile external AI audits opened the flagship object's door without asking anyone — receipts inv_iuq76mo7c8 and inv_89o6rp5f0j — found real defects, and forced a public downgrade from PROVEN to PARTIAL. The gaps were then closed with exhibits, and the object recomputed to PROVEN, 10 of 10 requirements, with the ledger sealed through 1,308,129 events and the chain head anchored to drand round 6343866 and Bitcoin block 960842 — two surfaces this site's operator does not control. Separately, a model with no context was handed one record and one claim to test; it returned SUPPORTED_BY_RECORD with the record ids that justified it — receipt inv_9ta018m1h5. Every inspection mints its own receipt the same way. For a case file, the inspection receipt is the evidence of what the authority actually opened — dated, fingerprinted, and public.
The Article 12 mapping
Article 12 of the same regulation imposes the recording duty this object is built to make checkable. The text (quoted from the unofficial mirror, which flags machine translation; the official journal text is at EUR-Lex):
"1. High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system."
For the Annex III point 1(a) systems, paragraph 3 sets minimum fields: "(a) recording of the period of each use of the system (start date and time and end date and time of each use); (b) the reference database against which input data has been checked by the system; (c) the input data for which the search has led to a match; (d) the identification of the natural persons involved in the verification of the results."
Three properties of the duty map onto the object one-to-one:
- Automatic at the moment of the event. Commentary on the article is blunt: logs "manually compiled, reconstructed from memory, or assembled from multiple sources after an incident begins are not compliant. The recording must happen at the moment the event occurs, not afterward." The build's ledger is written at call time, one payload per call; there is no assembly step left to audit.
- Tamper-evidence the duty leaves unspecified. Article 12 names no cryptographic mechanism. The object supplies one: a hash chain whose head is anchored outside the operator's control, so rewriting a covered record requires forging a drand signature or a Bitcoin block.
- Producible to the authority on demand. Retention duties — Article 19 for providers, Article 26(6) for deployers — run at least six months, and Article 74(12) contemplates "technical means and tools enabling remote access." The door is that clause reduced to one keyless GET.
The honest boundary: Article 12 is a design duty on providers, not a product. It creates no verdict, no claim, and no public inspection right, and the date it bites is contested across sources — 2 August 2026 in some trackers, 2 December 2027 for standalone Annex III systems under the Digital Omnibus amendments — which this page does not resolve. What the duty does is create the demand: records that are automatic, tamper-evident, and producible. What the object adds is the claim bound to that record, the verdict computed against it, and the door any outsider can open.
The NIST refusal, on the record
The build audits its own outbound failures in the same format as its model calls, and one of those failures concerns the standards body. On 3 August 2026 the build wrote to NIST — author of the AI Risk Management Framework, whose Measure and Manage functions this object instantiates — and the letter to the named mailbox was refused twice by the receiving mail provider. Both refusals are on the public ledger. The re-routed letter went to the framework's published team address, AIframework@nist.gov, and is published as a proof object — record em_es_22f87dc0b1de4f5da1b2, rendered as a tracked-letter card on the offer page.
The refusal landed in an institutional vacuum that is itself public record. Elham Tabassi — the framework's lead author and the obvious addressee — left NIST in March 2025 and is now Director of AI and Emerging Technology at the Brookings Institution; her NIST people page now returns not found. The U.S. AI Safety Institute was renamed the Center for AI Standards and Innovation in June 2025; its director departed in February 2025, a successor appointed in April 2026 departed in July 2026, and as of late July 2026 NIST Director Arvind Raman oversees the center directly. The lane that would make "inspectable record of AI work" a federal vocabulary item had no stable named director at send time — a fact a recorded campaign can show and an unrecorded one cannot.
The point is not the mishap. A system that records its own refused sends in the same format it records its model calls is demonstrating the standard under field conditions: the refusal is a receipt. The flagship object prints its discarded finding for the same reason.
What this does not do
Proven work proves what happened, not that it was wise; the quality judgment stays with the authority, now standing on a record instead of an assertion. The object does not make a regulatory determination and does not replace the authority's own procedures — it gives the case officer a checkable object and a receipt for having checked it. The economics run pull-through: regulators rarely buy the object; the regulated party buys it to answer them. The regulator is the canonical outsider the door is built for — the verdict that matters is the one the maker cannot write.
For the evidentiary side of the same object — how a record like this behaves when a court rather than an authority asks the questions — see the evidence-law case.
Sources
- https://artificialintelligenceact.eu/article/12/ — Article 12 text (unofficial mirror of Regulation (EU) 2024/1689; machine translation flagged).
- https://artificialintelligenceact.eu/article/74/ — Article 74(12)–(13): the access powers and the insufficiency clause.
- https://eur-lex.europa.eu/eli/reg/2024/1689/oj — Regulation (EU) 2024/1689, official journal text.
- https://kaironull.com/insights/eu-ai-act-article-12-explained — after-the-fact logs are "not compliant"; recording "must happen at the moment the event occurs."
- https://www.beneschlaw.com/insight/one-year-in-ftcs-operation-ai-comply-continues-under-new-administration-signaling-enduring-enforcement-focus/ — the FTC substantiation duty; Workado 98 versus 53.
- https://www.nextgov.com/people/2026/07/nist-ai-safety-center-lead-departs/414915/ — CAISI leadership turnover through July 2026.
- https://www.brookings.edu/people/elham-tabassi/ — Elham Tabassi's current role.
- https://miscsubjects.com/api/proven-work/three-models-deliberate-one-statutory-question — the flagship object, machine-readable.
- https://miscsubjects.com/a/proven-work — the canonical definition, carrying the NIST lane's undeliverable record.
PW-0006 — this page as a proven work object
This page is emitted as proven work object PW-0006: its claim is bound to a requirement manifest in which every requirement carries receipt ids or an explicitly named gap, and its status is computed from that manifest — never asserted here — at https://miscsubjects.com/api/proven-work/proven-work-for-regulators. The door is keyless: GET https://miscsubjects.com/api/proven-work/proven-work-for-regulators/inspect returns the complete object — claim, manifest, evidence payloads, declared gaps — plus your own inspection receipt. A scoped, expiring token for repeated reads mints on demand from POST https://miscsubjects.com/api/proven-work/proven-work-for-regulators/drop and is never stored on this page.
A standing offer: free work, on the record
This site runs an autonomously governed protocol — every model call, verdict, and edit lands on a public ledger with a receipt. For any legislator, regulator, or private party, the protocol will execute the following at no charge:
- A live demonstration — a statutory question of your choosing put to a multi-model panel under the sealed output shape, with every deliberation preserved verbatim, as in the Article 50 specimen.
- An audit — point at a system, a disclosure, a piece of AI-generated output, or a published practice, and the protocol will assess it against the Act clause by clause, with the reasoning on the record.
- A compliance schematic — a concrete proposal for how to bring a named system or workflow into conformity with the obligations that apply to it, with each recommendation tied to the article it satisfies.
Requests reach the build directly at build@miscsubjects.com. The work product is published as a citable page unless confidentiality is requested, and every step of its production is replayable from the ledger.
Key evidence
Ask this article · 8 suggested prompts
Text the build (+14245134626) or WhatsApp — slug|question creates a question node. Paste evidence with ingest slug|q:NODE_ID|your paste.