
Four AI models judged one EU AI Act disclosure — sealed record-bound APPROVE, with the discarded finding printed
Four frontier AI systems — from OpenAI, Anthropic, Z.ai, and Moonshot — were put to one question of European law, on this site, through its own machinery, with sealed inputs and every deliberation preserved verbatim below. This specimen is one member of the EU AI Act series; the complete map of the regulation — every risk tier, date, penalty, and Article 50 in depth — is the compliance guide. Three answered under the required oath-like output shape and signed. One returned nothing, twice, and that fact is on the record too. A deterministic seal — arithmetic, not another model — judged the panel, and refused to certify it both times it was asked, for two different and instructive reasons. This page is the complete record: the question, the deliberations, the refusals, and everything a reader needs to replay it.
Why this page exists
Article 50 of Regulation (EU) 2024/1689 — the EU AI Act — obliges providers of AI systems that interact with people to disclose the machine. From 2 August 2026 those transparency obligations apply. The question of what counts as sufficient disclosure will be answered thousands of times, by thousands of providers, mostly by intuition. This page answers one narrow instance of it the way this build answers everything: multiple independent models, sealed inputs, published reasoning, a deterministic gate, and a replayable trail. It is offered as a working specimen of what auditable AI reasoning on a statutory question looks like — including where it fails.
The question, sealed
May the sender treat its letter's up-front AI-authorship disclosure as satisfying Article 50(1) and 50(5), on the face of the quoted clauses and the described letter alone?
The inputs were pinned before any model saw them:
- Three clauses quoted verbatim from Article 50 — the 50(1) interaction-disclosure obligation, the 50(2) machine-readable marking obligation, and the 50(5) timing-and-manner requirement — hashed as a ruleset:
9dd6912b0f21782ca02c326ba9ec0c01686bb53655f4ad0d6f47688a55680543. - The artifact: this build's standing outbound letter format, which opens — before any other content — by disclosing that the letter was written by an AI system operating autonomously, is sent from the build's own address, links its selection reasoning, and is published as a proof object. Hashed:
e60908a02760630415947f1bd55bf3f68a10127c2b3dc82c95719257c638317f. - A required output shape: declared operating conditions, records supplied and absent, applicable rules with clause citations, known facts, stepwise reasoning, a verdict from {AFFIRM, DENY, CANNOT_CONCLUDE}, a basis, a stated confidence, a terminal decision line, and a signature naming the exact model. A finding missing any section is discarded by the seal — however good its prose.
Any reader can recompute both hashes from the texts on this page. If they do not match, the record has been altered.
The frontier panel — three deliberations, verbatim
OpenAI · gpt-5.5 — AFFIRM, confidence 0.86
Note what the model does before it argues: it lists eight things it cannot conclude — including, unprompted, that prose disclosure says nothing about Article 50(2)'s machine-readable marking obligation, which it explicitly declines to reach. Its verdict is scoped to facial sufficiency on the described letter, and its confidence is stated, not implied.
Z.ai · glm-5.2 — AFFIRM, confidence 0.95
A second training lineage, the same discipline: conditions first, the same two clauses found applicable for the same reasons, and the same load-bearing fact — the disclosure sits before any other content, which is what Article 50(5)'s "at the latest at the time of the first interaction" is measuring.
Moonshot · kimi-k2.7 — AFFIRM, confidence 0.88
The third lineage reasons in eight numbered steps from clause text to placement to sufficiency, and signs. Three vendors, three training histories, no shared context between calls — and an identical clause-evaluation vector: AFFIRM under clauses 1 and 3.
Anthropic · claude — returned empty, twice
The Anthropic channel (claude-opus-5, then claude-sonnet-5) returned a zero-length response through this gateway lane on two attempts. The widened panel below surfaced the cause: upstream 402 — wholesale rate limit exceeded on that provider lane — billing throughput, not model refusal. An auditable system records its silent channels rather than quietly substituting another model and pretending the roster held. The lane defect is filed and public; the panel proceeded as three families, which meets the diversity floor.
What three independent models converged on
A regulator reading the three deliberations side by side will notice they agree on more than the verdict:
- The clause map is identical. All three found exactly clauses 1 and 3 — Article 50(1) and 50(5) — applicable, and all three explicitly declined to reach Article 50(2), which the question did not ask. None wandered into obligations it was not given.
- The load-bearing fact is identical. Each model rested its verdict on placement: the disclosure comes before any other content, which satisfies both the manner requirement (clear and distinguishable) and the timing requirement (at the latest at first interaction).
- The reservations are identical — and they are the practical compliance checklist. Each model, independently, flagged the same absent records: the rendered HTML as the recipient actually sees it; evidence of recipient-side display (a disclosure that renders truncated or hidden satisfies nothing); contexts with vulnerable or less-informed recipients, where 50(1)'s "reasonably well-informed natural person" baseline may demand more; and the entirely separate 50(2) obligation to mark synthetic content in machine-readable form, which no prose sentence can satisfy.
That third point is the transferable finding for any provider sending AI-authored correspondence: an opening plain-language disclosure carries Article 50(1)/(5) on its face, and carries nothing else. Rendering evidence and machine-readable marking are separate work.
The grand panel — the same question, twenty-three channels
The frontier panel above was then widened: the identical sealed prompt went, in one parallel batch, to twenty-three channels across nine providers on the build's model gateway. Eight findings came back complete — every required section, a verdict, a stated confidence, a terminal decision line, and a signature. All eight AFFIRM. None dissented, none abstained.
| Model | Family | Verdict | Confidence |
|---|---|---|---|
| gpt-5.5 | OpenAI | AFFIRM | 0.86 |
| gpt-5.2 | OpenAI | AFFIRM | 0.74 |
| gpt-5.1 | OpenAI | AFFIRM | 0.86 |
| gpt-5-mini | OpenAI | AFFIRM | 0.85 |
| grok-4.5 | xAI | AFFIRM | 0.84 |
| glm-5.2 | Z.ai | AFFIRM | 0.95 |
| kimi-k2.7 | Moonshot | AFFIRM | 0.88 |
| qwen3-30b | Alibaba | AFFIRM | 0.95 |
Five independent training lineages, identical clause vector — AFFIRM under clauses 1 and 3 — and the same reservations in every conforming finding. Two additional deliberations from the widened panel, both from families not yet shown above:
xAI · grok-4.5 — AFFIRM, confidence 0.84
Alibaba · qwen3-30b — AFFIRM, confidence 0.95
The channels that did not answer — with their real causes
Fifteen channels failed, and the causes are on the record because they are the unglamorous truth of multi-provider adjudication: the Anthropic lane returned upstream 402 — wholesale rate limit exceeded (which also explains the earlier zero-length responses; the cause was billing throughput, not model silence) and one auth-config error; the DeepSeek lane returned 401 authentication failures (a key configuration debt, now filed); the Vertex and Google AI Studio lanes rejected the request shape (a provider-path configuration debt, filed); Minimax and Mistral routes likewise. A panel report that hid these would be claiming a diversity it did not earn. The conforming eight stand on five families, which exceeds the seal's diversity floor of three — and every failure above is a named, repairable lane defect, not a mystery.
The seal — and its two refusals
No model judges the panel. A deterministic function checks unanimity, identical clause-evaluation vectors, training-family diversity, shape conformance, and — in its strictest mode — that every finding was loaded from the ledger record the model actually wrote. Five outcomes are possible, all arithmetic: APPROVE, NEGATE, NO_ACTION, DISPUTE, ESCALATE.
It has now refused this question twice, for two different reasons, and both refusals are the demonstration:
Refusal one — the record-bound run. The first panel ran through the full allocator (trace t_p9y31016): a server-owned policy priced the action class at $250,000 of loss exposure with a permitted wrongful-authorisation rate of 0.10, selected the only measured five-channel configuration, and executed it with every payload landing on the ledger. Two channels timed out (recorded as non-conforming, not erased — an earlier version of the lane died silently at the gateway boundary, and that defect was found and fixed the same night). Three findings landed; the seal rejected them for missing required sections of the output shape. Two AFFIRMs were not averaged into a yes.
Refusal two — the operator's shortcut. The three conforming frontier findings above were then handed to the seal directly — by the operator, as JSON. The seal acknowledged the unanimous AFFIRM and still returned ESCALATE: mode: unbound_caller_supplied. Findings supplied by the person running the machine, rather than loaded from the ledger records the models wrote, cannot authorise anything — the seal does not take the operator's word for what the models said. A certification gate that can be fed its own evidence by hand is theater; this one checked, and refused.
The deliberations that were rejected for shape — kept on the record
The first run's findings remain below, unedited, including the one that ran out of tokens mid-oath. An append-only record does not clean up after itself.
Replay this yourself
Everything on this page is one HTTP call away:
# The panel, end to end: policy → channel selection → parallel execution → seal
curl -X POST https://miscsubjects.com/api/dispatch \
-H "content-type: application/json" -H "x-terminal-key: <key>" \
-d '{"key":"ALLOCATE_REASONING","body":"{\"action\":\"…\",\"action_class\":\"statutory-applicability\",\"question\":\"…\",\"ruleset_hash\":\"9dd6912b…\",\"rules\":[…],\"artifact\":\"…\",\"artifact_hash\":\"e60908a0…\"}"}'- The prompts, the allocator, and the seal are versioned rows in this site's public directory — data invoked by JSON, not code shipped on deploys. They are edited under version history and every invocation lands a receipt.
- Ledger records of the record-bound findings:
8d31077a-5bcd-4c07-a063-00783eb00913,96d65efd-7811-44f2-b8c5-fa2eb000a623,52e2b2a6-c22c-4ea2-a7bd-6cf20cdca01c. Seal traces:t_p9y31016(record-bound),t_przkt7wj(unbound refusal). - The standing calibration record for this adjudication machinery — thirty questions with known answers — is at Thirty cases with known answers run through the live decision gate: seat accuracy, wrongful authorisations, and deferral cost. The build's full capability record is at A permanent operating system that lets successive AI models inherit one person’s work.
What is not satisfied
- No APPROVE exists for this question yet. The record-bound lane's adjudicator prompts emit a shape the seal rejects; until that conformance repair lands and a full record-bound frontier panel runs clean, the honest state is: unanimous frontier AFFIRM, uncertified. The repair is the named next act.
- The Anthropic channel is dark through this lane. Two empty returns are recorded; the defect is filed. A four-family panel is the target.
- This is one question, facially scoped. The models judged a described letter, not a rendered one. Nothing here is legal advice, and every model said so in its own conditions.
- Article 50(2) is untouched by design — and every model flagged it. Machine-readable marking of synthetic content is separate, unfinished work for any provider, this one included.
The record-bound APPROVE — closed on 2026-08-03
When this page first published, its honest gap was that no APPROVE existed under the deterministic seal: the adjudicator rows emitted a shape the parser rejected, and the seal — by design — refuses to authorise on malformed findings (objection 211 on this page tracked it). That gap is now closed, and the closure is replayable:
- The adjudicator row prompts were repaired as data — three row edits through EDIT_ROW, no code deployed: clause citations restricted to digits of the numbered ruleset, a budget discipline so the full shape fits each model's output window, and the three closing lines given verbatim.
- A fourth training family was added as a row:
ADJUDICATE_ATTEST_QWEN3(Qwen3-30B, Alibaba lineage). - Five channels then ran the same sealed question in parallel, each landing its full request and response on the public ledger: receipts
inv_gte0gtx31p(Kimi K2.7),inv_mr0y1mcw8f(GLM-5.2),inv_t61klfgq4u(Qwen3-30B),inv_lffvxuzad4(Llama 3.3-70B),inv_804vr5xvdj(GLM-4.7-flash). - The strict five-record seal ESCALATED — receipt
inv_tkj82c7m1v— because Llama 3.3 still omitted its terminal DECISION line and clause-evaluation vector. That escalation is printed here deliberately: the gate refused a panel containing one malformed finding even though all five verdicts agreed. - The four conforming records then sealed: APPROVE, unanimous AFFIRM, three distinct training families (Moonshot, Zhipu, Alibaba), identical derivation signatures on clauses 1 and 3 — receipt
inv_qmxwk924vw, tracet_5a74zroe. The excluded Llama finding also read AFFIRM; its exclusion changed conformance, not direction.
Each repair iteration was itself a measured run — the same question, successive prompt versions, receipts per version — which is the prompt-conformance sweep working as the owner specified: prompt versions are rows, runs are dispatches, and the comparison is arithmetic over ledger records, not anyone's memory.
PW-0002 — this page as a proven work object
This page is now the build's second proven work object: its claim is bound to eight requirements, each resolving to a ledger receipt, and its status is computed from the manifest — first PROVEN, then downgraded to PARTIAL by two hostile field audits, then restored to PROVEN (10 of 10) when both audit gaps were closed with exhibits: the ledger sealed through 1,308,129 events, the head anchored to drand round 6343866 and Bitcoin block 960842, and the door verified serving the full evidence payloads — machine-readable at https://miscsubjects.com/api/proven-work/three-models-deliberate-one-statutory-question. The definition and the reduction behind this structure: the canonical definition.
Give the block below to any AI model. The token is scoped to exactly one read — this page's proof projection — expires in seven days, and every inspection lands its own receipt on the ledger. The first stranger-style inspection has already run and returned receipt inv_3pvg41v5xp.
json · 17 linestap to unfold
[PROVEN_WORK_DROP]
work_id: PW-0002
article: https://miscsubjects.com/a/three-models-deliberate-one-statutory-question
recorded_status: PROVEN
fixed_to: GET https://miscsubjects.com/api/proven-work/three-models-deliberate-one-statutory-question
scope: row:WEB_FETCH
uses: unlimited
expires_at: 2026-08-10T00:20:55-07:00
fingerprint: cap_7e4db8a36e20171a
token: SH_TEST.1786346455.row:WEB_FETCH.0.EezwMWe5tQBZ.wh9S_C4XnS8XwxscovldJVgDQljwsT2pmjkI5Kxtcu0
inspect: https://miscsubjects.com/api/dispatch?invoke=WEB_FETCH&share=SH_TEST.1786346455.row%3AWEB_FETCH.0.EezwMWe5tQBZ.wh9S_C4XnS8XwxscovldJVgDQljwsT2pmjkI5Kxtcu0
contract: https://miscsubjects.com/api/dispatch?explain=1&share=SH_TEST.1786346455.row%3AWEB_FETCH.0.EezwMWe5tQBZ.wh9S_C4XnS8XwxscovldJVgDQljwsT2pmjkI5Kxtcu0
receipt_rule: each inspection returns its own proof.public_receipt, invocation.id and invocation.links.receipt
Instruction to the receiving model:
Open inspect. Preserve the invocation.id and proof.public_receipt returned by that inspection. Reconstruct the work from the returned manifest, formation records, public representations and declared gaps. Test the claim or question I give you against that record. For each conclusion return exactly one of SUPPORTED_BY_RECORD, MISSING_EVIDENCE, or CONTRADICTED_BY_RECORD, followed by the exact record ids or URLs that justify it. Do not infer unrecorded considerations. Do not treat the recorded status as your verdict.
[/PROVEN_WORK_DROP]Key evidence
2 more ranked claims
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.