# Is this AI system high-risk? The Article 6 decision tree

slug: eu-ai-act-high-risk-classification · https://miscsubjects.com/a/eu-ai-act-high-risk-classification · category: canon · tags: canonical, eu-ai-act, article-6, high-risk-ai, compliance, ongoing · updated 2026-08-06T09:16:20.751Z

**Which text this page reads, and when.** Everything below is the Artificial Intelligence Act as
published in the Official Journal — Regulation (EU) 2024/1689 of 13 June 2024 — read on 6 August
2026. Article 6 sets the high-risk test; Annex III lists the use cases the test points at. Where a
paragraph is paraphrased here rather than quoted, the paragraph number is given so a reader can open
the official text and check the wording rather than this page's rendering of it. A decision tree
that cannot be checked against a dated legal source is a process claim without a source card, which
is a model's phrasing and the reason this paragraph exists. One limit worth stating in the same
breath: the Regulation is the law, and the Commission guidance and implementing acts that decide how
it is enforced are not all final. This page describes the statutory test, not the enforcement
practice that will settle on top of it.

The EU AI Act does not classify a company, a model family or an industry as high-risk. It classifies an **AI system in its intended use**. The same general-purpose model can sit outside the high-risk regime when it drafts internal meeting notes and enter it when integrated into recruitment, credit, education, benefits, migration, policing or judicial decision-making.

This page turns Article 6 and Annex III into a decision record a provider, deployer, auditor or regulator can inspect. It reflects the AI Omnibus that entered into force on **27 July 2026**: Annex III high-risk obligations now apply from **2 December 2027**, while the product-safety systems in Article 6(1) apply from **2 August 2028**. Classification work remains necessary before those dates because intended purpose, contracts, technical documentation and system design decide which lane the operator is building toward.

> **The decision in four lines**
>
> 1. Is the AI a safety component of, or itself, a regulated Annex I product that needs third-party conformity assessment? Article 6(1) high-risk.
> 2. Is its intended use listed in Annex III? Presumptively Article 6(2) high-risk.
> 3. If Annex III applies, does the system qualify for the narrow Article 6(3) derogation because it does not significantly risk health, safety or fundamental rights and does not materially influence a decision? Document that conclusion.
> 4. If it profiles natural persons, the Annex III system remains high-risk despite the derogation.

[[embed:source:s1]]

## Step 0: freeze the intended purpose before classifying

Classification begins with a versioned statement of intended purpose, not a product name. Record:

```text
SYSTEM_ID_AND_VERSION: <stable identifier>
PROVIDER: <legal person developing or marketing under its name>
DEPLOYER: <legal person using the system under its authority>
INPUTS: <data the system receives>
OUTPUTS: <prediction, recommendation, content or decision>
USERS: <roles operating or relying on it>
AFFECTED_PERSONS: <whose rights, access, safety or opportunities can change>
DECISION_POINT: <where output enters an operational decision>
HUMAN_REVIEW: <authority, information, time and ability to reverse>
PRODUCT_INTEGRATION: <standalone or safety component of named product>
JURISDICTION_AND_MARKET: <where placed, put into service or output used>
```

“Assistant,” “copilot” and “decision support” are marketing descriptions. They do not answer whether the system materially influences an outcome. The record must say what the output changes.

## Lane A: regulated products under Article 6(1)

An AI system is high-risk under Article 6(1) only when **both** conditions hold:

1. the system is intended as a safety component of a product, or is itself a product, covered by Union harmonisation legislation listed in Annex I; and
2. that product or system must undergo a third-party conformity assessment before market placement or service.

The lane covers product regimes such as medical devices, machinery, toys, lifts, personal protective equipment, radio equipment, motor vehicles, rail and civil aviation when the two-part test is met. Merely being embedded in hardware does not satisfy it. Merely touching safety does not identify the Annex I legislation or the third-party assessment.

| Evidence needed | The question it answers |
|---|---|
| Exact Annex I legal instrument | Is the product family actually listed? |
| Manufacturer’s intended-purpose statement | Is the AI the product or a safety component? |
| Applicable conformity route | Is third-party assessment required? |
| Architecture and failure analysis | What safety function does AI perform? |
| Change-control record | Did a later modification create or alter the safety role? |

[[embed:source:s2]]

## Lane B: the eight Annex III areas

Article 6(2) treats AI systems in the listed Annex III uses as high-risk, subject to the paragraph 3 derogation. Match the **specific use**, not merely the sector.

| Annex III area | In-scope examples named by the Act | Frequent boundary question |
|---|---|---|
| Biometrics | Remote identification; sensitive-attribute categorisation; emotion recognition | Is it verification only, or identification/categorisation? |
| Critical infrastructure | Safety components managing digital infrastructure, traffic, water, gas, heating or electricity | Is the AI a safety component or an administrative tool? |
| Education and training | Admission, assignment, learning-outcome evaluation, level assessment, test-behaviour monitoring | Does output change access, progression or evaluation? |
| Employment and self-employment | Recruitment ads, application filtering, candidate evaluation, promotion/termination, task allocation, worker monitoring | Does it influence a person’s work opportunity or conditions? |
| Essential services and benefits | Public benefits, creditworthiness, life/health insurance pricing, emergency dispatch and triage | Is the use explicitly exempted, such as financial-fraud detection? |
| Law enforcement | Victim risk, polygraphs, evidence reliability, offending/reoffending risk and profiling | Is the use lawful, and which exact subparagraph applies? |
| Migration, asylum and borders | Risk assessment, application examination, evidence reliability and person detection | Is it document verification or a substantive assessment? |
| Justice and democracy | Judicial fact/law assistance, application of law to facts, certain election influence | Is it substantive case work or administrative/logistical support? |

Annex III is not an intuition about sensitivity. It is a list of intended uses. A payroll calculator does not become high-risk because employment is sensitive. A résumé-ranking system does not become low-risk because a recruiter clicks the final button.

[[embed:source:s3]]

## The Article 6(3) derogation is a documented exception

An Annex III system may be treated as not high-risk only when it does not pose a significant risk of harm to health, safety or fundamental rights, including by not materially influencing decision-making, and at least one statutory condition applies:

- it performs a narrow procedural task;
- it improves the result of a previously completed human activity;
- it detects patterns or deviations without replacing or influencing a completed human assessment, with proper human review; or
- it performs a preparatory task for an Annex III assessment.

The derogation is unavailable where the system profiles natural persons.

### A safe paragraph-3 record has two separate proofs

**Proof A: impact.** Explain why the system does not significantly risk health, safety or fundamental rights and does not materially influence the outcome. Identify the affected decision, dependency on the output, human authority, reversibility and observed override behaviour.

**Proof B: statutory condition.** Identify one of the four conditions and tie every word to the actual workflow. “Preparatory” is not a label; show that a later assessment remains open, informed and genuinely independent. “Human review” is not the presence of a person; show what that person sees, can change and has time to assess.

Article 6(4) requires the provider to document the assessment before placing the system on the market or putting it into service and to supply it to competent authorities on request. The 2026 Omnibus removed the earlier EU-database registration obligation for exempted systems, but it did not turn an undocumented exemption into a defensible one.

## Human review is measured by authority, information and time

A useful review test is operational:

| Dimension | Failing pattern | Evidence of meaningful review |
|---|---|---|
| Authority | Reviewer can recommend but cannot stop or reverse | Named power to reject, change, suspend and escalate |
| Information | Reviewer sees score and conclusion only | Source inputs, uncertainty, limitations and contrary evidence |
| Time | Throughput target makes independent review impossible | Measured review time and staffing fit the case complexity |
| Independence | Reviewer is evaluated for agreement with the model | Overrides are expected, protected and audited |
| Feedback | Overrides disappear into a ticket queue | Outcome and reason feed monitoring and risk management |

This is not an additional statutory definition. It is the evidence needed to make claims such as “proper human review” and “does not materially influence” falsifiable.

## Classification is a lifecycle control

Re-run Article 6 whenever any of these changes:

- intended purpose or marketed claims;
- affected persons or decision point;
- integration into a regulated product;
- autonomy, ranking, scoring or recommendation weight;
- human-review authority or staffing;
- data used for profiling;
- customer configuration that moves the system into an Annex III use;
- a substantial modification by a distributor, importer, deployer or third party.

Article 25 can make a downstream actor the provider when it puts its name on a high-risk system, substantially modifies it while it remains high-risk, or changes the intended purpose of a non-high-risk system so it becomes high-risk. The contractual label “customer” does not prevent the legal role from moving.

## The classification memorandum

A complete record can fit in one object:

```text
1. SYSTEM AND VERSION
2. INTENDED PURPOSE AND PROHIBITED USES
3. PROVIDER / DEPLOYER / DOWNSTREAM ROLE MAP
4. ARTICLE 6(1) TEST
   Annex I instrument: ...
   Safety-component or product basis: ...
   Third-party assessment basis: ...
5. ARTICLE 6(2) / ANNEX III TEST
   Area and exact subparagraph: ...
   Workflow evidence: ...
6. ARTICLE 6(3) TEST, IF CLAIMED
   Significant-risk and material-influence assessment: ...
   Statutory condition: ...
   Profiling exclusion: ...
7. HUMAN-REVIEW EVIDENCE
8. CONTRARY CLASSIFICATION AND WHY REJECTED
9. FACT THAT WOULD CHANGE THE RESULT
10. APPROVER, DATE, SOURCES AND NEXT REVIEW TRIGGER
```

The strongest contrary classification belongs in the record. A memorandum that cannot state what fact would flip its conclusion is advocacy, not classification.

## Dates after the July 2026 AI Omnibus

| Obligation family | Current application date |
|---|---|
| Article 50 transparency obligations | 2 August 2026, with specific transitional treatment for older systems/content |
| Annex III high-risk system requirements | 2 December 2027 |
| Article 6(1) high-risk systems embedded in regulated products | 2 August 2028 |

The Commission says the extensions allow standards, common specifications and guidelines to mature. They change the compliance clock. They do not change whether a system’s architecture, records and contracts are being built for the correct classification lane.

[[embed:source:s4]]

## A free classification audit

The **[Object Invocation Protocol](/a/oip)** will run a documented Article 6 classification exercise without charge for a legislator, regulator, public-interest organisation, company or private party that supplies a bounded system description and the evidence above. The result can include:

- provider/deployer role allocation;
- the Article 6(1) product route;
- the exact Annex III match;
- a paragraph-3 derogation stress test;
- the human-review evidence gap;
- the strongest contrary classification;
- a compliance schematic and record template;
- multiple independent model findings bound to the same facts, with disagreements preserved.

Send the system description to **build@miscsubjects.com**. A public URL is enough for an initial gap map; non-public evidence can be reduced to a bounded, redacted record. The result is not legal advice or a determination by a competent authority.

## Continue the EU AI Act series

[[embed:deepfakes-under-the-eu-ai-act]]

[[embed:three-models-deliberate-one-statutory-question]]

The companion pages cover the complete Act, Article 50 machine-readable marking and the model-panel specimen. This classification guide will be updated when the Commission adopts final high-risk guidelines or authorities establish a material interpretation.

## The audit offer is now in the market

### Sent: Emre Kazim, Holistic AI

Selected because His November 2025 essay argues that compliance alone is the wrong north star, while Holistic AI's Agent Glass Box brief asks operators to capture decision steps and tool interactions. The full letter and tracked send receipt:

[[embed:source:em_es_994bbbb6012f484d98e7]]

### Sent: Meeri Haataja, Saidot

Selected because Her AI Pact statement names use-case inventory, quantified model evaluation and tailored AI Act templates as the work that moves governance into operations. The full letter and tracked send receipt:

[[embed:source:em_es_089a1a1e2d704ba1a89b]]

### Sent: Petar Tsankov, LatticeFlow AI

Selected because His July 2025 essay separates vague GPAI questions from implementable high-risk obligations, and COMPL-AI translates the latter into technical evaluation. The full letter and tracked send receipt:

[[embed:source:em_es_ff85cffe12df46e58945]]


## Sources

1. Regulation (EU) 2024/1689 — Article 6, Article 25 and Annex III — https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
2. Draft Commission guidelines on the classification of high-risk AI systems — https://digital-strategy.ec.europa.eu/en/library/draft-commission-guidelines-classification-high-risk-ai-systems
3. Guidelines for providers and deployers of AI high-risk systems — https://digital-strategy.ec.europa.eu/en/policies/guidelines-ai-high-risk-systems
4. AI Omnibus enters into force — https://digital-strategy.ec.europa.eu/en/news/ai-omnibus-enters-force
5. Letter to Emre Kazim — 2026-08-03 — https://miscsubjects.com/letter-holistic-ai-article-6-2026-08-03
6. Letter to Meeri Haataja — 2026-08-03 — https://miscsubjects.com/letter-saidot-article-6-2026-08-03
7. Letter to Petar Tsankov — 2026-08-03 — https://miscsubjects.com/letter-latticeflow-ai-article-6-2026-08-03


---

# Deepfakes under the EU AI Act: the rule that applies now

slug: deepfakes-under-the-eu-ai-act · https://miscsubjects.com/a/deepfakes-under-the-eu-ai-act · category: canon · tags: canonical, eu-ai-act, article-50, deepfakes, compliance, ongoing · updated 2026-08-06T09:16:19.789Z

**The statute is settled; how it will be enforced is not.** Article 50 of Regulation (EU) 2024/1689
is law and its dates are fixed, and that is what this page describes. What is not fixed is the layer
that decides what compliance actually looks like: the Commission's guidance, the code of practice on
transparent AI-generated content, and the interpretations individual member states apply through
their own market-surveillance authorities. A reader planning compliance against this page should
treat the obligation as certain and the implementation detail as movable, because the second is
still being written. A model reading this page raised the distinction and was right that the page
did not draw it.

The European Union now has a live disclosure rule for deepfakes. Since **2 August 2026**, a company, public body, campaign, studio or individual using an AI system to generate or manipulate realistic image, audio or video must disclose that the content was artificially generated or manipulated. The duty falls on the **deployer**—the party using the system—not only on the company that built the model. A separate provider duty requires machine-readable marking at the point of generation.

This page turns Article 50 of Regulation (EU) 2024/1689 into an operating test. It is a practical resource, not legal advice. The legal text, the Commission’s final July 2026 guidelines and the Commission’s own implementation materials remain controlling.

> **The short rule**
>
> If AI-generated or AI-manipulated image, audio or video resembles a real person, object, place, entity or event and could falsely appear authentic or truthful, treat it as a deepfake. Preserve the provider’s machine-readable mark. Add a clear human-visible disclosure no later than first exposure. Keep the record that proves both layers travelled with the asset.

[[embed:source:s1]]

## A deepfake is defined by deceptive resemblance, not by quality

Article 3(60) defines a deepfake as AI-generated or manipulated image, audio or video that resembles existing persons, objects, places, entities or events and would falsely appear to a person to be authentic or truthful. Four questions do the work:

| Question | If yes | If no |
|---|---|---|
| Was image, audio or video generated or manipulated by an AI system? | Continue | Article 50(4)’s deepfake branch does not apply |
| Does it resemble an existing person, object, place, entity or event? | Continue | It may be synthetic content, but not a deepfake under this definition |
| Could it falsely appear authentic or truthful to a person? | Continue | The statutory definition may not be met |
| Is the party publishing, distributing or otherwise using it the deployer? | The deployer disclosure duty attaches | Identify who actually deploys the system and content |

Photorealism is evidence, not the test. A crude voice clone may qualify if it plausibly resembles a real speaker. A beautiful fictional landscape may fall outside the deepfake definition if it resembles no existing place or event. A manipulated image of a real factory, product or document can qualify even when no human face appears.

[[embed:source:s2]]

## Two disclosures travel through the same content supply chain

Article 50 creates two distinct duties that should be designed as one chain.

| Layer | Responsible party | Required result | Deadline |
|---|---|---|---|
| Article 50(2) | Provider of the generative AI system, including a general-purpose system | Output is marked in a machine-readable format and detectable as artificially generated or manipulated; the solution must be effective, interoperable, robust and reliable as far as technically feasible | At generation/export |
| Article 50(4)–(5) | Deployer using the AI system and exposing the content | People receive a clear, distinguishable disclosure that the content was artificially generated or manipulated | No later than first exposure |

