# 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: PROVIDER: DEPLOYER: INPUTS: OUTPUTS: USERS: AFFECTED_PERSONS: DECISION_POINT: HUMAN_REVIEW: PRODUCT_INTEGRATION: JURISDICTION_AND_MARKET: ``` “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: AI_OPERATION: REAL-WORLD_RESEMBLANCE: FALSE_AUTHENTICITY_RISK: PROVIDER_MARK_PRESENT_AFTER_EXPORT: DEPLOYER_LABEL_AT_FIRST_EXPOSURE: ACCESSIBILITY_CHECK: CREATIVE_WORK_TREATMENT: TRANSFORMATION_TEST: REVIEWER_AND_DATE: ``` 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 --- # How to preserve the judgment behind an automated SOC 2 or ISO 27001 compliance check slug: continuous-controls-evidence-object · https://miscsubjects.com/a/continuous-controls-evidence-object · category: Governance · tags: governance, compliance, soc2, iso27001, auditable-reasoning · updated 2026-08-02T01:44:32.827Z ## The check became an API call. The judgement did not. Compliance automation earned its category by mechanising the boring half of a SOC 2 or ISO 27001 program. Where an auditor once emailed for screenshots, a platform now reads the cloud provider's API directly: is MFA enforced, is the bucket public, is the encryption flag set, how many days since the last access review. The configuration snapshot is real evidence, timestamped, pulled hourly instead of annually. That half of the promise — **continuous monitoring of configuration state** — is kept, and kept well. The other half is quieter. A control is not a configuration flag. A control is a sentence: *"Logical access to production systems is restricted to authorized personnel and reviewed at least quarterly."* Between the sentence and the API response sits a judgement — does **this** IAM policy, with **these** role bindings and **this** review log, satisfy **that** language? For the simple controls the mapping was written by hand once and reused forever. But the control language customers actually carry is not simple: it is customized per audit, negotiated per contract, inherited from frameworks that overlap without aligning. So the platforms are doing what every software category is doing in 2026 — handing the mapping to a large language model. The model reads the control text, reads the configuration snapshot, and emits satisfied or not satisfied. The dashboard turns green. Nothing on this page argues against that delegation. The judgement layer is exactly where a language model belongs — it is a reading task. The argument is about what that judgement leaves behind. ## The inherited decision Follow the green dot upstream. The customer relies on the platform's determination. The auditor, issuing a SOC 2 report on which third parties will in turn rely, samples the platform's determinations as evidence. If the determination was made by a model, the auditor has inherited a decision with no recorded basis: which version of the control language was judged, against which snapshot, by what reasoning, and what the model would have needed to see to decide otherwise. The platform's log says *check passed at 09:14*. It does not say why, in any form a second party can verify — and an unexplained pass that later proves wrong is not the platform's finding to defend. It is the auditor's. Assurance standards already have a name for this shape of problem. The ISAE 3000 sibling to this page works through it from the practitioner's side — what "sufficient appropriate evidence" means when a model made the call: [[embed:source:s7]] This page works through it from the platform's side: what the judgement layer should **emit**, per decision, so that the determination is an evidence object rather than a boolean. ## The evidence object, mechanically One governed control determination works like this. The **control's written language** — the actual sentence from the customer's control set, not a platform paraphrase — is pinned to a content hash and becomes the rule set. The **configuration snapshot** under review is hashed the same way and becomes the record. Afterwards there is no arguing about which text or which state was judged: both hashes are in the sealed result. Then the judgement itself. Not one model — **three seats across two model families**, each receiving the identical rule set and record under a governing constitution that compels a fixed output shape: the verdict, the clauses relied on, and a clause-by-clause derivation — for each clause of the control, did its condition trigger on this snapshot, does that support or defeat "satisfied," on which evidence records — plus the records that were *absent*, the strongest rejected alternative reading, and what evidence would flip the conclusion. A deterministic parser — ordinary software, not another model — projects each finding into canonical per-clause tuples and compares them, tuple by tuple, across the seats. Only when independent models agree not just on the answer but on the *reasoning* — same clauses, same trigger states, same evidence — does the determination seal as satisfied. The gate that does this, including the false-convergence defect it once shipped with and the fix, is documented in full: [[embed:source:s1]] When the panel does agree derivation-for-derivation, the artifact looks like this — every seat firing the same clauses in the same states on the same evidence, sealed: [[embed:source:s3]] ## Disagreement is an outcome, not a bug The property that matters most to a relying auditor is the one no single-model pipeline can have: **agreement that hides disagreement cannot pass**. The clearest exhibit on the ledger is a case where three seats 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: [[embed:source:s2]] Translate that into controls language. Three checks agree the access-review control is satisfied; two of them think so for reasons that contradict each other — one read the quarterly review as evidenced, the other read the control as not requiring it this period. On a dashboard, that is a green dot. Here, it is a recorded refusal, escalated to a named human, and the escalation is itself a receipt anyone can open a year later. For the platform this costs a small fraction of determinations routed to review. For the auditor it removes the exact failure they cannot detect from sampled outputs: consensus at the surface, divergence underneath. ## Malformed findings can never pass Models emit garbage at a nonzero rate, and a judgement layer is only safe if garbage fails closed. In the governed format a finding that cites a clause that does not exist in the control's rule set, omits a required field, or lacks its terminal decision line is **structurally voided** before any comparison happens. Here is that firing on the cheapest seat of a live panel, which cited clauses 7, 8 and 12 of a six-clause rule set: [[embed:source:s4]] The voided finding is preserved — it is evidence about the seat — but it can never mark a control satisfied. That is the property that makes it safe to include inexpensive seats on the panel at all: their failures are load-bearing for calibration and harmless for authorisation. ## Absence is declared, not discovered The oldest failure in continuous monitoring is silence read as compliance: the evidence feed breaks, the collector loses a scope, and the control stays green because nothing arrived to turn it red. The governed format inverts the default twice. First, every seat must declare, per decision, which expected records it **did not receive** — absence is a stated field, not an inference left to the reader. Second, abstention is a sealable outcome: a case on the ledger had a required record deliberately withheld, with a manifest naming the absence, and the panel's abstention was sealed exactly as an authorisation would have been: [[embed:source:s5]] A control determination that cannot say "I did not see the review log, therefore I decline to conclude" — as a permanent, openable record — is not monitoring the control. It is monitoring the pipeline's happy path. ## Calibration, with its limits stated How often is this right? That question has a measured, opened answer rather than an adjective. Thirty oracle-labelled cases — balanced across should-affirm, should-deny, and should-abstain — ran through the production gate, every case hashed, every seat call a receipt, every number computed from the result files: [[embed:source:s6]] The lead seat (glm-5.2) scored 30 of 30 on verdicts; the second family's seat (kimi-k2.7) 29 of 30, its single miss an over-abstention — the conservative direction. The number a relying party actually needs is the gate's: **zero wrongful authorisations in 30 sealed outcomes**. Nothing wrong was ever sealed as right; every error the seats produced was either voided, escalated, or fell on the side of declining to conclude. The limits travel with the number. The fixtures are **synthetic and determinate** — written so that a correct answer exists and is known. Real customized control language is messier, and a 30-case suite is a starting table, not an actuarial basis. What the study establishes is narrower and still useful: on cases where the right answer is knowable, the gate's failure mode is deferral, not wrongful passing. ## The siblings: same instrument, other obligations This is the third mapping of one mechanism, not a new machine. The same governed decision record is already assembled as a validation file with documented effective challenge for bank model-risk teams under SR 11-7: [[embed:source:s8]] and as the per-decision evidence object for assurance practitioners under ISAE 3000. A compliance-automation platform evaluating this can therefore test it against whichever obligation sits nearest: the model-risk framing if your customers are banks, the assurance framing if your output feeds an auditor's file. The mechanism — hashed rule set, hashed record, multi-family panel, derivation comparison, fail-closed parsing, declared absence, sealed outcomes — does not change between them. ## What is not satisfied Stated as plainly as the rest, because a compliance audience should be sold exactly what the evidence supports and nothing further: - **No framework conformance analysis.** No mapping of this instrument to the AICPA trust-services criteria, to any SOC program requirement, or to ISO 27001's evidence expectations has been performed. The claim here is about the shape of the evidence, not about conformance. - **No auditor has relied on it.** No engagement, SOC or otherwise, has used a sealed determination from this system as audit evidence. Until one has, everything above is an instrument offered for inspection, not a practice with precedent. - **Calibration is synthetic only.** The measured rates come from determinate fixtures authored for the study. No study yet measures accuracy on real customized control language against auditor-labelled ground truth. That study is the named next artifact. A platform or audit team reading this should treat those three gaps as the evaluation agenda. Everything else on this page is already openable. ## Submit a case Send one bounded control determination — the control's actual written language and the configuration snapshot (or evidence record) under review — to **build@miscsubjects.com**. You get back the complete governed panel: every seat's clause-by-clause derivation, the gate's decision, and a receipt you can open a year later. No account is required, and no meeting is necessary. ## The canonical class letter The letter below is the canonical class letter for compliance-automation platforms and the auditors who rely on them — 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, built, certified, or audited, 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: The judgement layer in continuous controls monitoring — an evidence object, running, with its receipts public > > Dear [named individual — title and surname, resolved at send time; never a team or a company], > > [A specific observation about the recipient's own platform, published methodology, or audit practice, 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 either automates control monitoring or relies on such automation in assurance work, and the instrument described below addresses the layer of that stack where a language model now decides whether a configuration satisfies a control's written language. > > The instrument, described without assumed vocabulary: the control's actual text is pinned to a cryptographic hash, as is the configuration snapshot under review. Three AI model seats across two model families each judge the case and must set out their reasoning clause by clause in a fixed, machine-readable form — whether each clause's condition fired on this snapshot, whether that supports or defeats "satisfied," on which record, and which expected records were absent. Ordinary software, not another AI, compares those reasoning chains step by step. When the seats agree on the answer but not the reasoning, the system declines to conclude and refers the case to a named human. That refusal is a permanent public record. > > The clearest exhibit: three seats returned the same verdict, citing the same rules, and the system still refused to conclude because two had derived it differently — the false-consensus failure no dashboard surfaces, caught mechanically and preserved: https://miscsubjects.com/receipt/inv_o6s0exhodd > > A 30-case oracle-labelled calibration run through the same production gate recorded zero wrongful authorisations — with its scope stated plainly: synthetic, determinate fixtures, not customized control language. The full mapping, including what the instrument does not satisfy — no AICPA or SOC conformance analysis, no auditor reliance to date — is here: https://miscsubjects.com/a/continuous-controls-evidence-object > > Should your team wish to examine it directly, a single bounded determination — one control's written language and one evidence record — sent to build@miscsubjects.com will be returned as the complete governed panel: every model's full reasoning and the permanent record of the decision. Criticism of the method from practitioners is equally welcome, and will be treated as the more valuable reply. > > 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 ## Sources 1. The derivation-agreement gate — effective challenge, mechanised — https://miscsubjects.com/a/auditable-reasoning-hardened 2. A unanimous verdict, refused on divergent derivation — https://miscsubjects.com/receipt/inv_o6s0exhodd 3. The genuine APPROVE — unanimous verdict, identical derivation — https://miscsubjects.com/receipt/inv_wl0rnh136b 4. A structurally invalid finding, voided — https://miscsubjects.com/receipt/inv_2dsklah529 5. Abstention sealed as an outcome — the first clean NO_ACTION — https://miscsubjects.com/receipt/inv_7rqy8ywuls 6. The calibration study — 30 oracle-labelled cases through the production gate — https://miscsubjects.com/a/adjudication-calibration-study 7. AI assurance under ISAE 3000: the evidence object the engagement is missing — https://miscsubjects.com/a/big-four-isae-3000-ai-assurance 8. SR 11-7 model validation: the instrument — https://miscsubjects.com/a/cro-model-validation-instrument