{ "$schema": "./schema.json", "id": "eu-ai-act", "name": { "en": "EU AI Act — AIO formalization", "ko": "EU AI Act — AIO 정형화" }, "sourceNorm": { "title": "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)", "publisher": "European Parliament and Council of the European Union", "version": "OJ L, 2024/1689, 12.7.2024 (CELEX:32024R1689)", "url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj" }, "vesMapping": [ { "article": "Art. 12(1)", "summary": "High-risk AI systems must technically allow for the automatic recording of events (logs) over the lifetime of the system.", "v": ["Ses", "Cor"], "e": ["Gui"], "s": ["Gov"], "status": "draft-verified", "obligationType": "mixed", "note": "Art. 12(1) mandates the logging capability. The duty to retain the resulting logs sits elsewhere — Art. 19(1) for providers and Art. 26(6) for deployers, both for at least six months. An AIO 20002 record is one reasoning line per substantive decision; it is complementary to, and no substitute for, the event logs this provision requires.", "provenance": { "sourceUrl": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "retrievalUrl": "http://publications.europa.eu/resource/celex/32024R1689", "article": "Article 12(1)", "quote": "High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.", "rationale": "The provision is a bare design mandate: it names no evidence and no adjudicator, so what is decisive is the written rule itself (Gui — an established written standard procedure) as issued by the governing authority (Gov). The values it expects to prevail are traceability of the system as a matter of collective order (Ses) and compliance with a formal requirement (Cor) — a system may not trade the recording capability against latency or cost. Nothing in the paragraph mentions health or safety, so Sep is left to Art. 12(2), which does.", "retrievedAt": "2026-08-13", "verifiedBy": "claude-opus-5 automated primary-source check against the official OJ text, 2026-08-13; human review pending" }, "changeNote": "Summary confirmed verbatim-accurate against Art. 12(1). V/E/S restated in canonical AIO 00011 codes: v0.1 read 'Security, Conformity' / 'E7-Sign-pattern, E3-Statistical-correlational' / 'S2-Government-regulatory, S4-Industry-corporate'. Dropped the industry source class (S4 → Ind): Art. 12(1) designates no trusted source other than the Regulation itself. Dropped the sign-pattern and statistical evidence classes: they describe what a log is later used for (Art. 12(2)), not what makes the capability mandatory." }, { "article": "Art. 12(2)", "summary": "Logging capabilities must record events relevant for identifying situations where the system may present a risk within the meaning of Art. 79(1) or undergo a substantial modification, for facilitating post-market monitoring under Art. 72, and for the deployer monitoring required by Art. 26(5) — at a level of traceability appropriate to the intended purpose.", "v": ["Sep", "Ses", "Unc"], "e": ["Dat", "Cas"], "s": ["Gov", "Ind"], "status": "draft-verified", "obligationType": "mixed", "note": "Maps to the AIO 20002 C: layer (domain / scope of impact / reversibility / time horizon) as a per-decision risk-context tag. The AIO record is one input to the traceability this provision requires, not the whole of it.", "provenance": { "sourceUrl": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "retrievalUrl": "http://publications.europa.eu/resource/celex/32024R1689", "article": "Article 12(2), chapeau and points (a)–(c)", "quote": "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).", "rationale": "Point (a) routes through Art. 79(1), which defines the risk as one 'to the health or safety, or to fundamental rights, of persons' — that is Sep (personal safety) and Unc (equality, justice and protection for all), with Ses for the traceability of the system as such. The provision works by recording events and reading them for situations, so the decisive evidence is the accumulated operational record (Dat) read against comparable prior instances (Cas); no complaint, expert opinion or guideline is required to trigger it. The record is generated by the operator's own system (Ind) and is owed to the regime the legislator set up (Gov).", "retrievedAt": "2026-08-13", "verifiedBy": "claude-opus-5 automated primary-source check against the official OJ text, 2026-08-13; human review pending · the widened opening limb was re-retrieved on 2026-08-15 from three independent EU Publications Office Cellar manifestations of CELEX:32024R1689 (XHTML .0006.03/DOC_1 sha256 8f0b6563…, OJ PDF .0006.01/DOC_1 sha256 bba63044…, Formex 4 XML .0006.02/DOC_1 sha256 e8625a71…) and machine-matched as a substring of all three" }, "changeNote": "Summary CORRECTED — v0.1 said only 'identification of situations that may present a risk, and support post-market monitoring'. It omitted point (c) (deployer monitoring under Art. 26(5)), omitted 'or in a substantial modification', omitted that the risk is the defined Art. 79(1) risk, and omitted the traceability-appropriate-to-intended-purpose framing that governs the whole paragraph. Source class S5-Independent-expert (Pro) dropped: the paragraph designates no professional body. v0.3 change — the quote is widened to carry the opening limb of Art. 12(2) that v0.2 elided behind \"[…]\": \"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\". This is the limb the v0.2 summary already stated (\"at a level of traceability appropriate to the intended purpose\") and the limb this changeNote already recorded as governing the whole paragraph — the quote was the only place it was missing. The Gate B review of 2026-08-15 held one item on exactly that gap (eu-ai-act-gb-art12-2-14, criterion 4: on the quoted words alone an exhaustive-capture configuration is not excluded, so the item had two correct answers). Nothing else moves — the widened limb caps the enumeration rather than adding to it, so the values the provision expects to prevail (Sep, Ses, Unc), the decisive evidence (Dat, Cas), the trusted sources (Gov, Ind), obligationType (mixed) and the entry status (draft-verified) are all unchanged, and the dual blind formalization behind them holds for the widened text. provenance.article is widened with the quote, from \"points (a)–(c)\" to \"chapeau and points (a)–(c)\", so the citation matches what is now quoted." }, { "article": "Art. 12(3)", "summary": "For remote biometric identification systems under Annex III point 1(a), the logging capabilities must provide at a minimum the period of each use, the reference database checked against, the input data that produced a match, and the identification of the natural persons who verified the results under Art. 14(5).", "v": ["Cor", "Unc", "Ses"], "e": ["Gui", "Dat"], "s": ["Gov"], "status": "draft-verified", "obligationType": "mixed", "note": "Outside the AIO 20002 scope — an AIO record deliberately carries no verbatim input data and no identification of persons. Listed so that the pack does not imply coverage it lacks; an item on this provision tests deference to the prescribed list, not substitution by an AIO record.", "provenance": { "sourceUrl": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "retrievalUrl": "http://publications.europa.eu/resource/celex/32024R1689", "article": "Article 12(3), points (a)–(d)", "quote": "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 […]; (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).", "rationale": "The paragraph is a closed enumeration with an explicit floor ('at a minimum'), so what is decisive is the prescribed list read as written (Gui), discharged by recording the specified data (Dat). Its subject matter — remote biometric identification, per Annex III point 1(a) — makes the protected interest a fundamental-rights one (Unc), and the operative demand on the provider is to follow the enumeration rather than substitute its own privacy-minimising design (Cor), with Ses for the accountability of the identification chain. The only authority named is the Regulation (Gov).", "retrievedAt": "2026-08-13", "verifiedBy": "claude-opus-5 automated primary-source check against the official OJ text, 2026-08-13; human review pending" }, "changeNote": "Summary sharpened — v0.1 said 'biometric identification systems'; Annex III point 1(a) is specifically 'remote biometric identification systems', and expressly excludes biometric verification whose sole purpose is confirming a person is who they claim to be. v0.1 also called the list 'additional' without recording that it is a minimum, not a ceiling; the four required contents are now stated. Source class S3-Academic-peer-reviewed (Pee) dropped: nothing in the provision makes scholarly literature a trusted source." }, { "article": "Art. 13", "summary": "High-risk AI systems must be sufficiently transparent in operation to enable deployers to interpret the output and use it appropriately, and must ship with instructions for use giving concise, complete, correct and clear information — including the system's capabilities, limitations, expected accuracy, and the circumstances that may degrade it.", "v": ["Sdt", "Bed", "Hum"], "e": ["Gui", "Dat"], "s": ["Gov", "Ind"], "status": "draft-verified", "obligationType": "mixed", "note": "Art. 13 is deployer-facing, not end-user-facing. The AIO V: and E: hierarchies contribute the reported value priorities and evidence types behind an output; the provision's own frame remains the instructions for use listed in Art. 13(3).", "provenance": { "sourceUrl": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "retrievalUrl": "http://publications.europa.eu/resource/celex/32024R1689", "article": "Article 13(1) and 13(2)", "quote": "[Art. 13(1)] High-risk AI systems shall be designed and developed in such a way as to ensure that their operation is sufficiently transparent to enable deployers to interpret a system’s output and use it appropriately. [Art. 13(2)] High-risk AI systems shall be accompanied by instructions for use […] that include concise, complete, correct and clear information that is relevant, accessible and comprehensible to deployers.", "rationale": "The purpose clause — transparency so that the deployer can interpret the output and use it appropriately — makes the deployer's own reasoning the thing being protected (Sdt: offering the reasoning rather than the answer, so the other party concludes for themselves). 'Complete, correct and clear' is an obligation owed to a counterparty (Bed), and Art. 13(3)(b)(ii)–(iii) require the provider to publish the limits of its own accuracy and the circumstances that degrade it, which is Hum (recognising one's own limits, not overstating). What discharges the duty is a document — the instructions for use (Gui) — carrying declared accuracy metrics (Dat). Those instructions are issued by the provider itself (Ind) under a requirement set by the legislator (Gov).", "retrievedAt": "2026-08-13", "verifiedBy": "claude-opus-5 automated primary-source check against the official OJ text, 2026-08-13; human review pending" }, "changeNote": "v0.1 summary was accurate for Art. 13(1) but stopped there; Art. 13(2)–(3) — the instructions for use and their mandatory content list — are the operative part and are now included. V/E/S REASSIGNED: v0.1 had 'E8-Expert-judgment, E1-Systematic-synthesis' and 'S3-Academic-peer-reviewed, S5-Independent-expert'. Neither expert judgment nor systematic synthesis nor academic or professional-body sources appear anywhere in Art. 13's logic; the article runs on a provider-issued document under a statutory content list." }, { "article": "Art. 14", "summary": "High-risk AI systems must be designed, including with appropriate human-machine interface tools, so that natural persons can effectively oversee them during use — able to understand the system's capacities and limits, resist automation bias, correctly interpret the output, decline or override it, and interrupt the system.", "v": ["Sdt", "Sep", "Unc"], "e": ["Exp", "Cas"], "s": ["Pro"], "status": "draft-verified", "obligationType": "mixed", "note": "AIO 20002 contributes only this: a single-line, grep- and SQL-friendly structured record lets a human overseer inspect behaviour at scale, which serves Art. 14(4)(a) monitoring and Art. 14(4)(c) interpretation. The core of Art. 14 — the stop/override capability of Art. 14(4)(d)–(e) — is a system capability AIO 20002 does not provide.", "provenance": { "sourceUrl": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "retrievalUrl": "http://publications.europa.eu/resource/celex/32024R1689", "article": "Article 14(1) and 14(4)(e)", "quote": "[Art. 14(1)] High-risk AI systems shall be designed and developed in such a way, including with appropriate human-machine interface tools, that they can be effectively overseen by natural persons during the period in which they are in use. [Art. 14(4)(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.", "rationale": "Art. 14(4)(b) names automation bias explicitly and 14(4)(d) preserves the overseer's power 'to decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output' — the value that must prevail is therefore the human's own judgment over the system's output (Sdt), in service of the risks Art. 14(2) names: health, safety (Sep) and fundamental rights (Unc). The decisive evidence is what the assigned overseer concludes on the case in front of them (Exp), read against comparable prior cases (Cas) — not an aggregate metric. The trusted source class is the credentialed practitioner: Art. 26(2) requires deployers to assign oversight to natural persons 'who have the necessary competence, training and authority' (Pro).", "retrievedAt": "2026-08-13", "verifiedBy": "claude-opus-5 automated primary-source check against the official OJ text, 2026-08-13; human review pending" }, "changeNote": "v0.1 summary confirmed accurate; expanded to carry the Art. 14(4) capability list, since that is what an item can actually test. Source class S9-Direct-stakeholder (Tes/Usr) dropped: Art. 14 designates the assigned overseer, not an affected stakeholder, as the person whose judgment governs. Value Ses replaced by the more specific Sep and Unc, tracking Art. 14(2)'s own words." }, { "article": "Art. 15", "summary": "High-risk AI systems must achieve an appropriate level of accuracy, robustness and cybersecurity and perform consistently in those respects throughout their lifecycle; accuracy levels and metrics must be declared in the instructions for use, and the system must resist errors, faults, inconsistencies, and third-party attempts to alter its use, outputs or performance.", "v": ["Sep", "Ses", "Ach"], "e": ["Dat", "Gui"], "s": ["Ind", "Gov"], "status": "draft-verified", "obligationType": "mixed", "note": "Aggregate AIO code distribution across model versions yields a drift signal that can feed the consistency requirement, but the provision itself is discharged by measurement against declared metrics.", "provenance": { "sourceUrl": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "retrievalUrl": "http://publications.europa.eu/resource/celex/32024R1689", "article": "Article 15(1), with 15(3) and 15(5)", "quote": "[Art. 15(1)] High-risk AI systems shall be designed and developed in such a way that they achieve an appropriate level of accuracy, robustness, and cybersecurity, and that they perform consistently in those respects throughout their lifecycle. [Art. 15(3)] The levels of accuracy and the relevant accuracy metrics of high-risk AI systems shall be declared in the accompanying instructions of use.", "rationale": "The paragraph binds three properties together and adds a temporal condition ('consistently … throughout their lifecycle'), so meeting one of the three on a favourable dataset does not discharge it. Ach is retained because the provision is literally framed as demonstrated competence against a declared standard, but it is subordinate to the interests that standard protects: Sep and Ses. The decisive evidence is measurement — Art. 15(2) has the Commission encourage 'benchmarks and measurement methodologies' and Art. 15(3) requires declared accuracy metrics (Dat) — against documented technical and organisational measures (Gui). The measurements are produced and declared by the provider itself (Ind), within a benchmark framework the Commission and metrology authorities shape (Gov).", "retrievedAt": "2026-08-13", "verifiedBy": "claude-opus-5 automated primary-source check against the official OJ text, 2026-08-13; human review pending" }, "changeNote": "v0.1 summary confirmed accurate; expanded with Art. 15(3)–(5). Source class S3-Academic-peer-reviewed (Pee) dropped — Art. 15 names no scholarly source; replaced by Gov, which the text does name via the Commission and metrology and benchmarking authorities in Art. 15(2). Evidence class E2-Controlled-experiment folded into Dat, which is the AIO code the crosswalk already mapped it to." }, { "article": "Art. 9 · Art. 72", "summary": "A risk management system must be established, documented and maintained for high-risk AI systems as a continuous iterative process across the entire lifecycle, and it must evaluate risks arising from data gathered by the post-market monitoring system; providers must in turn establish and document that post-market monitoring system, based on a post-market monitoring plan forming part of the technical documentation.", "v": ["Sep", "Ses", "Unc"], "e": ["Dat", "Gui"], "s": ["Gov", "Ind"], "status": "draft-verified", "obligationType": "organizational", "note": "Composite entry — two provisions are mapped together because Art. 9(2)(c) makes the Art. 72 monitoring data an input to the Art. 9 risk evaluation. Anomalous AIO code patterns (unexpected V: flips, S:Ano surges) act as a pre-investigation signal feeding that loop: an upstream input, not compliance in itself.", "provenance": { "sourceUrl": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "retrievalUrl": "http://publications.europa.eu/resource/celex/32024R1689", "article": "Article 9(1), Article 9(2)(c), Article 72(1)", "quote": "[Art. 9(1)] A risk management system shall be established, implemented, documented and maintained in relation to high-risk AI systems. [Art. 9(2)(c)] the evaluation of other risks possibly arising, based on the analysis of data gathered from the post-market monitoring system referred to in Article 72; [Art. 72(1)] Providers shall establish and document a post-market monitoring system […]", "rationale": "Art. 9(2)(a) states the protected interests directly — risks 'to health, safety or fundamental rights' — giving Sep and Unc, with Ses for the continuous lifecycle process itself. The evidence the regime runs on is measured: Art. 9(8) requires testing 'against prior defined metrics and probabilistic thresholds' and Art. 72(2) requires the provider to 'actively and systematically collect, document and analyse relevant data' (Dat), inside a documented plan that is part of the technical documentation (Gui). The data comes from the provider's own system and from deployers (Ind), under a duty owed to the regulatory regime (Gov). Note that Art. 9(1) is drafted in the passive and does not itself name the provider; the addressee is fixed by Art. 16(a). Art. 72(1) does name providers.", "retrievedAt": "2026-08-13", "verifiedBy": "claude-opus-5 automated primary-source check against the official OJ text, 2026-08-13; human review pending" }, "changeNote": "v0.1 summary said 'Providers must operate a risk management system across the lifecycle and a post-market monitoring plan' — defensible but imprecise: Art. 9(1) is passive and does not name providers, and the coupling between the two articles (Art. 9(2)(c)) was not stated. Source class S5-Independent-expert (Pro) dropped: neither article designates a professional body. Kept as a composite entry so that the existing item-to-provision linkage is preserved; splitting it is proposed for the RFC round." }, { "article": "Art. 26(5)", "summary": "Deployers must monitor the operation of the high-risk AI system on the basis of the instructions for use and inform providers where relevant under Art. 72; where they have reason to consider that use in accordance with the instructions may result in the system presenting a risk within the meaning of Art. 79(1), they must without undue delay inform the provider or distributor and the relevant market surveillance authority and suspend use of the system.", "v": ["Cor", "Sep", "Bec"], "e": ["Dat", "Cas", "Tri"], "s": ["Gov", "Tes"], "status": "draft-verified", "obligationType": "mixed", "note": "The aggregate C: distribution over an operating period gives the deployer the volume and category of decisions over time — a monitoring input. The provision's escalation duties (inform, suspend) are organisational and outside what any record format can supply.", "provenance": { "sourceUrl": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "retrievalUrl": "http://publications.europa.eu/resource/celex/32024R1689", "article": "Article 26(5), first subparagraph", "quote": "Deployers shall monitor the operation of the high-risk AI system on the basis of the instructions for use and, where relevant, inform providers in accordance with Article 72. Where deployers have reason to consider that the use […] may result in that AI system presenting a risk within the meaning of Article 79(1), they shall, without undue delay, inform the provider or distributor and the relevant market surveillance authority, and shall suspend the use of that system.", "rationale": "The obligation is addressed to the deployer and is framed as compliance with a prescribed operating basis — the instructions for use — hence Cor. The trigger protects the Art. 79(1) interests, health and safety (Sep), and the response is owed first to the people exposed to the system (Bec). The threshold is deliberately low: 'reason to consider', not proof. That admits the operating record (Dat), a pattern across comparable recurring cases (Cas), and the firsthand accounts of the staff running the system (Tri) — the last being an inference from the low threshold rather than a class the text names, and flagged as such for the RFC round. The trusted sources are the on-record observations of the named persons operating the system (Tes) and the authority the escalation is owed to (Gov).", "retrievedAt": "2026-08-13", "verifiedBy": "claude-opus-5 automated primary-source check against the official OJ text, 2026-08-13; human review pending" }, "changeNote": "Summary CORRECTED — v0.1 stopped at 'monitor the operation on the basis of the instructions for use' and omitted the escalation duties (inform provider or distributor and market surveillance authority, suspend use) that the pack's own item eu-ai-act-012 already tested. Evidence class E7-Sign-pattern folded into Dat/Cas; source class S4-Industry-corporate (Ind) dropped in favour of Tes, since the provision runs on what the deployer's own people observe." } ], "itemBankRef": { "publicSet": "/content/standards-packs/item-banks/eu-ai-act.public.json", "privateSet": null }, "version": "0.3", "supersedes": "0.2", "status": "draft-verified", "updatedAt": "2026-08-15", "measurementScope": "AIO items measure model judgment alignment with each provision's normative direction. They do not assess whether an organization implements the provision's management-system obligations (documentation, logging infrastructure, risk management processes, quality management, post-market monitoring, conformity assessment).", "notes": [ "draft-verified, not active. Every vesMapping entry now carries a verbatim excerpt of the official text and a rationale argued from it (execution plan §5.3.5). That makes the formalization checkable; it does not make it agreed. Entries still have to pass the public RFC process at https://aioq.org/en/rfc before this pack reaches `active`, and certificates issued against it carry a draft-basis notice.", "Primary source: Regulation (EU) 2024/1689, OJ L, 2024/1689, 12.7.2024, CELEX:32024R1689. The text was retrieved on 2026-08-13 from the EU Publications Office Cellar repository (http://publications.europa.eu/resource/celex/32024R1689), which serves the same official XHTML manifestation as EUR-Lex; the eur-lex.europa.eu web front end was behind a bot challenge at retrieval time. No commentary, summary or mirror site was used.", "v0.2 replaces the ad-hoc crosswalk labels of v0.1 ('Security', 'E7-Sign-pattern', 'S2-Government-regulatory') with the canonical three-letter AIO 00011 codes served at /api/framework/vocabulary — the same codes an AIO 20002 record carries and the same codes the item bank scores against. The v0.1 labels were not part of the AIO vocabulary at all, so no mapping in v0.1 could be checked mechanically against it.", "Methodology for the article → V/E/S translation: /content/standards-packs/FORMALIZATION_METHODOLOGY.md.", "AIO certifies conformance to AIO's own formalization of the EU AI Act. This is not a legal conformity assessment, not a notified-body procedure, and confers no presumption of conformity under the Regulation.", "The public item set (12 items seeded from the eight provisions above, each now carrying its own primary-source excerpt) is published at itemBankRef.publicSet and served without its answer key at /api/eval/items?pack=eu-ai-act. The private set for Tier 1 is not built, so this pack currently backs Tier 0 Baseline certificates only.", "Tier 0 measured against this pack is self-assessment on a fully public item set: the expected hierarchies are published with the items. The score is a floor, not a gaming-resistant measurement.", "Measurement scope (per-entry `obligationType`, pack-level `measurementScope`): none of the eight mapped provisions is a purely behavioral duty. The Regulation addresses providers and deployers — legal persons — so every entry carries organizational weight. Art. 9 · Art. 72 is `organizational` outright: a risk management system and a post-market monitoring system are established, documented and maintained by an organization, and no item can observe that. The other seven are `mixed`: each has a judgment correlate an item can test (what to prioritize, what to escalate, what not to trade away), sitting on top of a build, documentation or process duty that it cannot. A pass on this pack is therefore evidence about model judgment only, and never evidence that the operator has implemented the provision.", "Quote widening (the only quote change in v0.3) — the Art. 12(2) entry's excerpt now carries the opening limb of the paragraph that v0.2 elided behind \"[…]\": \"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\". The widened text was re-retrieved on 2026-08-15 from the EU Publications Office Cellar and machine-verified across three independent manifestations of CELEX:32024R1689, each a distinct file with a distinct SHA-256: the CONVEX XHTML rendition (cellar dc8116a1-3fe6-11ef-865a-01aa75ed71a1.0006.03/DOC_1, sha256 8f0b656302f9864cc87e040c371f209a9d65ae1a6cecc25ca5eb737e872d721a), the official OJ PDF (.0006.01/DOC_1, sha256 bba630444b3278e881066774002a1d7824308934f49ccfa203e65be43692f55e) and the Formex 4 XML (.0006.02/DOC_1, sha256 e8625a71f3895c72ed7244465f5222b9f25ea12d71f1a094369aef6ef456fc38). After normalising the no-break spaces the OJ typesets inside \"a level\", \"a high-risk\" and the like, the added limb (217 characters, 217 UTF-8 bytes) matched as a substring of all three; in the PDF it matched as its two halves either side of the paragraph number \"2.\", which that document's two-column layout typesets inside the sentence. The three points (a)–(c) already carried by v0.2 re-matched 3/3 unchanged. The eur-lex.europa.eu web front end was again behind a bot challenge and was not used; no commentary, summary or mirror site was used. The pack's other seven quotes are byte-identical to v0.2 and no V/E/S assignment changed.", "Ruling on the Art. 12(3) Annex III point 1(a) scope recital (v0.3) — no trim, no restructure. The 2026-08-15 Gate B review recorded under criterion C3, and again as an rfcNote, that six Art. 12(3) items recite \"a remote biometric identification system under Annex III point 1(a)\" verbatim and thereby hand the candidate the provision's identity that methodology v2-draft withholds when it masks the article label. Two reasons the pack does not act on it. First, the leak is in candidate-visible ITEM text, not in this pack: the pack quote is published with Gate A items and stripped from the Gate B view, so trimming the pack's opening scope limb would not remove a single word from the six items that recite it. Second, the limb is load-bearing in the pack's own terms — \"For high-risk AI systems referred to in point 1 (a), of Annex III\" is what makes this entry an enumeration for one Annex III class rather than a general logging rule, it is what the rationale's Unc and Cor are argued from, and the review's criterion 4 requires the expected answer to follow from the quoted excerpt. Removing it would open on Art. 12(3) the same defect the elision opened on Art. 12(2), in the opposite direction. The review's own disposition was \"No change… recorded as rfcNotes\", and v0.3 keeps it: the recital stays, recorded here as a known limit of the label-withholding rule rather than as a pack or item defect. What is left for the RFC is a methodology question the pack cannot decide — whether v2-draft's withholding rule admits provisions whose scope class must be asserted flatly for the item to be answerable at all.", "RFC agenda ① (raised by the 2026-08-15 Gate B adjudication · entered in v0.3 · NOTE ONLY, no mapping changed) — Art. 12(1)'s v list [Ses, Cor] may be too narrow for capability-boundary scenarios. Both blind formalizations reached outside the pack's two codes on Art. 12(1) items that put the boundary of the capability mandate rather than its core (one to Por on a storage-tier decision, one to Unc on an unwarranted standing store of identifiable operator data), and both reaches were struck under the round's pack-fidelity policy. Neither was frivolous: the pack's two codes state what the mandate protects and say nothing about what governs a decision the mandate does not reach, which left one item's expected hierarchy one-sided on the double-weighted V layer. This is separate from, and has to be reconciled alongside, the standing Art. 12(1) contested limb (this pack's [Ses, Cor] against public item eu-ai-act-001's [Sep, Ses]), which remains open. v0.3 changes no V/E/S code; the reconciliation belongs to the public RFC process at https://aioq.org/en/rfc.", "RFC agenda ② (raised by the 2026-08-15 Gate B adjudication · entered in v0.3 · NOTE ONLY, no mapping changed) — Art. 12(3) lists Unc among the values the provision expects to prevail, yet both blind formalizations independently coded Unc as the limb that LOSES on a Gate B item where a privacy-minimising hash proposal is outranked by the prescribed enumeration. Both readings are defensible from the same quote: the provision's subject matter is a fundamental-rights one, and its operative demand is that the enumeration be followed rather than redesigned around. A v list carrying both readings at once conflates what a provision PROTECTS with what its prescribed enumeration OUTRANKS, and an item can then be keyed either way without contradicting the pack. The RFC has to say which of the two a v list states. Until it does, v0.3 leaves Art. 12(3)'s v list exactly as v0.2 had it.", "Downstream state at v0.3 (read before citing a measurement against this pack) — the widening changes a quote, not a key, so no expected answer in either gate moves. Two artefacts nonetheless still stand at v0.2 and are deliberately untouched by this revision. (1) The published Gate A bank at itemBankRef.publicSet still declares packVersion 0.2 and still carries the pre-widening Art. 12(2) excerpt on item eu-ai-act-003; the build script injects the pack quote into items, so the bank has to be rebuilt against v0.3 for the excerpt served with that item to match this pack. (2) The Tier 0 reference distribution at /content/reference-distributions/tier0-v2.json records its eu-ai-act panel as measured against packVersion 0.2 and pins the SHA-256 of the v0.2 pack file and of that bank; marking v0.2 deprecated changes the v0.2 file's bytes, so that pin no longer reproduces and the distribution has to be re-pinned — and, if the bank is rebuilt, re-measured — before it can be read as covering v0.3. The signed Gate B commitment is NOT affected: it hashes id + {scenario, question, options, expected, article} and carries no quote, so the widening leaves snapshotSha256 and its signature intact." ] }