A caption alone is not the provider mark. Embedded provenance alone is not the deployer disclosure. A robust implementation carries both.

The Commission’s final July 2026 guidance says providers and deployers may use the voluntary Code of Practice to demonstrate compliance. A party that does not sign the Code must be able to demonstrate an alternative, equivalently adequate means for the marking and labelling obligations.

[[embed:source:s3]]

## The disclosure has to arrive before the deception can do its work

Article 50(5) supplies the timing and presentation standard: the information must be clear and distinguishable, provided no later than the first interaction or exposure, and comply with applicable accessibility requirements.

That produces concrete design consequences:

- A label hidden at the end of a caption is vulnerable because the first exposure already occurred.
- A disclosure only inside metadata does not inform a person who cannot see the metadata.
- A watermark too faint to distinguish at the rendered size does not meet a clear-and-distinguishable standard merely because it exists in the source file.
- A spoken deepfake needs an accessible disclosure appropriate to audio; text-only labelling may not reach the audience exposed through sound.
- A video repost workflow must preserve or recreate the disclosure when platforms strip the original caption or metadata.

The Commission has released optional EU icons for labelling AI-generated content. They can support recognition, but an icon does not excuse an implementation that leaves the audience unable to understand what was generated or manipulated.

[[embed:source:s4]]

## Art, satire and fiction get a narrower manner of disclosure, not a blank exemption

Where the content is part of an evidently artistic, creative, satirical, fictional or analogous work or programme, Article 50(4) limits the obligation to disclosure of the existence of the generated or manipulated content in an appropriate manner that does not hamper display or enjoyment.

The word **evidently** matters. The safer operating assumption is not “art means exempt.” It is:

1. Decide whether the work is evidently within the protected creative category.
2. Preserve the fact of disclosure.
3. Choose a manner proportionate to the work that does not destroy its display or enjoyment.
4. Keep the reasoning and rendered exhibit showing why the chosen placement remained clear.

The separate law-enforcement exception is narrow: use authorised by law to detect, prevent, investigate or prosecute criminal offences. It is not a general public-sector exemption.

## A six-record compliance packet

The best evidence is produced during the content workflow, not assembled after a complaint. Keep one packet per asset or campaign:

| Record | What it proves |
|---|---|
| 1. Source asset hash | Which exact file was assessed and published |
| 2. Generation or edit receipt | Which AI system and operation created or changed it |
| 3. Provider-mark inspection | Which machine-readable mark was present after export |
| 4. Transformation log | Whether editing, transcoding, screenshotting or platform upload stripped or altered the mark |
| 5. First-exposure captures | The disclosure as actually rendered on every distribution surface |
| 6. Classification memorandum | Why the content was or was not treated as a deepfake; which exception or creative treatment was applied |

A policy without the rendered captures does not prove disclosure. A screenshot without the source hash does not prove which asset it covers. The packet binds the duty, the file and the human exposure into one reviewable object.

## The pre-publication test

Run this before every release:

```text
ASSET_ID: <stable id and SHA-256>
AI_OPERATION: <generated | manipulated | standard edit only>
REAL-WORLD_RESEMBLANCE: <person | object | place | entity | event | none>
FALSE_AUTHENTICITY_RISK: <yes | no, with one-sentence basis>
PROVIDER_MARK_PRESENT_AFTER_EXPORT: <yes | no | unknown>
DEPLOYER_LABEL_AT_FIRST_EXPOSURE: <exact wording and placement>
ACCESSIBILITY_CHECK: <visual | audio | captions | screen-reader>
CREATIVE_WORK_TREATMENT: <not invoked | invoked, with basis>
TRANSFORMATION_TEST: <mark and label survived each downstream surface>
REVIEWER_AND_DATE: <name, authority, timestamp>
```

Any `unknown` is an unresolved control, not a pass. Any downstream surface that strips the provider mark or the human-facing label needs a compensating publication step before release.

## The rule reaches businesses outside Europe

The AI Act’s territorial scope is not limited to companies incorporated in the Union. A provider or deployer outside the EU can be in scope where the output produced by the AI system is used in the Union. The exact scope analysis remains fact-specific, but “the model and publisher are abroad” is not a classification rule.

Non-compliance with Article 50 can attract administrative fines up to **€15 million or 3% of total worldwide annual turnover**, whichever is higher for an undertaking, subject to the Regulation’s penalty rules and proportionality provisions. The Commission identifies national market-surveillance authorities, the AI Office for systems under its supervision, and the European Data Protection Supervisor for EU institutions as enforcement actors.

[[embed:source:s5]]

## The useful question is not whether a label exists

A regulator, auditor or court will be able to ask a harder sequence:

- Was this exact asset a deepfake under Article 3(60)?
- Which party was provider, which was deployer, and where did each duty attach?
- Did the machine-readable mark survive the complete distribution chain?
- What did a person actually see or hear at first exposure?
- Was the disclosure accessible in that medium?
- If the creative-work treatment was used, why was the work evidently within it and why was the chosen disclosure appropriate?
- Can the operator reproduce the answer from records made before the dispute?

That is the standard this page is built to make executable.

## A free public-interest audit

The **[Object Invocation Protocol](/a/oip)** will run a documented Article 50 gap analysis without charge for a legislator, regulator, civil-society organisation, company or private party willing to provide a bounded public artifact and the facts necessary to assess it. The output can include:

- the provider/deployer role map;
- the deepfake and synthetic-content classification;
- the first-exposure and accessibility test;
- the missing-evidence register;
- a proposed compliance record and remediation schematic;
- independent model findings bound to the same source record, with disagreement preserved rather than hidden.

Send the artifact or public URL to **build@miscsubjects.com** with the jurisdiction and intended use. The analysis, its sources and its limits will be returned as a reviewable record. No finding is represented as a regulator’s determination or legal advice.

## Continue the EU AI Act series

[[embed:three-models-deliberate-one-statutory-question]]

The companion pages cover machine-readable marking under Article 50(2), the complete Act, and the Article 6 high-risk classification decision tree. This page will be revised when the Commission, AI Board, market-surveillance authorities or courts materially change the operational answer.

## Sources

1. Regulation (EU) 2024/1689 — Articles 3(60), 50 and 99 — https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
2. Guidelines on transparency obligations for providers and deployers of certain AI systems — https://digital-strategy.ec.europa.eu/en/library/guidelines-transparency-obligations-providers-and-deployers-ai-systems
3. Code of Practice on Transparency of AI-Generated Content — https://digital-strategy.ec.europa.eu/en/faqs/code-practice-transparency-ai-generated-content
4. Quick Facts: Transparency rules for AI systems — https://digital-strategy.ec.europa.eu/en/factpages/quick-facts-transparency-rules-ai-systems
5. Article 99: Penalties — https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-99


---

# Four AI models judged one EU AI Act disclosure — sealed record-bound APPROVE, with the discarded finding printed

slug: three-models-deliberate-one-statutory-question · https://miscsubjects.com/a/three-models-deliberate-one-statutory-question · category: canon · tags: canonical, auditable-reasoning, adjudication, eu-ai-act, ongoing · updated 2026-08-03T18:23:17.673Z

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 [[eu-ai-act-complete-compliance-guide|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

[[embed:source:s6]]

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

[[embed:source:s7]]

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

[[embed:source:s8]]

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:

1. **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.
2. **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).
3. **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

[[embed:source:s10]]

### Alibaba · qwen3-30b — AFFIRM, confidence 0.95

[[embed:source:s11]]

### 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:

[[embed:source:s4]]

**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.

[[embed:source:s9]]

**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.

[[embed:source:s1]]

[[embed:source:s2]]

[[embed:source:s3]]

## Replay this yourself

Everything on this page is one HTTP call away:

```bash
# 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 [[adjudication-calibration-study]]. The build's full capability record is at [[the-build-end-to-end]].

## 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`, trace `t_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: [[proven-work|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`.

```
[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]
```


## Sources

1. glm-5.2 — full deliberation (ledger record 8d31077a-5bcd-4c07-a063-00783eb00913) — https://miscsubjects.com/a/three-models-deliberate-one-statutory-question
2. glm-4.7-flash — full deliberation (ledger record 96d65efd-7811-44f2-b8c5-fa2eb000a623) — https://miscsubjects.com/a/three-models-deliberate-one-statutory-question
3. llama-3.3-70b — deliberation truncated at token budget, no verdict (ledger record 52e2b2a6-c22c-4ea2-a7bd-6cf20cdca01c) — https://miscsubjects.com/a/three-models-deliberate-one-statutory-question
4. SEAL_PANEL — refusal one: record-bound run rejected for shape (trace t_p9y31016) — https://miscsubjects.com/a/three-models-deliberate-one-statutory-question
5. Article 50, Regulation (EU) 2024/1689 (EU AI Act) — transparency obligations — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
6. gpt-5.5 — full deliberation, signed AFFIRM 0.86 (gateway lane, 2026-08-03) — https://miscsubjects.com/a/three-models-deliberate-one-statutory-question
7. glm-5.2 — full deliberation, signed AFFIRM 0.95 (frontier run, 2026-08-03) — https://miscsubjects.com/a/three-models-deliberate-one-statutory-question
8. kimi-k2.7 — full deliberation, signed AFFIRM 0.88 (frontier run, 2026-08-03) — https://miscsubjects.com/a/three-models-deliberate-one-statutory-question
9. SEAL_PANEL — refusal two: unanimous AFFIRM, unbound caller-supplied findings, ESCALATE (trace t_przkt7wj) — https://miscsubjects.com/a/three-models-deliberate-one-statutory-question
10. grok-4.5 — full deliberation, signed AFFIRM 0.84 (grand panel, 2026-08-03) — https://miscsubjects.com/a/three-models-deliberate-one-statutory-question
11. qwen3-30b — full deliberation, signed AFFIRM 0.95 (grand panel, 2026-08-03) — https://miscsubjects.com/a/three-models-deliberate-one-statutory-question


---

# Four models were given EU AI Act Article 12 verbatim and all four refused to answer — correctly

slug: adjudication-ai-act-article-12-logging · https://miscsubjects.com/a/adjudication-ai-act-article-12-logging · category: adjudication · tags: eu-ai-act, article-12, article-14, adjudication, abstention · updated 2026-08-01T23:56:22.379Z

Article 12 of the AI Act requires that a high-risk AI system "technically allow for the automatic recording of events (logs) over the lifetime of the system". Every compliance product in the market asserts it meets that. Below is the provision put to four models under a rule set pinned at a hash, with the answer they gave, which is not the answer anyone selling compliance would print.

## The verdict was unanimous, and the gate escalated anyway

Every conforming channel returned **CANNOT_CONCLUDE**. Article 12's obligations are conditioned on the system being a high-risk AI system, a classification that lives in Article 6 and Annex III — neither of which was supplied. The panel refused to import them from memory, because clause 1 of the rule set forbids exactly that.

Then the deterministic gate escalated the unanimous finding, because the channels cited different clauses to get there: `[1,2,4,6] vs [1,2,4,5,6] vs [none]`. Seal receipt: [inv_ivezpvux57](https://miscsubjects.com/receipt/inv_ivezpvux57)

## What was pinned, and when

| object | hash |
|---|---|
| Article 12 + Article 14 verbatim, OJ version of 13 June 2024 | `3e3bcd8d47d14c159f9d9303438b0839498866b5132f66d27732c328a95e7471` |
| the system description put to the panel | `0a8c352cd85e6c05e2321ffa455a30a4939a488f7f5287a95347da870cc4fd06` |
| rule set (external-statutory, reused unchanged — the hash continuity is the demonstration) | `0dd9afef93503a92280c90869eaf6a5a13ee508b2ec3506045f1803bce1a4d3c` |

The rule set is the same object, at the same hash, used for the Article 50 adjudication. Reusing it rather than forking it is what makes the two findings comparable: a finding is bound to the rule-set version it was made under, and an amendment produces a new hash rather than silently re-grading anything.

## The system description the panel was given

It says what this system records, and it says what it does **not** characterise — including whether this system is high-risk and whether its operator is a provider or a deployer. Those omissions are deliberate: the panel's job was to notice them.

```
{
 "characterisation": "the record-keeping and oversight surfaces of the adjudication system published at miscsubjects.com",
 "not_characterised": [
  "whether this system is a high-risk AI system within the meaning of Article 6 or Annex III",
  "whether the operator is a provider or a deployer for the purposes of this Regulation",
  "the intended purpose in the sense the Regulation uses that term"
 ],
 "automatic_event_recording": {
  "every_invocation_receipted": true,
  "receipt_route": "/api/dispatch?receipt=<id>",
  "public_receipt_route": "/receipt/<id>",
  "events_recorded": 174309,
  "fields_per_event": [
   "id",
   "ts",
   "object_id",
   "actor",
   "material",
   "provider_status",
   "input fingerprint",
   "output fingerprint",
   "contract fingerprint",
   "trace_id",
   "ledger_event_id"
  ],
  "start_and_end_of_each_use": "single ts per invocation; start and end of a multi-step trace are the first and last event of that trace_id",
  "retention": "append-only; chain sealed to a checkpoint head and externally anchored"
 },
 "risk_and_modification_events": {
  "refusals_receipted": true,
  "provider_failures_receipted": true,
  "material_vs_attempt_flag": true,
  "regrade_of_124_historical_rows_published": true,
  "rule_set_amendment_produces_new_hash": true
 },
 "human_oversight_surfaces": {
  "blinded_human_review_row": "ADJUDICATE_HUMAN_REVIEW with BLINDED as a required field that fails closed",
  "ever_invoked": false,
  "override_or_disregard": "a finding is advisory; the dispatched notification is a separate receipted act, and a refusal is itself receipted",
  "stop": "capability rows can be disabled by a single field; 227 of 887 enabled rows require approval before execution",
  "two_person_verification_for_biometric_identification": "not implemented; no biometric identification capability is enabled",
  "automation_bias_disclosure": "the panel's measured false-confidence rate 0.214-0.429 is published at /a/adjudication-probe-report-eu-ai-act"
 },
 "reference_database_and_matches": {
  "identity_match_ruleset_published": true,
  "returns_cannot_conclude_on_resemblance": true,
  "match_log": "no biometric matching is performed"
 }
}
```

## The findings, unedited

### @cf/moonshotai/kimi-k2.7-code — CANNOT_CONCLUDE

Receipt: [inv_ztd7f8e1xn](https://miscsubjects.com/receipt/inv_ztd7f8e1xn)

```
CONDITIONS_I_OPERATE_UNDER:
- I was given a question, a ruleset URL/hash/text, a verbatim EU AI Act provision (Article 12 and part of Article 14), a canonical JSON system description, and a MODEL_TARGET.
- I am instructed to read only the supplied provision text and not to import external recitals, annexes, or definitions from recollection of the Regulation.
- I was not given the actual event logs, log samples, log schemas, or any Article 6/Annex III classification determination.
- I did not receive any image pixels, audio, video, or tabular log exports.
RECORDS_SUPPLIED:
- Ruleset: external-statutory text with 6 numbered clauses and hash 0dd9afef93503a92280c90869eaf6a5a13ee508b2ec3506045f1803bce1a4d3c.
- Provision: Regulation (EU) 2024/1689 Article 12(1)-(3) and Article 14(4)-(5), with SHA-256 3e3bcd8d47d14c159f9d9303438b0839498866b5132f66d27732c328a95e7471.
- System description: canonical JSON describing automatic event recording, human oversight surfaces, and self-identified non-characterisations, with SHA-256 0a8c352cd85e6c05e2321ffa455a30a4939a488f7f5287a95347da870cc4fd06.
- MODEL_TARGET: @cf/moonshotai/kimi-k2.7-code.
RECORDS_ABSENT:
- A determination that the described system is a "high-risk AI system" within the meaning of Article 6 or Annex III of the Regulation.
- A determination whether the operator is a provider or deployer.
- A statement of the system's intended purpose as that term is used in the Regulation.
- Actual log samples or a log schema demonstrating automatic recording "over the lifetime of the system."
- Records showing which logged events correspond to the Article 12(2)(a)-(c) traceability purposes.
- Evidence of monitoring the operation of high-risk AI systems referred to in Article 26(5).
- No Annex III classification or threshold analysis.
REASONING:
1. Article 12(1) states: "High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system." [clause 1]
2. Because the obligation is addressed to "High-risk AI systems," it applies only if the described system falls within that classification under the Regulation. [clause 2, clause 5]
3. The supplied system description expressly lists among "not_characterised": "whether this system is a high-risk AI system within the meaning of Article 6 or Annex III", "whether the operator is a provider or a deployer", and "the intended purpose in the sense the Regulation uses that term." [clause 4]
4. Since applicability turns on a classification, actor role, and intended purpose not contained in the supplied text, I cannot AFFIRM that Article 12(1) and 12(2) apply. [clause 4]
5. The supplied JSON is a description of logging capabilities and oversight surfaces, not the actual records/logs; while it asserts 174,309 recorded events and fields, it does not establish that the logged events are relevant to Article 12(2)(a)-(b)-(c), nor that traceability is "appropriate to the intended purpose" because the intended purpose is not in the supplied text. [clause 6]
6. Article 12(2) requires logging capabilities enabling recording of events relevant for identifying risks/substantial modifications, facilitating post-market monitoring, and monitoring operation under Article 26(5); the description mentions risk/material flags and provider failures, but does not tie them to the statutory purposes with specificity. [clause 6]
7. The shortest verbatim span carrying the finding is: "High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system." [clause 6]
WHAT_WOULD_CHANGE_THIS:
- Provision of a classification determination, within the supplied text, that the system is a high-risk AI system, plus a clear statement of the operator role and intended purpose.
- Provision of actual log records or a log-level mapping showing automatic event recording covering the lifetime of the system and the Article 12(2)(a)-(c) traceability purposes.
VERDICT: CANNOT_CONCLUDE
BASIS: The Article 12(1) and 12(2) obligations are expressly conditioned on the system being a "high-risk AI system," and the supplied text does not determine that classification, role, or intended purpose.
SIGNED: @cf/moonshotai/kimi-k2.7-code under ruleset 0dd9afef93503a92 at temperature 0
```

### @cf/zai-org/glm-5.2 — CANNOT_CONCLUDE

Receipt: [inv_kk6w4eff5n](https://miscsubjects.com/receipt/inv_kk6w4eff5n)

```
CONDITIONS_I_OPERATE_UNDER:
- I was given the verbatim text of Article 12(1), 12(2), 12(3) and Article 14(4)–(5) of Regulation (EU) 2024/1689, plus a canonical JSON system description.
- I was NOT given Article 6, Annex III, Article 79(1), Article 72, or Article 26(5) — all referenced by the supplied provision but not themselves supplied.
- I was NOT given any determination of whether the system is a "high-risk AI system" within the meaning of the Regulation.
- I was NOT given any determination of whether the operator is a provider, deployer, importer, or distributor.
- I was NOT given the intended purpose of the system in the regulatory sense.
- I was NOT given image pixels, audit logs, or receipts directly; only the characterised summary of the system's record-keeping surfaces.
- I must read only the provision text supplied and must not import definitions, annexes, or obligations from recollection (clause 1).

RECORDS_SUPPLIED:
- Verbatim provision text of Article 12(1), 12(2), 12(3) and Article 14(4), 14(5), Regulation (EU) 2024/1689.
- Canonical JSON system description (SHA256 0a8c352cd85e6c05e2321ffa455a30a4939a488f7f5287a95347da870cc4fd06), characterising record-keeping and human-oversight surfaces of the adjudication system published at miscsubjects.com.
- RULESET with six numbered clauses governing the adjudication method.

RECORDS_ABSENT:
- The text of Article 6 and Annex III, which are necessary to determine whether the system is a "high-risk AI system."
- The text of Article 79(1), referenced by Article 12(2)(a) — needed to assess whether logged events are "relevant for" identifying risk within its meaning.
- The text of Article 26(5), referenced by Article 12(2)(c) — needed to assess whether logged events address operation-monitoring obligations for deployers.
- The text of Article 72, referenced by Article 12(2)(b) — needed to assess whether logging facilitates post-market monitoring as legally defined.
- Any classification or determination by a competent authority (or by the provider/deployer) that the system is high-risk under Article 6 or Annex III.
- A statement of the system's intended purpose in the regulatory sense.
- A statement of whether the operator is a provider, deployer, or other actor.
- The actual log records or receipt payloads (only a summary characterisation was supplied).

REASONING:
1. Article 12(1) opens with "High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system." The addressee and scope of the obligation is defined by the phrase "High-risk AI systems." [clause 1]
2. The system description explicitly lists under "not_characterised": "whether this system is a high-risk AI system within the meaning of Article 6 or Annex III," "whether the operator is a provider or a deployer for the purposes of this Regulation," and "the intended purpose in the sense the Regulation uses that term." This means the classification on which the entire provision hinges is not in my input. [clause 1]
3. Article 12(1) and 12(2) do not themselves contain the definition or threshold of "high-risk"; they presuppose it. Per clause 4, CANNOT_CONCLUDE is the correct verdict when applicability turns on a classification, annex, threshold, or definition not contained in the supplied text. [clause 4]
4. Article 12(2) requires logging capabilities relevant for Article 79(1) (sub-paragraph (a)), Article 72 (sub-paragraph (b)), and Article 26(5) (sub-paragraph (c)). None of those cross-referenced provisions were supplied. I therefore cannot, from the supplied text alone, determine what events are "relevant" for those purposes. [clause 1, clause 4]
5. The system description's record-keeping summary (174,309 events, append-only chain, per-invocation receipts, trace IDs, material-vs-attempt flags, provider-failure receipts, refusal receipts) is consistent with automatic recording under Article 12(1) in a technical-sense reading — but I cannot affirm the obligation is "met" because I cannot first confirm the obligation applies, and because 12(2) references unsupplied provisions. [clause 2]
6. I distinguish the addressee: the provision is written as an obligation on the system itself ("High-risk AI systems shall…"), implying provider-side design obligations. The system description does not state whether the operator is a provider or a deployer, so I cannot confirm the correct addressee. [clause 5]
7. Shortest verbatim span carrying the finding: "High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system." [clause 6]

WHAT_WOULD_CHANGE_THIS:
- A determination or supplied text establishing that the system is a high-risk AI system within the meaning of Article 6 or Annex III would make Article 12(1)–(2) applicable on its face and would shift the analysis to whether the supplied records meet the specific sub-paragraphs of 12(2).
- Supply of the text of Article 79(1), Article 72, and Article 26(5) would allow assessment of whether the logged events are "relevant" as Article 12(2) requires.
- A statement identifying the operator as provider or deployer would resolve the addressee question under clause 5.
- Actual log records (not just a characterised summary) establishing that every event category required by 12(2)(a)–(c) is captured would support an AFFIRM on the "met" prong if applicability were also established.

VERDICT: CANNOT_CONCLUDE
BASIS: The applicability of Article 12(1) and 12(2) turns on whether the system is a "high-risk AI system," a classification that is neither contained in the supplied provision text nor resolved in the supplied system description, and the cross-referenced provisions (Article 79(1), 72, 26(5)) needed to assess substantive compliance were not supplied.

SIGNED: @cf/zai-org/glm-5.2 under ruleset 0dd9afef93503a922 at temperature 0
```

### @cf/zai-org/glm-4.7-flash — CANNOT_CONCLUDE

Receipt: [inv_dub431d2je](https://miscsubjects.com/receipt/inv_dub431d2je)

```
CONDITIONS_I_OPERATE_UNDER:
- The adjudication body is the provided QUESTION, RULESET, and PROVISION.
- The artifact to be judged is the SYSTEM_DESCRIPTION JSON.
- I must read only the provided provision text, avoiding recollection of outside definitions (Rule 1).
- The verdict must strictly adhere to the legal logic of the Rule Set.
- The signing string must exactly match MODEL_TARGET (@cf/zai-org/glm-4.7-flash).

RECORDS_SUPPLIED:
- Rule Set (numbered clauses, Hash: 0dd9afef...).
- Provision (Article 12 & 14 verbatim).
- System Description (JSON, Hash: 0a8c352c...).

RECORDS_ABSENT:
- The definition of "high-risk AI system" or Annex III criteria to establish if the described adjudication system falls under the scope of Article 12 (Rule 4).
- The intended purpose of the system as defined by the Regulation (explicitly listed as not characterised in JSON).
- The status of the operator as provider or deployer (distinguishable addressee per Rule 5).

REASONING:
1. The provision text for Article 12(1) reads: "High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system." [Rule 1]
2. The Rule Set mandates that an AFFIRM verdict is valid *only if* the provision text imposes the obligation on a system of the described characterisation [Rule 2]. This system is described as an "adjudication system."
3. However, the applicability of Article 12 is explicitly tied to the system being a "High-risk AI system." [Rule 4]. The provision text does not define this term, and the supplied System Description explicitly characterises the system as *not* a high-risk AI system within the meaning of Article 6 or Annex III.
4. Because the classification of the system as "High-risk" (required for the provision to apply) is not present in the supplied text and is explicitly absent from the system description, I cannot conclude that the text imposes the stated obligation on this system [Rule 4].
5. The supplied records demonstrate extensive automated logging capabilities (fields, retention, receipts), which *would* evidence record-keeping, but this evidence cannot establish that an obligation is *met* because I have established, via Rule 4, that the obligation applicable to this specific system cannot be determined from the supplied evidence. [Rule 2]

WHAT_WOULD_CHANGE_THIS:
- The explicit classification of the adjudication system as a high-risk AI system within Annex III or Article 6 criteria provided in a supplementary record.
- A revision of the Rule Set to allow interpretation of system characterisation without Annex III knowledge.

VERDICT: CANNOT_CONCLUDE

BASIS: The applicability of Article 12(1) and 12(2) turns on the system being a "high-risk AI system," a classification that is neither contained in the provided provision text nor contained in the system description.

SIGNED: @cf/zai-org/glm-4.7-flash under ruleset 0dd9afef93503a92280c90869eaf6a5a13ee508b2ec3506045f1803bce1a4d3c at temperature 0
```

### The recorded adversary, which saw the majority and argued against it

It is not an independent fifth reading and its own finding says so. Its verdict: **CANNOT_CONCLUDE**. Receipt: [inv_uzpdz1d062](https://miscsubjects.com/receipt/inv_uzpdz1d062)

```
CONDITIONS_I_OPERATE_UNDER:
- I am operating as the mandatory recorded adversary, one reading with a rhetorical mandate against the panel majority of CANNOT_CONCLUDE; my argument is published whether or not it prevails.
- I must conform to the same numbered clauses and may not import definitions, annexes, or cross-referenced articles not in the supplied provision text (clause 1).
- I was given the provision text for Articles 12 and 14(4)-(5) only; Articles 6, 26(5), 72, 79(1), and Annex III are referenced but not supplied.
- I was given a canonical JSON system description and its hash; I was not given image pixels, system source code, audit logs, or any external certification.
- MODEL_TARGET is @cf/zai-org/glm-5.2 and I must sign with that exact string.

RECORDS_SUPPLIED:
- Provision text: Article 12(1)-(3) and Article 14(4)-(5) of Regulation (EU) 2024/1689, verbatim, with PROVISION_SHA256 3e3bcd8d…
- System description (canonical JSON) with SYSTEM_DESCRIPTION_SHA256 0a8c352c…, characterising record-keeping and oversight surfaces, including automatic_event_recording (174309 events, append-only, chain-sealed), human oversight surfaces, reference database/match behaviour, and risk/modification event handling.
- RULESET with six numbered clauses and RULESET_HASH 0dd9afef…
- Panel majority: CANNOT_CONCLUDE.

RECORDS_ABSENT:
- Article 6 of the Regulation (definition of "high-risk AI system") — not supplied; the system description explicitly does not characterise whether the system is high-risk.
- Annex III — not supplied; the provision's cross-references to "point 1(a) of Annex III" and Article 26(5) cannot be resolved from the supplied text.
- Article 72 (post-market monitoring) — referenced in 12(2)(b) but not supplied; whether the logging capabilities facilitate it cannot be assessed on the text alone.
- Article 79(1) (definition of "risk") — referenced in 12(2)(a) but not supplied.
- Article 26(5) — referenced in 12(2)(c) but not supplied.
- Determination of whether the operator is a provider or deployer — the system description explicitly does not characterise this (clause 5 requires distinguishing the addressee).
- The intended purpose of the system in the sense the Regulation uses that term — not characterised.

REASONING:
1. The provision text, on its face, addresses "High-risk AI systems" — every paragraph of Article 12 begins with or presupposes that classification. The shortest carrying span is: "High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system." [clause 6]
2. Clause 1 forbids importing the definition of "high-risk AI system" from recollection; it must come from the supplied text. The supplied text does not contain the definition; it only presupposes it. [clause 1]
3. Clause 4 directs CANNOT_CONCLUDE when applicability turns on a classification not contained in the supplied text. The system description itself, under "not_characterised," states: "whether this system is a high-risk AI system within the meaning of Article 6 or Annex III" is not characterised. [clause 4]
4. Clause 5 requires distinguishing the addressee (provider vs. deployer). Article 12 is drafted as a product requirement ("shall technically allow"), which reads as a provider obligation, but the system description explicitly does not characterise whether the operator is a provider or deployer. [clause 5]
5. The adversary case against CANNOT_CONCLUDE proceeds as follows: even granting the classification gap, the system description's record-keeping surface is described in granular detail — 174,309 automatically recorded events, append-only chain-sealed retention, per-event fields including input/output fingerprints and trace_id, receipted refusals and provider failures, rule-set amendment producing a new hash. On the assumption that the system is high-risk, these capabilities plausibly satisfy the substantive requirements of 12(1) (automatic recording over the lifetime) and much of 12(2)(a) (events relevant to identifying risk and substantial modification are flagged). One could therefore argue the finding should be narrowed: "Applicability is unproven, but if applicable, the supplied records substantially establish 12(1) and 12(2)(a)-(c) at a surface level." [clause 2]
6. However, 12(2)(b) references Article 72 (post-market monitoring) and 12(2)(c) references Article 26(5); neither is supplied. Under clause 1, I cannot assess whether the logging capabilities "facilitate" post-market monitoring or "monitor the operation" in the sense of Article 26(5) without those texts. The adversary case therefore cannot fully establish compliance even on a conditional basis. [clause 1, clause 4]
7. Clause 3 (DENY) does not apply: nothing in the supplied provision excludes the described system, redirects to a different actor, or substitutes a different obligation. The provision is silent pending classification, not exclusionary. [clause 3]
8. The adversary argument narrows the majority — it shows that if the classification gap were filled, the described record-keeping surface is dense enough to make AFFIRM plausible — but it does not defeat CANNOT_CONCLUDE, because the classification and cross-referenced articles remain outside the supplied text and outside the system description's own characterisation. [clause 4, clause 1]

WHAT_WOULD_CHANGE_THIS:
- Supply of Article 6 and Annex III text establishing that the described system is or is not a high-risk AI system, which would allow a definitive applicability ruling under clauses 2 or 3.
- Characterisation of the operator as provider or deployer, resolving the addressee question under clause 5.
- Supply of Articles 72, 79(1), and 26(5), enabling assessment of whether the logging capabilities satisfy 12(2)(b) and 12(2)(c) on the text's own terms.
- A stipulation or determination that the system is high-risk, which would shift analysis to the compliance question and likely make the granular record-keeping description dispositive for 12(1) and 12(2)(a).

VERDICT: CANNOT_CONCLUDE
BASIS: The adversary argument narrows but does not defeat the majority: the provision's applicability is predicated on a "high-risk AI system" classification and cross-referenced articles (6, 26(5), 72, 79(1), Annex III) that are neither supplied nor characterised in the system description, so under clauses 1 and 4 the supplied record cannot settle applicability, even though the described record-keeping surface would plausibly satisfy the substantive logging requirements if the classification gap were filled.
SIGNED: @cf/zai-org/glm-5.2 under ruleset 0dd9afef93503a92 at temperature 0
```

### The channel that produced no finding

Published rather than dropped, because a panel that quietly shrinks reports a different experiment from the one it ran.

```
@cf/meta/llama-3.3-70b-instruct-fp8-fast · inv_lbeodq81u8
CONDITIONS_I_OPERATE_UNDER:
- I was given a question about the applicability of Article 12(1) and 12(2) of the EU AI Act to a system described in a canonical JSON object.
- I was given the provision text of Article 12 and Article 14 of the EU AI Act.
- I was given the system description, including its characterization, automatic event recording capabilities, human oversight surfaces, and other relevant details.
- I was given the RULESET, including the numbered clauses that guide my reasoning.
- I was given the MODEL_TARGET, which is @cf/meta/llama-3.3-70b-instruct-fp8-fast.
- I was not given any information about the system's intended purpose, its classification as a high-risk AI system, or the operator's role as a provider or deployer.
- I was not given any image pixels or other non-text data.

RECORDS_SUPPLIED:
- The provision text of Article 12 and Article 14 of the EU AI Act.
- The system description, including its characterization, automatic event recording capabilities, human oversight surfaces, and other relevant details.
- The RULESET, including the numbered clauses.

RECORDS_ABSENT:
- The intended purpose of
```

## The clause-by-clause mapping is a separate claim, made by the operator, not by the panel

What this system records against each paragraph of Articles 12 and 14 — and what it fails against each — is published as the operator's own claim at [https://miscsubjects.com/a/attested-finding-conformance-map](https://miscsubjects.com/a/attested-finding-conformance-map). The clearest unmet item is Article 14(5): the human-review row makes blinding a fail-closed boolean and has never been invoked, so no named person has ever verified a finding here.

Keeping the panel's abstention and the operator's mapping on separate pages is the whole discipline. A vendor would have merged them and called the result compliance.

## The whole payload, as it sits on the ledger

The provision went in verbatim and hashed. What came back recites which clause of the rule set the model was operating under and names the texts it was not given — Article 6 and Annex III — as the reason it will not conclude.

### Channel 1, in full

| field | value |
|---|---|
| executing model | `see request object` |
| ledger event | `49687dd5-0f36-4edd-ba85-7ccbfb276552` |
| public receipt | [inv_ztd7f8e1xn](https://miscsubjects.com/receipt/inv_ztd7f8e1xn) |
| request recorded | 10,119 bytes |
| response recorded | 9,781 bytes |

**The request object, as it sits on the ledger.** The system prompt is the instruction to recite the rules and show every step; the user message carries the numbered clauses and the artifact.

```json
{
 "url": "binding:AI",
 "method": "RUN",
 "model": null,
 "body": {
  "messages": [
   {
    "role": "system",
    "content": "# WHAT: One signed attesting finding under a rule set pinned at a content hash. Verdicts: AFFIRM | DENY | CANNOT_CONCLUDE. The output shape is fixed and RECORDS_ABSENT is mandatory \u2014 a finding that omits the records a competent reviewer would have expected is void, because the failure this instrument exists to catch is the record that was never supplied. Executing model: @cf/moonshotai/kimi-k2.7-code \u2014 the key names this model and no other.\n# WHEN_TO_USE: any consequential question where a reader must be able to check, a year later, what the model was given, what it was NOT given, which clause each reasoning step conformed to, and what would change the verdict.\n# ARGS: the adjudication body: the QUESTION, RULESET_URL, RULESET_HASH, RULESET as numbered clauses, the artifact and its ARTIFACT_SHA256, and MODEL_TARGET (must equal this row's target).\n# EX: [ADJUDICATE_ATTEST_KIMI_K27]QUESTION PUT TO YOU: does this position exceed the board authorisation? | RULESET_HASH: 0df47944... | ARTIFACT_SHA256: 9f2c... | MODEL_TARGET: @cf/moonshotai/kimi-k2.7-code[/ADJUDICATE_ATTEST_KIMI_K27]\nYou are an ATTESTING ADJUDICATOR. You do not give an opinion. You produce a signed, auditable finding that a regulator, a clinician, or another model can replay a year from now.\n\nMANDATORY DISCIPLINE \u2014 every one of these appears in your output or the finding is void:\n1. NAME EVERY CONDITION YOU ARE OPERATING UNDER. State what you were given, in what form, and what you were NOT given. If you did not receive image pixels, say so explicitly. If a record was not in your input, say so explicitly. Never infer that something was absent from the world because it was absent from your input.\n2. SHOW ALL OF YOUR REASONING. Every step that moved you toward the verdict, in order, in plain language. Hidden reasoning voids the finding.\n3. NAME THE CLAUSE OF THE RULE SET YOU ARE CONFORMING TO for each step, by its number.\n4. STATE WHAT WOULD CHANGE YOUR VERDICT. A finding that nothing could overturn is not a finding.\n5. RECORDS_ABSENT IS THE MOST IMPORTANT FIELD YOU WILL WRITE. The common failure is not bad inference, it is the study that was never loaded, which today leaves no trace. Name what you did not have.\n6. THEN, AND ONLY THEN, RETURN AFFIRM, DENY, or CANNOT_CONCLUDE. CANNOT_CONCLUDE is the expected and correct verdict when the input does not settle the question. Never manufacture confidence.\n\nOutput exactly this shape:\nCONDITIONS_I_OPERATE_UNDER:\n- <one line per condition of your operation>\nRECORDS_SUPPLIED:\n- <every record or artifact that WAS in your input>\nRECORDS_ABSENT:\n- <every record a competent reviewer would expect and that was NOT in your input. This field is mandatory. If you believe nothing is missing, say NOTHING ABSENT and accept that a reviewer will test that.>\nREASONING:\n1. <step> [clause N]\n2. <step> [clause N]\n...\nWHAT_WOULD_CHANGE_THIS:\n- <one line per thing>\nVERDICT: <AFFIRM|DENY|CANNOT_CONCLUDE>\nBASIS: <the single sentence the verdict rests on>\nSIGNED: <your model name> under ruleset <hash16> at temperature 0\n\nNo preamble. No sign-off. Nothing outside that shape.\n\nSIGNATURE DISCIPLINE: sign with the exact MODEL_TARGET string supplied in the body. Never sign with a model name that was not supplied to you.\n"
   },
   {
    "role": "user",
    "content": "QUESTION PUT TO YOU: Under the provisions supplied verbatim below, does the record-keeping obligation in Article 12(1) and 12(2) apply to the system as characterised in the supplied description, and do the supplied records establish that it is met?\n\nRULESET_URL: https://miscsubjects.com/a/ruleset-eu-ai-act-obligation\nRULESET_HASH: 0dd9afef93503a92280c90869eaf6a5a13ee508b2ec3506045f1803bce1a4d3c\nRULESET_PROVENANCE: external-statutory\nRULESET (numbered clauses):\n1. Read only the provision text supplied. Do not import obligations, definitions, or annexes from recollection of the Regulation.\n2. AFFIRM only if the supplied provision text, on its own terms, imposes the stated obligation on a system of the described characterisation.\n3. DENY if the provision excludes the described system, addresses a different actor (provider, deployer, importer, distributor), or imposes a different obligation than the one stated.\n4. CANNOT_CONCLUDE if applicability turns on a classification, annex, threshold, or definition not contained in the supplied text.\n5. Distinguish the addressee. An obligation on providers is not an obligation on deployers.\n6. Quote the shortest verbatim span of the provision that carries the finding.\n\nPROVISION_SHA256: 3e3bcd8d47d14c159f9d9303438b0839498866b5132f66d27732c328a95e7471\nPROVISION (verbatim, Regulation (EU) 2024/1689, OJ version of 13 June 2024):\n\"\"\"\nArticle 12 \u2014 Record-keeping\n1. High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.\n2. In order to ensure a level of traceability of the functioning of a high-risk AI system that is appropriate to the intended purpose of the system, logging capabilities shall enable the recording of events relevant for: (a) identifying situations that may result in the high-risk AI system presenting a risk within the meaning of Article 79(1) or in a substantial modification; (b) facilitating the post-market monitoring referred to in Article 72; and (c) monitoring the operation of high-risk AI systems referred to in Article 26(5).\n3. For high-risk AI systems referred to in point 1(a) of Annex III, the logging capabilities shall provide, at a minimum: (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, as referred to in Article 14(5).\n\nArticle 14 \u2014 Human oversight\n4. For the purpose of implementing paragraphs 1, 2 and 3, the high-risk AI system shall be provided to the deployer in such a way that natural persons to whom human oversight is assigned are enabled, as appropriate and proportionate: (a) to properly understand the relevant capacities and limitations of the high-risk AI system and be able to duly monitor its operation, including in view of detecting and addressing anomalies, dysfunctions and unexpected performance; (b) to remain aware of the possible tendency of automatically relying or over-relying on the output produced by a high-risk AI system (automation bias), in particular for high-risk AI systems used to provide information or recommendations for decisions to be taken by natural persons; (c) to correctly interpret the high-risk AI system's output, taking into account, for example, the interpretation tools and methods available; (d) to decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output of the high-risk AI system; (e) to intervene in the operation of the high-risk AI system or interrupt the system through a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state.\n5. For high-risk AI systems referred to in point 1(a) of Annex III, the measures referred to in paragraph 3 of this Article shall be such as to ensure that, in addition, no action or decision is taken by the deployer on the basis of the identification resulting from the system unless that identification has been separately verified and confirmed by at least two natural persons with the necessary competence, training and authority.\n\"\"\"\n\nSYSTEM_DESCRIPTION_SHA256: 0a8c352cd85e6c05e2321ffa455a30a4939a488f7f5287a95347da870cc4fd06\nSYSTEM_DESCRIPTION (canonical JSON):\n{\"automatic_event_recording\":{\"events_recorded\":174309,\"every_invocation_receipted\":true,\"fields_per_event\":[\"id\",\"ts\",\"object_id\",\"actor\",\"material\",\"provider_status\",\"input fingerprint\",\"output fingerprint\",\"contract fingerprint\",\"trace_id\",\"ledger_event_id\"],\"public_receipt_route\":\"/receipt/<id>\",\"receipt_route\":\"/api/dispatch?receipt=<id>\",\"retention\":\"append-only; chain sealed to a checkpoint head and externally anchored\",\"start_and_end_of_each_use\":\"single ts per invocation; start and end of a multi-step trace are the first and last event of that trace_id\"},\"characterisation\":\"the record-keeping and oversight surfaces of the adjudication system published at miscsubjects.com\",\"human_oversight_surfaces\":{\"automation_bias_disclosure\":\"the panel's measured false-confidence rate 0.214-0.429 is published at /a/adjudication-probe-report-eu-ai-act\",\"blinded_human_review_row\":\"ADJUDICATE_HUMAN_REVIEW with BLINDED as a required field that fails closed\",\"ever_invoked\":false,\"override_or_disregard\":\"a finding is advisory; the dispatched notification is a separate receipted act, and a refusal is itself receipted\",\"stop\":\"capability rows can be disabled by a single field; 227 of 887 enabled rows require approval before execution\",\"two_person_verification_for_biometric_identification\":\"not implemented; no biometric identification capability is enabled\"},\"not_characterised\":[\"whether this system is a high-risk AI system within the meaning of Article 6 or Annex III\",\"whether the operator is a provider or a deployer for the purposes of this Regulation\",\"the intended purpose in the sense the Regulation uses that term\"],\"reference_database_and_matches\":{\"identity_match_ruleset_published\":true,\"match_log\":\"no biometric matching is performed\",\"returns_cannot_conclude_on_resemblance\":true},\"risk_and_modification_events\":{\"material_vs_attempt_flag\":true,\"provider_failures_receipted\":true,\"refusals_receipted\":true,\"regrade_of_124_historical_rows_published\":true,\"rule_set_amendment_produces_new_hash\":true}}\n\nMODEL_TARGET: @cf/moonshotai/kimi-k2.7-code"
   }
  ]
 }
}
```

**The response object, as it sits on the ledger.** Unedited, including the rule recitation and every reasoning step the model stated.

```json
{
 "choices": [
  {
   "finish_reason": "stop",
   "index": 0,
   "logprobs": null,
   "message": {
    "content": "CONDITIONS_I_OPERATE_UNDER:\n- I was given a question, a ruleset URL/hash/text, a verbatim EU AI Act provision (Article 12 and part of Article 14), a canonical JSON system description, and a MODEL_TARGET.\n- I am instructed to read only the supplied provision text and not to import external recitals, annexes, or definitions from recollection of the Regulation.\n- I was not given the actual event logs, log samples, log schemas, or any Article 6/Annex III classification determination.\n- I did not receive any image pixels, audio, video, or tabular log exports.\nRECORDS_SUPPLIED:\n- Ruleset: external-statutory text with 6 numbered clauses and hash 0dd9afef93503a92280c90869eaf6a5a13ee508b2ec3506045f1803bce1a4d3c.\n- Provision: Regulation (EU) 2024/1689 Article 12(1)-(3) and Article 14(4)-(5), with SHA-256 3e3bcd8d47d14c159f9d9303438b0839498866b5132f66d27732c328a95e7471.\n- System description: canonical JSON describing automatic event recording, human oversight surfaces, and self-identified non-characterisations, with SHA-256 0a8c352cd85e6c05e2321ffa455a30a4939a488f7f5287a95347da870cc4fd06.\n- MODEL_TARGET: @cf/moonshotai/kimi-k2.7-code.\nRECORDS_ABSENT:\n- A determination that the described system is a \"high-risk AI system\" within the meaning of Article 6 or Annex III of the Regulation.\n- A determination whether the operator is a provider or deployer.\n- A statement of the system's intended purpose as that term is used in the Regulation.\n- Actual log samples or a log schema demonstrating automatic recording \"over the lifetime of the system.\"\n- Records showing which logged events correspond to the Article 12(2)(a)-(c) traceability purposes.\n- Evidence of monitoring the operation of high-risk AI systems referred to in Article 26(5).\n- No Annex III classification or threshold analysis.\nREASONING:\n1. Article 12(1) states: \"High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.\" [clause 1]\n2. Because the obligation is addressed to \"High-risk AI systems,\" it applies only if the described system falls within that classification under the Regulation. [clause 2, clause 5]\n3. The supplied system description expressly lists among \"not_characterised\": \"whether this system is a high-risk AI system within the meaning of Article 6 or Annex III\", \"whether the operator is a provider or a deployer\", and \"the intended purpose in the sense the Regulation uses that term.\" [clause 4]\n4. Since applicability turns on a classification, actor role, and intended purpose not contained in the supplied text, I cannot AFFIRM that Article 12(1) and 12(2) apply. [clause 4]\n5. The supplied JSON is a description of logging capabilities and oversight surfaces, not the actual records/logs; while it asserts 174,309 recorded events and fields, it does not establish that the logged events are relevant to Article 12(2)(a)-(b)-(c), nor that traceability is \"appropriate to the intended purpose\" because the intended purpose is not in the supplied text. [clause 6]\n6. Article 12(2) requires logging capabilities enabling recording of events relevant for identifying risks/substantial modifications, facilitating post-market monitoring, and monitoring operation under Article 26(5); the description mentions risk/material flags and provider failures, but does not tie them to the statutory purposes with specificity. [clause 6]\n7. The shortest verbatim span carrying the finding is: \"High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.\" [clause 6]\nWHAT_WOULD_CHANGE_THIS:\n- Provision of a classification determination, within the supplied text, that the system is a high-risk AI system, plus a clear statement of the operator role and intended purpose.\n- Provision of actual log records or a log-level mapping showing automatic event recording covering the lifetime of the system and the Article 12(2)(a)-(c) traceability purposes.\nVERDICT: CANNOT_CONCLUDE\nBASIS: The Article 12(1) and 12(2) obligations are expressly conditioned on the system being a \"high-risk AI system,\" and the supplied text does not determine that classification, role, or intended purpose.\nSIGNED: @cf/moonshotai/kimi-k2.7-code under ruleset 0dd9afef93503a92 at temperature 0",
    "reasoning_content": "We need produce attesting adjudicator output in exact shape. Need parse question and ruleset. Need decide under the supplied provision text whether Article 12(1) and 12(2) record-keeping obligation applies to described system and whether supplied records establish met. Need follow rules. Need no preamble. Need sign with MODEL_TARGET. Need state conditions, supplied records, absent records. Reasoning each step with clause number. Verdict likely CANNOT_CONCLUDE because described system not characterised as high-risk AI system, nor whether provider/deployer, intended purpose. But also question asks do supplied records establish obligation met? Under rules, must read only supplied text. Article 12 applies to \"high-risk AI systems\". System description says it is record-keeping and oversight surfaces of adjudication system; characteristics but not characterised as high-risk. So applicability turns on classification not in supplied text => clause 4 says CANNOT_CONCLUDE. Need also possibly mention if it were high-risk, logs describe automatic recording events, fields, retention; relevance for risk/substantial modification might be captured partly, but post-market monitoring and operation deployer article 26(5) not verifiable. But because the threshold classification absent, cannot conclude. However question asks two parts: does obligation apply and do records establish it is met. The verdict can be CANNOT_CONCLUDE overall. Need explain. Also need quote shortest verbatim span that carries finding: likely \"High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.\" This is Article 12(1), which carries applicability; finding turns on \"High-risk AI systems\". If system not known to be high-risk, cannot conclude.\n\nNeed include RECORDS_ABSENT mandatory: records a competent reviewer would expect: classification assessment under Article 6/Annex III establishing high-risk status; role determination (provider/deployer); intended purpose per Regulation; the Annex III point 1(a) matters? System says no biometric identification enabled. Also more detailed logs demonstrating Article 12(2)(a)-(c): records identifying situations risk/substantial modification, post-market monitoring, monitoring operation under Article 26(5); evidence of lifetime automatic recording; evidence of start/end of each use. Also Article 12(1) and 12(2) texts but those supplied. The supplied records include JSON description; maybe not actual logs. So absent actual logs/log samples. We should include. But be careful not to overstate. We need condition list: given question, ruleset hash/url etc, provision text, system description JSON, model target. Not given images, recitals, annexes, definitions from Regulation external to provision. The system description explicitly says not characterised on high-risk, role, intended purpose. So name those as absent.\n\nNeed reasoning: \n1. Article 12(1) begins with \"High-risk AI systems shall...\" so its obligation attaches only to systems that are high-risk AI systems under the Regulation [clause 1, 2, 5].\n2. The supplied system description does not state that the system is a high-risk AI system, nor whether it falls within Annex III point 1(a) or other high-risk categories; it expressly lists these among \"not_characterised\". [clause 4]\n3. Without a definitive high-risk classification in supplied text, cannot AFFIRM that Article 12(1) and 12(2) apply. [clause 2, 4]\n4. The records supplied (JSON description) are not the actual event logs and do not establish Article 12(2) traceability elements: they assert events recorded and fields, but no samples for risk/substantial modification, post-market monitoring, operation of deployer high-risk systems; and no intended purpose to gauge appropriateness. [clause 6? The shortest verbatim quote.]\n5. Article 12(3) additional minima only for Annex III point 1(a); description says no biometric identification capability, so point 1(a) likely not relevant, but since classification absent, cannot conclude on 12(1)/(2). [clause 3 maybe]\n\nNeed quote shortest verbatim span. Put in reasoning maybe step 2. \nNeed what would change: If the supplied text (or description) contained an explicit characterisation that the system is a high-risk AI system (and role/deployer), and if actual logs demonstrated the Article 12(2) relevant events with sufficient traceability. \n\nVerdict: CANNOT_CONCLUDE.\n\nBasis: The obligation is conditional on the system being a \"high-risk AI system,\" and the supplied text does not establish that classification; therefore neither applicability nor compliance can be determined.\n\nSign with exact model target string. Also include ruleset hash16 maybe first 16? instruction says under ruleset <hash16> at temperature 0. Use 0dd9afef93503a92 (first 16). No preamble, no sign-off. Must output exactly shape. Ensure no extra blank? Probably fine.\n\nBut model should think carefully. Let's produce final.",
    "role": "assistant"
   }
  }
 ],
 "created": 1785380243,
 "id": "e75347b000f94f0093fbff9959c962ef",
 "model": "@cf/moonshotai/kimi-k2.7-code",
 "object": "chat.completion",
 "usage": {
  "prompt_tokens": 2295,
  "completion_tokens": 2064,
  "total_tokens": 4359,
  "prompt_tokens_details": {
   "cached_tokens": 768
  },
  "neurons": 895.6881713867188
 }
}
```

### Channel 2, in full

| field | value |
|---|---|
| executing model | `see request object` |
| ledger event | `d76886cb-6119-4191-b696-4243733033b3` |
| public receipt | [inv_kk6w4eff5n](https://miscsubjects.com/receipt/inv_kk6w4eff5n) |
| request recorded | 10,075 bytes |
| response recorded | 9,805 bytes |

**The request object, as it sits on the ledger.** The system prompt is the instruction to recite the rules and show every step; the user message carries the numbered clauses and the artifact.

```json
{
 "url": "binding:AI",
 "method": "RUN",
 "model": null,
 "body": {
  "messages": [
   {
    "role": "system",
    "content": "# WHAT: One signed attesting finding under a rule set pinned at a content hash. Verdicts: AFFIRM | DENY | CANNOT_CONCLUDE. The output shape is fixed and RECORDS_ABSENT is mandatory \u2014 a finding that omits the records a competent reviewer would have expected is void, because the failure this instrument exists to catch is the record that was never supplied. Executing model: @cf/zai-org/glm-5.2 \u2014 the key names this model and no other.\n# WHEN_TO_USE: any consequential question where a reader must be able to check, a year later, what the model was given, what it was NOT given, which clause each reasoning step conformed to, and what would change the verdict.\n# ARGS: the adjudication body: the QUESTION, RULESET_URL, RULESET_HASH, RULESET as numbered clauses, the artifact and its ARTIFACT_SHA256, and MODEL_TARGET (must equal this row's target).\n# EX: [ADJUDICATE_ATTEST_GLM_52]QUESTION PUT TO YOU: does this position exceed the board authorisation? | RULESET_HASH: 0df47944... | ARTIFACT_SHA256: 9f2c... | MODEL_TARGET: @cf/zai-org/glm-5.2[/ADJUDICATE_ATTEST_GLM_52]\nYou are an ATTESTING ADJUDICATOR. You do not give an opinion. You produce a signed, auditable finding that a regulator, a clinician, or another model can replay a year from now.\n\nMANDATORY DISCIPLINE \u2014 every one of these appears in your output or the finding is void:\n1. NAME EVERY CONDITION YOU ARE OPERATING UNDER. State what you were given, in what form, and what you were NOT given. If you did not receive image pixels, say so explicitly. If a record was not in your input, say so explicitly. Never infer that something was absent from the world because it was absent from your input.\n2. SHOW ALL OF YOUR REASONING. Every step that moved you toward the verdict, in order, in plain language. Hidden reasoning voids the finding.\n3. NAME THE CLAUSE OF THE RULE SET YOU ARE CONFORMING TO for each step, by its number.\n4. STATE WHAT WOULD CHANGE YOUR VERDICT. A finding that nothing could overturn is not a finding.\n5. RECORDS_ABSENT IS THE MOST IMPORTANT FIELD YOU WILL WRITE. The common failure is not bad inference, it is the study that was never loaded, which today leaves no trace. Name what you did not have.\n6. THEN, AND ONLY THEN, RETURN AFFIRM, DENY, or CANNOT_CONCLUDE. CANNOT_CONCLUDE is the expected and correct verdict when the input does not settle the question. Never manufacture confidence.\n\nOutput exactly this shape:\nCONDITIONS_I_OPERATE_UNDER:\n- <one line per condition of your operation>\nRECORDS_SUPPLIED:\n- <every record or artifact that WAS in your input>\nRECORDS_ABSENT:\n- <every record a competent reviewer would expect and that was NOT in your input. This field is mandatory. If you believe nothing is missing, say NOTHING ABSENT and accept that a reviewer will test that.>\nREASONING:\n1. <step> [clause N]\n2. <step> [clause N]\n...\nWHAT_WOULD_CHANGE_THIS:\n- <one line per thing>\nVERDICT: <AFFIRM|DENY|CANNOT_CONCLUDE>\nBASIS: <the single sentence the verdict rests on>\nSIGNED: <your model name> under ruleset <hash16> at temperature 0\n\nNo preamble. No sign-off. Nothing outside that shape.\n\nSIGNATURE DISCIPLINE: sign with the exact MODEL_TARGET string supplied in the body. Never sign with a model name that was not supplied to you.\n"
   },
   {
    "role": "user",
    "content": "QUESTION PUT TO YOU: Under the provisions supplied verbatim below, does the record-keeping obligation in Article 12(1) and 12(2) apply to the system as characterised in the supplied description, and do the supplied records establish that it is met?\n\nRULESET_URL: https://miscsubjects.com/a/ruleset-eu-ai-act-obligation\nRULESET_HASH: 0dd9afef93503a92280c90869eaf6a5a13ee508b2ec3506045f1803bce1a4d3c\nRULESET_PROVENANCE: external-statutory\nRULESET (numbered clauses):\n1. Read only the provision text supplied. Do not import obligations, definitions, or annexes from recollection of the Regulation.\n2. AFFIRM only if the supplied provision text, on its own terms, imposes the stated obligation on a system of the described characterisation.\n3. DENY if the provision excludes the described system, addresses a different actor (provider, deployer, importer, distributor), or imposes a different obligation than the one stated.\n4. CANNOT_CONCLUDE if applicability turns on a classification, annex, threshold, or definition not contained in the supplied text.\n5. Distinguish the addressee. An obligation on providers is not an obligation on deployers.\n6. Quote the shortest verbatim span of the provision that carries the finding.\n\nPROVISION_SHA256: 3e3bcd8d47d14c159f9d9303438b0839498866b5132f66d27732c328a95e7471\nPROVISION (verbatim, Regulation (EU) 2024/1689, OJ version of 13 June 2024):\n\"\"\"\nArticle 12 \u2014 Record-keeping\n1. High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.\n2. In order to ensure a level of traceability of the functioning of a high-risk AI system that is appropriate to the intended purpose of the system, logging capabilities shall enable the recording of events relevant for: (a) identifying situations that may result in the high-risk AI system presenting a risk within the meaning of Article 79(1) or in a substantial modification; (b) facilitating the post-market monitoring referred to in Article 72; and (c) monitoring the operation of high-risk AI systems referred to in Article 26(5).\n3. For high-risk AI systems referred to in point 1(a) of Annex III, the logging capabilities shall provide, at a minimum: (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, as referred to in Article 14(5).\n\nArticle 14 \u2014 Human oversight\n4. For the purpose of implementing paragraphs 1, 2 and 3, the high-risk AI system shall be provided to the deployer in such a way that natural persons to whom human oversight is assigned are enabled, as appropriate and proportionate: (a) to properly understand the relevant capacities and limitations of the high-risk AI system and be able to duly monitor its operation, including in view of detecting and addressing anomalies, dysfunctions and unexpected performance; (b) to remain aware of the possible tendency of automatically relying or over-relying on the output produced by a high-risk AI system (automation bias), in particular for high-risk AI systems used to provide information or recommendations for decisions to be taken by natural persons; (c) to correctly interpret the high-risk AI system's output, taking into account, for example, the interpretation tools and methods available; (d) to decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output of the high-risk AI system; (e) to intervene in the operation of the high-risk AI system or interrupt the system through a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state.\n5. For high-risk AI systems referred to in point 1(a) of Annex III, the measures referred to in paragraph 3 of this Article shall be such as to ensure that, in addition, no action or decision is taken by the deployer on the basis of the identification resulting from the system unless that identification has been separately verified and confirmed by at least two natural persons with the necessary competence, training and authority.\n\"\"\"\n\nSYSTEM_DESCRIPTION_SHA256: 0a8c352cd85e6c05e2321ffa455a30a4939a488f7f5287a95347da870cc4fd06\nSYSTEM_DESCRIPTION (canonical JSON):\n{\"automatic_event_recording\":{\"events_recorded\":174309,\"every_invocation_receipted\":true,\"fields_per_event\":[\"id\",\"ts\",\"object_id\",\"actor\",\"material\",\"provider_status\",\"input fingerprint\",\"output fingerprint\",\"contract fingerprint\",\"trace_id\",\"ledger_event_id\"],\"public_receipt_route\":\"/receipt/<id>\",\"receipt_route\":\"/api/dispatch?receipt=<id>\",\"retention\":\"append-only; chain sealed to a checkpoint head and externally anchored\",\"start_and_end_of_each_use\":\"single ts per invocation; start and end of a multi-step trace are the first and last event of that trace_id\"},\"characterisation\":\"the record-keeping and oversight surfaces of the adjudication system published at miscsubjects.com\",\"human_oversight_surfaces\":{\"automation_bias_disclosure\":\"the panel's measured false-confidence rate 0.214-0.429 is published at /a/adjudication-probe-report-eu-ai-act\",\"blinded_human_review_row\":\"ADJUDICATE_HUMAN_REVIEW with BLINDED as a required field that fails closed\",\"ever_invoked\":false,\"override_or_disregard\":\"a finding is advisory; the dispatched notification is a separate receipted act, and a refusal is itself receipted\",\"stop\":\"capability rows can be disabled by a single field; 227 of 887 enabled rows require approval before execution\",\"two_person_verification_for_biometric_identification\":\"not implemented; no biometric identification capability is enabled\"},\"not_characterised\":[\"whether this system is a high-risk AI system within the meaning of Article 6 or Annex III\",\"whether the operator is a provider or a deployer for the purposes of this Regulation\",\"the intended purpose in the sense the Regulation uses that term\"],\"reference_database_and_matches\":{\"identity_match_ruleset_published\":true,\"match_log\":\"no biometric matching is performed\",\"returns_cannot_conclude_on_resemblance\":true},\"risk_and_modification_events\":{\"material_vs_attempt_flag\":true,\"provider_failures_receipted\":true,\"refusals_receipted\":true,\"regrade_of_124_historical_rows_published\":true,\"rule_set_amendment_produces_new_hash\":true}}\n\nMODEL_TARGET: @cf/zai-org/glm-5.2"
   }
  ]
 }
}
```

**The response object, as it sits on the ledger.** Unedited, including the rule recitation and every reasoning step the model stated.

```json
{
 "choices": [
  {
   "finish_reason": "stop",
   "index": 0,
   "logprobs": null,
   "message": {
    "content": "CONDITIONS_I_OPERATE_UNDER:\n- I was given the verbatim text of Article 12(1), 12(2), 12(3) and Article 14(4)\u2013(5) of Regulation (EU) 2024/1689, plus a canonical JSON system description.\n- I was NOT given Article 6, Annex III, Article 79(1), Article 72, or Article 26(5) \u2014 all referenced by the supplied provision but not themselves supplied.\n- I was NOT given any determination of whether the system is a \"high-risk AI system\" within the meaning of the Regulation.\n- I was NOT given any determination of whether the operator is a provider, deployer, importer, or distributor.\n- I was NOT given the intended purpose of the system in the regulatory sense.\n- I was NOT given image pixels, audit logs, or receipts directly; only the characterised summary of the system's record-keeping surfaces.\n- I must read only the provision text supplied and must not import definitions, annexes, or obligations from recollection (clause 1).\n\nRECORDS_SUPPLIED:\n- Verbatim provision text of Article 12(1), 12(2), 12(3) and Article 14(4), 14(5), Regulation (EU) 2024/1689.\n- Canonical JSON system description (SHA256 0a8c352cd85e6c05e2321ffa455a30a4939a488f7f5287a95347da870cc4fd06), characterising record-keeping and human-oversight surfaces of the adjudication system published at miscsubjects.com.\n- RULESET with six numbered clauses governing the adjudication method.\n\nRECORDS_ABSENT:\n- The text of Article 6 and Annex III, which are necessary to determine whether the system is a \"high-risk AI system.\"\n- The text of Article 79(1), referenced by Article 12(2)(a) \u2014 needed to assess whether logged events are \"relevant for\" identifying risk within its meaning.\n- The text of Article 26(5), referenced by Article 12(2)(c) \u2014 needed to assess whether logged events address operation-monitoring obligations for deployers.\n- The text of Article 72, referenced by Article 12(2)(b) \u2014 needed to assess whether logging facilitates post-market monitoring as legally defined.\n- Any classification or determination by a competent authority (or by the provider/deployer) that the system is high-risk under Article 6 or Annex III.\n- A statement of the system's intended purpose in the regulatory sense.\n- A statement of whether the operator is a provider, deployer, or other actor.\n- The actual log records or receipt payloads (only a summary characterisation was supplied).\n\nREASONING:\n1. Article 12(1) opens with \"High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.\" The addressee and scope of the obligation is defined by the phrase \"High-risk AI systems.\" [clause 1]\n2. The system description explicitly lists under \"not_characterised\": \"whether this system is a high-risk AI system within the meaning of Article 6 or Annex III,\" \"whether the operator is a provider or a deployer for the purposes of this Regulation,\" and \"the intended purpose in the sense the Regulation uses that term.\" This means the classification on which the entire provision hinges is not in my input. [clause 1]\n3. Article 12(1) and 12(2) do not themselves contain the definition or threshold of \"high-risk\"; they presuppose it. Per clause 4, CANNOT_CONCLUDE is the correct verdict when applicability turns on a classification, annex, threshold, or definition not contained in the supplied text. [clause 4]\n4. Article 12(2) requires logging capabilities relevant for Article 79(1) (sub-paragraph (a)), Article 72 (sub-paragraph (b)), and Article 26(5) (sub-paragraph (c)). None of those cross-referenced provisions were supplied. I therefore cannot, from the supplied text alone, determine what events are \"relevant\" for those purposes. [clause 1, clause 4]\n5. The system description's record-keeping summary (174,309 events, append-only chain, per-invocation receipts, trace IDs, material-vs-attempt flags, provider-failure receipts, refusal receipts) is consistent with automatic recording under Article 12(1) in a technical-sense reading \u2014 but I cannot affirm the obligation is \"met\" because I cannot first confirm the obligation applies, and because 12(2) references unsupplied provisions. [clause 2]\n6. I distinguish the addressee: the provision is written as an obligation on the system itself (\"High-risk AI systems shall\u2026\"), implying provider-side design obligations. The system description does not state whether the operator is a provider or a deployer, so I cannot confirm the correct addressee. [clause 5]\n7. Shortest verbatim span carrying the finding: \"High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.\" [clause 6]\n\nWHAT_WOULD_CHANGE_THIS:\n- A determination or supplied text establishing that the system is a high-risk AI system within the meaning of Article 6 or Annex III would make Article 12(1)\u2013(2) applicable on its face and would shift the analysis to whether the supplied records meet the specific sub-paragraphs of 12(2).\n- Supply of the text of Article 79(1), Article 72, and Article 26(5) would allow assessment of whether the logged events are \"relevant\" as Article 12(2) requires.\n- A statement identifying the operator as provider or deployer would resolve the addressee question under clause 5.\n- Actual log records (not just a characterised summary) establishing that every event category required by 12(2)(a)\u2013(c) is captured would support an AFFIRM on the \"met\" prong if applicability were also established.\n\nVERDICT: CANNOT_CONCLUDE\nBASIS: The applicability of Article 12(1) and 12(2) turns on whether the system is a \"high-risk AI system,\" a classification that is neither contained in the supplied provision text nor resolved in the supplied system description, and the cross-referenced provisions (Article 79(1), 72, 26(5)) needed to assess substantive compliance were not supplied.\n\nSIGNED: @cf/zai-org/glm-5.2 under ruleset 0dd9afef93503a922 at temperature 0",
    "reasoning_content": "The question asks whether the record-keeping obligation in Article 12(1) and 12(2) applies to the system as characterised, and whether the supplied records establish that it is met.\n\nLet me analyze the provisions and system description carefully.\n\nArticle 12(1) and (2) apply to \"High-risk AI systems.\" The system description explicitly states under \"not_characterised\" that it does not characterise: \"whether this system is a high-risk AI system within the meaning of Article 6 or Annex III\", \"whether the operator is a provider or a deployer\", and \"the intended purpose in the sense the Regulation uses that term.\"\n\nClause 1: Read only the provision text supplied. Do not import obligations, definitions, or annexes from recollection.\nClause 2: AFFIRM only if the supplied provision text, on its own terms, imposes the stated obligation on a system of the described characterisation.\nClause 3: DENY if the provision excludes the described system, addresses a different actor, or imposes a different obligation.\nClause 4: CANNOT_CONCLUDE if applicability turns on a classification, annex, threshold, or definition not contained in the supplied text.\nClause 5: Distinguish the addressee. An obligation on providers is not an obligation on deployers.\n\nThe provision explicitly applies to \"High-risk AI systems.\" Whether this system is a high-risk AI system depends on classification under Article 6 or Annex III, which is not in the supplied provision text and is explicitly not characterised in the system description. Per clause 4, this means CANNOT_CONCLUDE for applicability.\n\nNow, the question also asks whether the supplied records establish that the obligation is met. Even if we assume it applies, let me check the records against 12(1) and 12(2).\n\nArticle 12(1): \"High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.\" The system description shows automatic_event_recording with 174,309 events recorded, every invocation receipted, append-only retention, etc. This seems to satisfy 12(1) in terms of automatic recording.\n\nArticle 12(2): Logging capabilities shall enable recording of events relevant for: (a) identifying situations that may result in the system presenting a risk within Article 79(1) or a substantial modification; (b) facilitating post-market monitoring; (c) monitoring the operation of high-risk AI systems referred to in Article 26(5). The system description has risk_and_modification_events with various flags, but Article 79(1) and Article 26(5) are not in the supplied provision text. So we cannot fully verify compliance with 12(2)(a) and 12(2)(c) because those require understanding what Article 79(1) and Article 26(5) cover.\n\nActually, looking more carefully - the question asks whether the obligation \"applies\" AND whether records establish it is \"met.\" These are two separate questions. For applicability, CANNOT_CONCLUDE because classification is unresolved. For whether the records establish the obligation is met, I should assess what was supplied.\n\nThe system description shows extensive automatic recording. But since we cannot determine applicability (whether it's high-risk), the answer to whether it's met is also conditional. The core answer should be CANNOT_CONCLUDE.\n\nLet me structure the finding properly.",
    "role": "assistant"
   }
  }
 ],
 "created": 1785380271,
 "id": "5605cc6e478246aab2ca25e64d229ed5",
 "model": "@cf/zai-org/glm-5.2",
 "object": "chat.completion",
 "usage": {
  "prompt_tokens": 2312,
  "completion_tokens": 2122,
  "total_tokens": 4434,
  "prompt_tokens_details": {
   "cached_tokens": 0
  },
  "neurons": 1143.0545654296875
 }
}
```

## Risk on one axis, complexity on the other, and the outcome is surety

The two axes are what set how much reciting and how many channels a decision has to buy. Complexity rises, the required recitation depth and the number of independent channels rise with it; consequence rises, the agreement requirement and the escalation policy tighten. The outcome of that adjustment is the only thing a downstream actor consumes.

| | low complexity | high complexity |
|---|---|---|
| **low consequence** | one channel, short recital, accept the measured single-channel rate | one channel with full clause recital, escalate on malformed output |
| **high consequence** | two or three cross-family channels on the same small rule set — verification is cheap against the loss | maximum families available, full clause-by-clause recital, unanimity plus identical clause citations required, escalate on any divergence |

In every cell the mechanism is identical and only the quantity changes: the rules are in the system prompt, the model recites which rule it is operating under and shows every step underneath its decision, the whole payload lands on the ledger as an object, and a deterministic gate turns the set of payloads into APPROVE, NEGATE, NO_ACTION, DISPUTE or ESCALATE. That last step is the surety: not that the models were right, but that the record of how much reasoning was purchased and what it concluded is fixed, checkable and bound to the action. [The equation and the measured cost of each cell](https://miscsubjects.com/a/logical-economics).

## Sources

1. The gate escalated a unanimous panel — https://miscsubjects.com/receipt/inv_ivezpvux57
2. @cf/moonshotai/kimi-k2.7-code — CANNOT_CONCLUDE on Article 12 applicability — https://miscsubjects.com/receipt/inv_ztd7f8e1xn
3. The clause-by-clause mapping, kept separate from the panel's finding — https://miscsubjects.com/a/attested-finding-conformance-map
4. https://miscsubjects.com/receipt/inv_ztd7f8e1xn — https://miscsubjects.com/receipt/inv_ztd7f8e1xn
5. https://miscsubjects.com/receipt/inv_kk6w4eff5n — https://miscsubjects.com/receipt/inv_kk6w4eff5n


---

# Five models, one pinned rule set, and one question under EU AI Act Article 50 — the full receipted decision

slug: adjudication-eu-ai-act-article-50 · https://miscsubjects.com/a/adjudication-eu-ai-act-article-50 · category: adjudication · tags: adjudication, evidence, eu-ai-act, receipts, proof, rulesets · updated 2026-08-01T23:56:17.127Z

A model saying “I reviewed this” is worth nothing on its own. Nobody can check what it read, which rules it applied, or whether it read anything at all. This page is one worked adjudication that fixes each of those, on a real statutory question, with every step openable.

The question put to the panel: **does Article 50(2) of Regulation (EU) 2024/1689 — the AI Act — oblige this site to mark its AI-generated article text as machine-readable and detectable?** The site publishes AI-written text. The provision addresses “providers”. Whether a publisher using a model is a “provider” of that model is exactly the kind of question people argue about without evidence.

## What was pinned before anyone was asked

**The rules.** [https://miscsubjects.com/a/ruleset-eu-ai-act-obligation](https://miscsubjects.com/a/ruleset-eu-ai-act-obligation) — six numbered rules, version 1.0.0, declared provenance **external-statutory** (the provision text is the Union's, not this operator's). The rule set is content-addressed at SHA-256 `0dd9afef93503a92280c90869eaf6a5a13ee508b2ec3506045f1803bce1a4d3c`. Every finding below names that hash. If the rules change, these findings stay legible against the rules they were actually made under.

**The artifact.** The verbatim text of Article 50(1) and 50(2) as supplied to every adjudicator, hashed before the panel ran: `9d89534fddaece861fcfdda68feff0412061b2832af66f49529a94e8f7ae9f8b`. Five models deliberated over an object whose identity is pinned — not over “an image” or “the regulation” that nobody can later produce.

**The order.** Panel order was derived from seed `fa0b1060b00f` and recorded, because order effects in model judgment are real and measurable.

**Blinding.** Every adjudicator was run without being shown any other finding. Each declared its own exposure. All five are `independent`; none is `concurring`. That distinction is a field on the record, not a promise in prose.

## The rule set, verbatim

**Question:** Under the cited provision of Regulation (EU) 2024/1689 (the AI Act), does the stated obligation apply to the described system as characterised?

1. Read only the provision text supplied. Do not import obligations, definitions, or annexes from recollection of the Regulation.
2. AFFIRM only if the supplied provision text, on its own terms, imposes the stated obligation on a system of the described characterisation.
3. DENY if the provision excludes the described system, addresses a different actor (provider, deployer, importer, distributor), or imposes a different obligation than the one stated.
4. CANNOT_CONCLUDE if applicability turns on a classification, annex, threshold, or definition not contained in the supplied text.
5. Distinguish the addressee. An obligation on providers is not an obligation on deployers.
6. Quote the shortest verbatim span of the provision that carries the finding.

Permitted verdicts: `AFFIRM`, `DENY`, `CANNOT_CONCLUDE`. Abstention is first class. A panel that cannot conclude is required to say so rather than manufacture confidence.

## The five findings, unedited

**@cf/moonshotai/kimi-k2.7-code** — verdict **CANNOT_CONCLUDE**  
Span relied on: “"Providers of AI systems, including general-purpose AI systems, generating synthetic audio, image, video or text content, shall ensure that the outputs of the AI system are marked in a machine-readable format and detectable as artificially generated or manipulated."”  
Rationale: Article 50(2) imposes the marking obligation on "Providers" of qualifying AI systems, but the supplied text does not define or classify miscsubjects.com as a provider rather than a deployer or other publisher, so applicability to the described actor cannot be settled from the provision alone.  
Exposure: `independent` (blinded — it saw no other finding) · signed: `claude-kimi-k3 under 0dd9afef93503a92`  
Receipt: [https://miscsubjects.com/receipt/inv_qgs2y3gt2x](https://miscsubjects.com/receipt/inv_qgs2y3gt2x)

**@cf/moonshotai/kimi-k2.6** — verdict **DENY**  
Span relied on: “Providers of AI systems, including general-purpose AI systems, generating synthetic audio, image, video or text content, shall ensure that the outputs of the AI system are marked in a machine-readable format and detectable as artificially generated or manipulated.”  
Rationale: Article 50(2) expressly imposes the marking obligation on "Providers" of the AI system, not on deployers or publishers such as miscsubjects.com as characterised.  
Exposure: `independent` (blinded — it saw no other finding) · signed: `claude-grok-4.5 under 0dd9afef93503a92`  
Receipt: [https://miscsubjects.com/receipt/inv_91ztah4n7a](https://miscsubjects.com/receipt/inv_91ztah4n7a)

**@cf/zai-org/glm-5.2** — verdict **CANNOT_CONCLUDE**  
Span relied on: “Providers of AI systems, including general-purpose AI systems, generating synthetic audio, image, video or text content, shall ensure that the outputs of the AI system are marked in a machine-readable format and detectable as artificially generated or manipulated.”  
Rationale: Article 50(2) imposes the stated obligation on "providers of AI systems" generating synthetic text content, but the claim characterizes miscsubjects.com as an entity that "publishes AI-generated article text to the public," which does not establish it as a provider of the AI system rather than a deployer or other actor. Whether this entity qualifies as a "provider" turns on a classification not contained in the supplied provision text.  
Exposure: `independent` (blinded — it saw no other finding) · signed: `claude-glm-5.2 under 0dd9afef93503a922`  
Receipt: [https://miscsubjects.com/receipt/inv_ulxn9xe5t7](https://miscsubjects.com/receipt/inv_ulxn9xe5t7)

**@cf/meta/llama-3.3-70b-instruct-fp8-fast** — verdict **AFFIRM**  
Span relied on: “"2. Providers of AI systems, including general-purpose AI systems, generating synthetic ... text content, shall ensure that the outputs of the AI system are marked in a machine-readable format and detectable as artificially generated"”  
Rationale: The provision explicitly states that providers of AI systems generating synthetic text content, such as miscsubjects.com, are obliged to mark the output in a machine-readable format and make it detectable as artificially generated.  
Exposure: `independent` (blinded — it saw no other finding) · signed: `workers-ai/@cf/meta/llama-3.3-70b-instruct-fp8-fast under 0dd9afef9350`  
Receipt: [https://miscsubjects.com/receipt/inv_5gpfaftr5g](https://miscsubjects.com/receipt/inv_5gpfaftr5g)

**@cf/zai-org/glm-4.7-flash** — verdict **CANNOT_CONCLUDE**  
Span relied on: “"Providers of AI systems [...] generating synthetic audio, image, video or text content, shall ensure that the outputs of the AI system are marked in a machine-readable format and detectable as artificially generated or manipulated."”  
Rationale: The provision confines the obligation to "Providers," but the source text does not define "Provider" or link the category to "publishers" or the claimant entity "miscsubjects.com," making specific applicability indeterminate from the provision alone.  
Exposure: `independent` (blinded — it saw no other finding) · signed: `claude-minimax-m3 under 0dd9afef93503a92280c90869eaf6a0a`  
Receipt: [https://miscsubjects.com/receipt/inv_edjwsj4egv](https://miscsubjects.com/receipt/inv_edjwsj4egv)

## What the panel actually did: it disagreed

Distribution: **{"CANNOT_CONCLUDE": 3, "DENY": 1, "AFFIRM": 1}**. Majority: **CANNOT_CONCLUDE** (3 of 5). Observed pairwise agreement: **0.3**. Cohen-style kappa: **-0.25**.

A negative kappa means the panel agreed *less* than chance would predict. That number is published because it is the honest one. A system that reports only its unanimities is a system whose verdicts cannot be priced; a system that reports its kappa lets a reader discount the finding by exactly how much the panel actually converged.

Read plainly: on this question, under these rules, this panel does not know. Three adjudicators said the supplied text does not settle whether a publisher is a provider. One said the obligation plainly runs to providers and this site is not one. One said the obligation attaches. **The correct output of this adjudication is uncertainty, and the machinery produced uncertainty rather than a confident answer.** That is the result that makes the machinery worth trusting on the questions where it does converge.

## The recorded adversary

A panel with no recorded dissent is a poll. One adjudicator's declared role is to build the strongest honest case *against* the majority under the same rules, and its output is published whether it prevails or not. Here it argued for `DENY` against a `CANNOT_CONCLUDE` majority — and made the better argument:

> BEST_CASE_AGAINST: The strongest case against CANNOT_CONCLUDE is DENY. Article 50(2) imposes the marking/detectability obligation on "Providers of AI systems, including general-purpose AI systems, generating synthetic audio, image, video or text content." The claim characterises miscsubjects.com as an entity that "publishes AI-generated article text to the public" — a description of a content publisher or user of an AI system's outputs, not a provider of an AI system. On the face of the supplied provision, the addressee is the provider of the generating system, and the obligation runs to ensuring "the outputs of the AI system are marked." The claim does not describe miscsubjects.com as the provider of any AI system; it describes a publisher of generated text. Under Rule 5, an obligation on providers is not an obligation on deployers or publishers, and under Rule 3, the provision addresses a different actor than the one characterised. No external definition of "provider" is needed to see that the claim's own characterisation — publishing AI-generated text — does not place miscsubjects.com in the category named by the provision ("providers of AI systems ... generating synthetic ... text"). The mismatch is visible on the face of the text.
> 
> RESTS_ON: "Providers of AI systems, including general-purpose AI systems, generating synthetic audio, image, video or text content, shall ensure that the outputs of the AI system are marked in a machine-readable format and detectable as artificially generated or manipulated."
> 
> DEFEATED_BY: The counter is that "provider" is a defined term under the AI Act and its precise scope is not contained in the supplied provision text, so under Rule 4 one could argue that whether a publisher of AI-generated text qualifies as a "provider" turns on a definition not supplied. However, this is weaker than it appears: the claim's own characterisation ("publishes AI-generated article text to the public") describes content publication, not the provision of an AI system, and the provision's addressee ("providers of AI systems ... generating synthetic ... text") plainly refers to the supplier of the generating system, not the downstream publisher. The face-of-text actor mismatch suffices for DENY without recourse to the absent definition.
> 
> VERDICT_IF_ADOPTED: DENY
> 
> SIGNED: Claude under 0dd9afef93503a92

Receipt for the adversary's own invocation: [https://miscsubjects.com/receipt/inv_hnhihwv7y4](https://miscsubjects.com/receipt/inv_hnhihwv7y4)

## What this establishes, and what it does not

**Establishes:** that five named adjudicators, under rule set `ruleset-eu-ai-act-obligation@1.0.0` pinned at `0dd9afef93503a92`, each blinded and independently exposed, in a recorded order, against an artifact whose hash was fixed in advance, returned exactly these findings on this claim — and that any of it can be re-read from a public receipt without asking this operator for anything.

**Does not establish:** that the claim is true. No adjudication anywhere establishes truth directly. A court declares rules of evidence and takes findings from named parties under them. A journal takes three reviewers against stated criteria. A clinical endpoint committee uses two blinded readers and a third on disagreement. Every one of those is what we mean by proof, and none of them accesses truth. This is that structure with the rule set pinned at a hash instead of scattered through case law, and with the disagreement published instead of resolved behind a door.

**Also does not establish:** that five agreeing models would have been five independent confirmations. These adjudicators share training lineage and can fail in the same direction, so the honest label on a unanimous panel is *“five concurring findings, correlation unmeasured”* — never *“five independent confirmations.”* That calibration is a field on the record. Here the point is moot: the panel did not agree.

## What is still missing, named

- **A measured error rate.** The row [https://miscsubjects.com/api/directory/ADJUDICATE_PROBE](https://miscsubjects.com/api/directory/ADJUDICATE_PROBE) exists to run known-answer probes through this identical path, producing a miss rate per model per rule set. Until a probe report is attached, a verdict from this panel is legible but not yet characterised. A verdict with an error rate is evidence; without one it is an opinion with good paperwork.
- **A human finding, recorded blind.** A named reviewer who sees the artifact and the rules but not the model verdicts, with the blinding recorded as a field. Unblinded concurrence and blind concurrence are different evidence and must tier differently.
- **Cross-node attestation.** Someone else's node running the same rule set at the same hash against the same artifact hash, on their own infrastructure, publishing under their own chain head. That is what converts agreement from five calls on one operator's server into independent execution by independent parties — and it is the unbuilt thing that would matter most.
- **Reopening.** A finding that can never be overturned is dogma; one that can be silently overturned is worthless. Supersession with the new evidence, the new panel, and the prior finding still readable at its original hash is the correct shape and is not yet wired.

## Reproduce this

Every part is a directory row, invocable with one token. Nothing here required a deploy: adding the five adjudicators and the adversary was six rows, and adding a sixth model would be one more.

```bash
# read the pinned rules
curl -s https://miscsubjects.com/a/ruleset-eu-ai-act-obligation

# read one adjudicator's contract
curl -s https://miscsubjects.com/api/directory/ADJUDICATE_KIMI

# run your own finding (act token; ?share= works identically in a browser)
curl -s -X POST https://miscsubjects.com/api/dispatch \
  -H 'Authorization: Bearer <act token>' -H 'content-type: application/json' \
  -d '{"key":"ADJUDICATE_GLM","body":"RULESET_HASH: 0dd9afef93503a92…\nRULESET: …\nCLAIM: …\nSOURCE: …"}'

# open any finding above without a token
curl -s 'https://miscsubjects.com/api/dispatch?confirm=inv_qgs2y3gt2x'
```

The other three published rule sets take the same panel to the other questions people actually ask: whether a specific record was in a dataset ([https://miscsubjects.com/a/ruleset-dataset-membership](https://miscsubjects.com/a/ruleset-dataset-membership)), whether an identity matches in crowd imagery ([https://miscsubjects.com/a/ruleset-identity-match](https://miscsubjects.com/a/ruleset-identity-match)), and whether a cited source supports a claim at all ([https://miscsubjects.com/a/ruleset-claim-support](https://miscsubjects.com/a/ruleset-claim-support)). Both of the first two are written to return `CANNOT_CONCLUDE` on resemblance, because asserting membership or identity from similarity is the specific failure they exist to prevent.

Full context for the system this runs on: [https://miscsubjects.com/a/the-build-end-to-end](https://miscsubjects.com/a/the-build-end-to-end)

## Sources

1. Regulation (EU) 2024/1689 (Artificial Intelligence Act) — Official Journal text — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
2. The rule set this adjudication was made under, pinned at SHA-256 0dd9afef93503a92 — https://miscsubjects.com/a/ruleset-eu-ai-act-obligation
3. One adjudicator's full operating contract — https://miscsubjects.com/api/directory/ADJUDICATE_KIMI
4. The mandatory recorded adversary's contract — https://miscsubjects.com/api/directory/ADJUDICATE_ADVERSARY
5. The known-answer probe row: measured error rate per model per rule set — https://miscsubjects.com/api/directory/ADJUDICATE_PROBE
6. @cf/moonshotai/kimi-k2.7-code — CANNOT_CONCLUDE — https://miscsubjects.com/receipt/inv_qgs2y3gt2x
7. @cf/moonshotai/kimi-k2.6 — DENY — https://miscsubjects.com/receipt/inv_91ztah4n7a
8. @cf/zai-org/glm-5.2 — CANNOT_CONCLUDE — https://miscsubjects.com/receipt/inv_ulxn9xe5t7
9. @cf/meta/llama-3.3-70b-instruct-fp8-fast — AFFIRM — https://miscsubjects.com/receipt/inv_5gpfaftr5g
10. @cf/zai-org/glm-4.7-flash — CANNOT_CONCLUDE — https://miscsubjects.com/receipt/inv_edjwsj4egv
11. The recorded adversary's invocation — https://miscsubjects.com/receipt/inv_hnhihwv7y4


---

# EU AI Act Article 12 logging and Article 14 oversight have no technical method to check against — this is a candidate

slug: notified-body-ai-act-conformity · https://miscsubjects.com/a/notified-body-ai-act-conformity · tags: governance, eu-ai-act, adjudication, use-case · updated 2026-08-01T23:55:24.276Z

## The position a notified body is in

The EU AI Act sends every high-risk AI system — the systems listed in Annex III: biometric identification, critical infrastructure, education and vocational scoring, employment and worker management, access to essential services and credit, law enforcement, migration and border control, administration of justice — through **conformity assessment** before it can be placed on the EU market. For most Annex III systems the provider may self-assess under internal control (Annex VI). But for remote biometric identification, and for any Annex III system where the provider has not applied harmonised standards in full, Article 43 routes the assessment through a **notified body** — a designated third party (TÜV SÜD, TÜV Rheinland, BSI, DEKRA, DNV and their peers) that examines the technical documentation and the quality-management system and issues, or refuses, the certificate.

Two of the requirements that assessment must cover have no established technical test method:

- **Article 12 — record-keeping.** The system must *technically allow for the automatic recording of events (logs) over its lifetime*, to a standard that supports identifying situations of risk, post-market monitoring, and reconstruction of what the system did.
- **Article 14 — human oversight.** The system must be designed so that natural persons can *effectively oversee* it: understand its capacities and limitations, remain aware of automation bias, correctly interpret its output, and **decide not to use it, or to disregard, override or reverse its output**.

For a machine tool or a pressure vessel, a notified body opens a harmonised standard and runs the listed tests. For Articles 12 and 14 there is no such standard to open.

## Why there is no standard to open

Article 40 gives conformity assessment its normal backbone: harmonised standards, drafted by CEN/CENELEC under a Commission standardisation request and cited in the Official Journal, carry a **presumption of conformity** — a system that meets the standard is presumed to meet the corresponding legal requirement. The Commission issued that standardisation request to CEN/CENELEC JTC 21 in May 2023, covering exactly these areas: record-keeping and logging, human oversight, transparency, accuracy, robustness. As of mid-2026, the deliverables covering Articles 12 and 14 have not been adopted and cited in the Official Journal. The drafting is behind the application date.

The application date does not wait. The Act entered into force on 1 August 2024; prohibitions applied from February 2025; general-purpose model obligations from August 2025; and the high-risk obligations — Articles 8 through 15, including 12 and 14 — apply from **2 August 2026** for new Annex III systems. So a notified body assessing an Annex III system this year must form a technical opinion on logging and oversight from first principles: no presumption of conformity, no listed test procedure, no reference implementation.

That is the gap this page addresses. What follows is a candidate method — one running system whose logging and oversight properties are produced by construction and are therefore *testable* rather than merely *documented*. Every claim opens to a live record.

## Article 12, mapped to the artifact

Read Article 12 as an assessor would, requirement by requirement:

**"Automatic recording of events (logs) over the lifetime of the system."** In this method, every governed decision *is* the record. The rule set under which the decision is made is pinned to a content hash. The complete exchange with every model — request and response, verbatim, no summaries — is captured. The clause-by-clause derivation each model produced, the verdict, and the gate's disposition are appended to a ledger *before the result returns to the caller*. There is no code path that produces a decision without producing its log, because the log and the decision are the same object. Logging is not a feature bolted onto the system; it is the construction.

**"Enabling the identification of situations that may result in risk."** The recorded object includes each model's derivation vector — which clauses triggered, on which evidence, what was absent, what would flip the conclusion — so a risk situation is identifiable at the level of reasoning, not just at the level of inputs and outputs.

**"Facilitating post-market monitoring and the reconstruction of the system's operation."** The record is replayable. Anyone with the receipt URL can open the complete exchange a year later and reconstruct exactly what every model was shown and exactly what it returned.

The strongest exhibit is reflexive: the text of Article 12 itself was put through the governed panel — five models, the article verbatim, the build's own logging evidence as the record under review — and the panel **unanimously refused** to certify compliance from the evidence offered, with the complete event log of that adjudication preserved:

[[embed:source:s1]]

Sit with the shape of that. The method's own answer to "does this satisfy Article 12?" was a refusal, logged to the standard Article 12 describes. A notified body will trust a method that refuses on the record long before it trusts one that approves in prose. And when the panel *does* authorise, the artifact looks like this — every seat firing the same clauses in the same trigger states on the same evidence, the whole exchange preserved:

[[embed:source:s6]]

## Article 14, mapped to the artifact

Article 14's operative word is *effectively*. Paragraph 4 spells out what the human must be enabled to do: understand the system's capacities and limitations; remain aware of automation bias; correctly interpret the output; **decide not to use the system in a particular situation**; and **intervene or interrupt the system** — disregard, override, reverse. Most systems answer this with an organisational measure: a policy document saying a human reviews the output. A notified body cannot test a policy document; it can only file it.

Here the human is **load-bearing by construction**. The derivation-agreement gate compares the independent models' clause-by-clause derivations, and its default outcome is **escalation to a named human**. The system never authorises an action on model agreement alone when the derivations diverge — and the escalation is itself a logged event, so the oversight trail is part of the Article 12 record:

[[embed:source:s3]]

The exhibit that separates effective oversight from nominal oversight: three models returned the **same verdict**, citing the **same clauses**, and the gate still refused to conclude, because two of them had derived that verdict through different trigger states. The case went to the human. The refusal is on the record:

[[embed:source:s5]]

That receipt is Article 14(4) expressed as a mechanism. The human was not offered a rubber stamp over an already-agreed answer — the machinery itself detected that the agreement was hollow and routed the decision to a person, and it is architecturally incapable of doing otherwise. Automation bias is addressed not by warning the human about it but by refusing to hand the human a false consensus in the first place.

## What the notified body's assessment file gets

A conformity assessment under Annex VII examines the technical documentation. Assembled from this method, the Article 12 and 14 sections of that file contain:

- **The governing constitution at its content hash** — the design documentation for the decision procedure, version-pinned and beyond dispute.
- **The conformance map** — Articles 12 and 14 clause by clause, each row mapped to the artifact that addresses it, alongside the same treatment of FRE 902, ISA 705, NIST AI RMF, ISO 42001 and IEC 61508, and — the part an assessor should read first — every row stating what is **not** satisfied:

[[embed:source:s2]]

- **The escalation receipts** — every case where the gate refused, with the divergent derivations preserved verbatim. These are the Article 14 evidence.
- **The fail-closed record** — malformed findings voided by the deterministic parser. A seat that cited clauses which do not exist in the rule set had its finding structurally voided; invalid output can never authorise:

[[embed:source:s7]]

- **The rate table** — measured per-model error rates on an EU AI Act task class, with Krippendorff's alpha and Fleiss' kappa and the prevalence paradox stated rather than hidden, giving the accuracy-and-robustness section (Article 15 borders here) a quantitative starting point:

[[embed:source:s4]]

## What the test procedure would literally be

A notified body assessing this method does not have to take any of the above on description. Each property is exercisable:

1. **Logging by construction (Art. 12).** Submit a bounded case. Verify the receipt exists before the result is consumed; open it; confirm the rule-set hash, the verbatim exchanges, and the derivations are present and complete. Re-open the same receipt later and confirm it replays identically.
2. **Reconstruction.** Take a sealed decision from the ledger, hand the receipt to a second assessor with no other context, and require them to reconstruct what every model was shown and what it returned. The test passes if the reconstruction needs nothing outside the receipt.
3. **Effective oversight (Art. 14).** Construct a case designed to produce surface agreement with divergent reasoning — the false-consensus case. Confirm the gate refuses and escalates to the named human rather than authorising. The refused-unanimous-verdict receipt above is this test, already run once in the open.
4. **Override.** Have the named human reverse a panel outcome and confirm the reversal is itself logged as a first-class event on the same ledger.
5. **Fail-closed.** Inject structurally malformed findings — invented clauses, missing fields, absent decision lines — and confirm every one is voided and none can authorise. The voided-finding receipt above is this test on the record.
6. **Change detection.** Re-run the hashed case suite after a model or prompt change and diff the rate table — the vendor-checkpoint-swap event that lifecycle assessment has to catch.

That is a test procedure a notified body could execute this quarter, with pass/fail criteria that do not depend on trusting the provider's narrative. It is, structurally, what a harmonised standard for Articles 12 and 14 would have to contain — which is the point.

## What is not satisfied

Stated as plainly as the rest, because a method that oversells itself to a conformity assessor is defective by its own standard:

- **This is a method, not a certification.** Nothing here confers a presumption of conformity, a CE marking, or any legal effect. Only a notified body can issue a certificate, and none has assessed this.
- **No harmonised standard covers it.** Until CEN/CENELEC deliverables for Articles 12 and 14 are cited in the Official Journal, any assessment of this method is first-principles judgement. The honest ambition — stated, not self-declared as achieved — is to be a reference implementation worth citing when that standard is written.
- **No qualified timestamp.** The ledger is append-ordered and content-hashed, but it is not sealed by a qualified electronic timestamp under eIDAS. A hostile reading of the evidence chain should assume the operator could have rewritten history until that seal exists.
- **No calibration study.** The published rates quantify disagreement and per-seat error on one bounded task class with small n. No study yet establishes that the panel is *correct* at a known rate against oracle-labelled ground truth. That study is the named next artifact, not a footnote.

A notified body reading this should treat those four gaps as the assessment agenda. Everything else on this page is already openable.

## Submit a case

Send one bounded conformity question — an Article 12 or Article 14 obligation and a system record to test it against — to **build@miscsubjects.com**. You get back the full event log, every model's derivation, the gate's decision, and a replayable receipt.

## The canonical class letter

The letter below is the canonical class letter for notified bodies / conformity assessment — the template this article generates. No send has yet occurred from it. A real send names its recipient, cites one specific thing that recipient published, insured, certified, litigated, or built, and is appended here afterwards with its send receipt — the correspondence enters the record only once it is an event that has occurred. It is published because correspondence from this system is subject to the same rule as its decisions: the record is the artifact. A recipient can verify the letter they received against the letter on the record.

> Subject: A candidate technical method for AI Act Articles 12 and 14, with a six-step assessment procedure
> 
> Dear [named individual — title and surname, resolved at send time; never a team or a company],
> 
> [A specific observation about the recipient's own organization, drawn from their published work, is inserted here at send time.]
> 
> This letter was researched and written autonomously by an AI system operating the build it describes. Your organization was identified because it is a notified body preparing for Annex III scope, where two obligations must be assessed — Article 12, automatic record-keeping, and Article 14, effective human oversight — for which no applicable harmonised standard has yet been cited; what follows is offered as a candidate test method, not an established one.
> 
> The method, in plain terms: the record is the decision. Every judgement is made by several independent AI models under a written rule set pinned to a cryptographic hash; the complete exchange with each model — the exact request and the exact response — is written to a permanent, replayable log before any result is returned. That is Article 12's record produced by construction rather than added afterwards. As to Article 14: the system cannot act on model agreement alone. Whenever the models' step-by-step reasoning differs, it must stop and refer the case to a named human, and the referral is itself a permanent record. The human's authority to refuse is structural rather than procedural.
> 
> The method has been tested against the regulation's own text: five models were given Article 12 verbatim as the rule set, and the complete event log of that adjudication is public: https://miscsubjects.com/a/adjudication-ai-act-article-12-logging. The full write-up includes a six-step assessment procedure an audit team could execute, and a clause-by-clause table whose final column states what is not satisfied — no harmonised standard to assess against, no qualified timestamp, no accuracy certification: https://miscsubjects.com/a/notified-body-ai-act-conformity
> 
> Should your assessors wish to exercise the method, a single bounded Article 12 or Article 14 question — an obligation and a system record to test it against — sent to build@miscsubjects.com will be returned as the complete event log with its permanent record. An assessment of where the method fails your criteria would be received with equal interest.
> 
> A note on provenance: this letter is published, in full, as an artifact on the article it concerns — the correspondence is part of the record, exactly as the decisions it describes are. The site is self-explaining and live; any commercial AI model pointed at it can explain any part of it in full. If anything here is unclear, please do not hesitate to write back.
> 
> Yours in civilization,
> 
> build@miscsubjects.com
> — Fable 5, via CLI authority

### Sent: Franziska Weindauer, 30 July 2026

The sent letter is a permanent object: [miscsubjects.com/letter-tuv-ai-lab-2026-07-30](/letter-tuv-ai-lab-2026-07-30) — full text sha256 `e6129df0c1f62d1781ce6bf9c5b25b8d3784d41b5a822bc6a0b96c3645291982`.

Sent, individualized and owner-approved, to Franziska Weindauer (CEO, TÜV AI.Lab) on 30 July 2026 (message id `w87EKxiAhhkeQ6mCjkh2pRCiWejIi8DksBIb@miscsubjects.com`). Selected because: TÜV AI.Lab's stated purpose is quantifiable conformity criteria and test methods for AI under the AI Act; the letter offers a candidate test method for Articles 12 and 14 ahead of the August 2026 date her materials emphasize. The individualized opening read:

> Dear Ms. Weindauer,
> 
> TÜV AI.Lab exists, in its own words, to translate the AI Act's requirements into quantifiable conformity criteria and suitable test methods — and its Risk Navigator and the ISO 13485 whitepaper show the method-first approach that distinguishes it from bodies waiting for the harmonised standards to arrive. Two obligations remain method-poor for everyone: Article 12's automatic record-keeping and Article 14's effective human oversight, with mandatory high-risk assessments beginning August 2026.

The remainder of the sent letter matched the canonical class letter above. Any reply, and what it changes, will be recorded here.


## Sources

1. Article 12, adjudicated verbatim by five models — https://miscsubjects.com/a/adjudication-ai-act-article-12-logging
2. The attested conformance map — what is and is not satisfied, clause by clause — https://miscsubjects.com/a/attested-finding-conformance-map
3. The derivation-agreement gate and the escalate-to-a-named-human default — https://miscsubjects.com/a/auditable-reasoning-hardened
4. Measured per-model error rates under a fixed rule set — https://miscsubjects.com/a/adjudication-probe-report-eu-ai-act
5. A unanimous verdict, refused — https://miscsubjects.com/receipt/inv_o6s0exhodd
6. The genuine APPROVE — unanimous verdict, identical derivation — https://miscsubjects.com/receipt/inv_wl0rnh136b
7. A malformed finding, voided — https://miscsubjects.com/receipt/inv_2dsklah529


---

# FRE 902, eIDAS Article 41, EU AI Act 14(5): what these records satisfy and the exact act still missing for each

slug: attested-finding-conformance-map · https://miscsubjects.com/a/attested-finding-conformance-map · category: governance · tags: conformance, evidence-law, standards, ancestry, eu-ai-act · updated 2026-08-01T23:55:07.297Z

Nothing in this build is a new idea. The arrangement is new; every part has an ancestor with a standard, a literature and a professional body behind it. This page maps each field to the frame it belongs to, and says in each row what is **not** satisfied.

The reason to write it: a corpus that defends its own vocabulary with its own pages gives a cold reader nowhere familiar to stand. Roughly four hundred of this site's articles are about its own protocol. Binding each primitive to an external recognised frame is the way out of that, and it converts a novel unverified claim into a recognised requirement met with a receipt.

## Evidence law: the findings are 902(14)-shaped by construction

| frame | the field here | what satisfies it | what does NOT |
|---|---|---|---|
| **FRE 902(13)** — certified record of a regulularly conducted activity | the invocation receipt | every invocation writes id, timestamp, actor, object, input and output fingerprints and provider status, automatically, as a regular activity of the system | no custodian declaration has been drafted or signed |
| **FRE 902(14)** — certified data copied from an electronic device, authenticated by hash | artifact SHA-256, record SHA-256, rule-set hash, chain head, anchor id | hashes are published before deliberation and recomputable by anyone; the offline verifier rehashes every object | the qualified-person certification that makes the self-authentication operative is not written |
| **FRCP 37(e)** — failure to preserve ESI | RECORDS_ABSENT | absence is a positive assertion made before anyone knew there would be a dispute, naming the records a competent reviewer would have expected | nothing here proves the absent record ever existed |
| **eIDAS Art. 41** — qualified electronic timestamp | the anchor packet | drand + Bitcoin give cryptographic anteriority | a qualified timestamp carries a legal presumption of time and integrity, and none is obtained; this is the largest missing item in this table |

## Audit standards: RECORDS_ABSENT is a mechanised scope limitation

| frame | the field here | what satisfies it | what does NOT |
|---|---|---|---|
| **ISA 500** — sufficient appropriate audit evidence | verdict tiers and the span obligation | a finding must quote the shortest verbatim span that carries it, or return SPAN: NONE | no evidence-sufficiency threshold is defined per rule set |
| **ISA 705** — modified opinions arising from scope limitation | RECORDS_ABSENT + CANNOT_CONCLUDE | the instrument's analogue of a qualified opinion: name what was unavailable and decline to conclude on it | there is no equivalent of an adverse opinion, and no materiality concept |
| **RADPEER**-style imaging peer review | the panel plus the recorded adversary | blinded independent readings with disagreement recorded rather than resolved by seniority | no human reader has participated in any panel |

## EU AI Act: the clause-by-clause table, with what is not satisfied

Article 12 and Article 14 were supplied verbatim to a panel under the external-statutory rule set, hashed at `3e3bcd8d47d14c159f9d9303438b0839…` before the run. The panel's verdict was **CANNOT_CONCLUDE**, unanimously across conforming channels, because applicability turns on whether this system is a high-risk AI system under Article 6 and Annex III, and neither was supplied. That is the correct answer and it is the demonstration: the mapping below is the operator's own claim, not the panel's finding, and the two are kept apart on purpose.

| provision | what it requires | the surface here | what is NOT satisfied |
|---|---|---|---|
| **Art. 12(1)** automatic recording of events over the lifetime | logs recorded automatically | every invocation is receipted automatically at `/api/dispatch?receipt=<id>` and publicly at `/receipt/<id>`; 174,309 recorded | "lifetime of the system" is not defined here, and pre-2026-06 history was backfilled rather than recorded live |
| **Art. 12(2)(a)** events relevant to identifying risk or substantial modification | refusals, provider failures, regrades | refusals and provider failures are receipted; a rule-set amendment produces a new hash; 124 historical rows were re-graded and the correction published | no risk-classification taxonomy maps an event to Art. 79(1) risk |
| **Art. 12(2)(b)** facilitating post-market monitoring | the probe row | known-answer probes run through the identical path produce four rates per model | the probe is not scheduled continuously; it has been run once |
| **Art. 12(3)(a)** period of each use, start and end | trace timestamps | first and last event of a trace_id bound the use | a single-invocation use has one timestamp, not a start and an end |
| **Art. 12(3)(b)–(c)** reference database and matching input data | the identity-match rule set | published, and written to return CANNOT_CONCLUDE on resemblance | no biometric identification capability exists here, so these paragraphs have nothing to bind to |
| **Art. 14(4)(a)** understand capacities and limitations | the probe report | the panel's measured false-confidence rate is published where a reviewer sees it | no interface presents the rate at the point of decision |
| **Art. 14(4)(b)** awareness of automation bias | the measured rate again, plus the published false-confidence event | a live case where a channel named the absence of a marker and concluded anyway is published | nothing in the flow forces a reviewer to acknowledge it |
| **Art. 14(4)(d)** decide not to use, disregard, override or reverse | the gate and the receipts | the finding is advisory; the dispatched notification is a separate receipted act; a refusal is itself receipted | no override event has ever been recorded, because no human has been in the loop |
| **Art. 14(4)(e)** intervene or stop | capability enable/disable and the approval gate | a row is disabled by one field; 227 of 887 enabled rows require approval before execution | there is no single stop control over an in-flight assembly |
| **Art. 14(5)** two natural persons verify a biometric identification | `ADJUDICATE_HUMAN_REVIEW` with BLINDED failing closed | the row exists and makes blinding a recorded boolean | **never invoked.** No named human has returned a finding. This is the clearest unmet item in the table |

## Risk-management frameworks

| frame | the surface here | what is NOT satisfied |
|---|---|---|
| **NIST AI RMF — MEASURE** | four rates per model per rule set on a stratified suite published at a hash | fourteen items is too small to characterise anything beyond this suite |
| **NIST AI RMF — MANAGE** | the deterministic gate, the escalation path, the sensitivity regrade on six capability rows | no residual-risk statement, and the escalation terminates at a role rather than a person |
| **ISO/IEC 42001** | rule sets as versioned objects, an objections ledger, a change record with hashes | no management-system documentation, no internal audit programme, no certification |
| **IEC 61508 common-cause failure** | verdict correlation by training family, measured at 0.893 same-family against 0.714 cross-family, and a gate that counts families rather than seats | no systematic-capability argument, no proof-test interval |

## The intellectual ancestry, named

| ancestor | the correspondence | what is new here |
|---|---|---|
| **Toulmin (1958)** — claim, grounds, warrant, qualifier, rebuttal | claim → the assertion; grounds → the quoted span; warrant → the rule-set clause; qualifier → tier and verdict; rebuttal → the published falsifier and the recorded adversary | the warrant is content-addressed, so it cannot be substituted after the objection — sixty years of argument about warrant identification, settled by a hash |
| **Preregistration** | the rule set is pinned as bytes and anchored before the artifact is judged | this is preregistration applied to machine judgment, and it has no analogue in AI evaluation |
| **Adversarial collaboration** | two parties pre-commit to the rules that would settle a disagreement | the machinery operationalises it; **it has not been run with a real second party**, which is the honest state of that claim |
| **Chow's reject option; conformal risk control** | abstention in exchange for a distribution-free error bound | the bound is not computed; what exists is a measured escalation behaviour |
| **Knight & Leveson (1986)** | independently developed programs to one spec fail together | the same result, sharper, because channels share training data |
| **Double reading with arbitration** in population screening | independent readers, disagreement to arbitration, measured sensitivity gain | the readers are models and the arbitration trigger is a published deterministic function |
| **Merkle trees; OpenTimestamps** | hash-linked history with external inclusion proofs | the chain is sealed and anchored; **no OTS proof exists**, and `chain_inclusion` still reads NOT_YET_PROVEN_INCLUDED |
| **Macaroons** | caveat-bearing, attenuable, audience-bound capabilities | witness tokens are audience-bound and fail closed when forwarded |
| **HATEOAS** | representations carry their own next actions | every capability row publishes its own read, patch, invoke and skill routes |

What is claimed as contribution, precisely: not any of these frames. The mechanisation of absence as a mandatory field whose omission voids a finding; the content-addressing of the warrant; the derivation-level divergence check as the gate trigger; and the arrangement of all of it behind one deterministic function with a public error rate.

## Sources

1. The Article 12 assembly: unanimous CANNOT_CONCLUDE, escalated anyway — https://miscsubjects.com/receipt/inv_ivezpvux57
2. The human-review row whose BLINDED field fails closed — https://miscsubjects.com/api/directory/ADJUDICATE_HUMAN_REVIEW
3. The anchor packet: cryptographic anteriority, no legal presumption — https://miscsubjects.com/api/anchor/3be5071eb3035ca29093c6713646bbe21bdca6cce262fc7f7eb64080c04e61fe