fix(citations): correct EU AI Act anchors for verification carve-out

03_TECHNICAL_CORE/ontology/ARCO_instances_verification.ttl

@@ -15,7 +15,7 @@
 
   Non-entailment claim: AnnexIII1aApplicableSystem is not entailed for VerificationKiosk_001 under current assertions (OWA — no closed-world guarantee).
 
-  Legal basis: Recital 22 and Art. 3(41) EU AI Act — 1:1 biometric verification is excluded from Annex III 1(a); only 1:N remote biometric identification triggers classification.""" ;
+  Legal basis: Recital 15, Recital 17, and Annex III item 1(a) of EU AI Act 2024/1689 — the verification carve-out ("intended to be used for biometric verification, which includes authentication, whose sole purpose is to confirm that a specific natural person is the person he or she claims to be") excludes 1:1 biometric verification from biometric identification (Recital 15) and from remote biometric identification systems specifically (Recital 17, rationale: minor impact on fundamental rights), and is reaffirmed in the Annex III 1(a) operative text. Article 3(36) defines biometric verification as the automated 1:1 modality; Article 3(41) defines the RBI system. Only 1:N remote biometric identification triggers Annex III 1(a) classification.""" ;
   owl:imports <https://arco.ai/ontology/governance> .
 
 #################################################################
@@ -24,7 +24,7 @@
 
 :AnnexIII_Condition_1a_Exclusion rdf:type :RegulatoryContent ;
   rdfs:label "Annex III 1(a) — Verification Exclusion Note" ;
-  rdfs:comment "Documents the 1:1 verification exclusion from Annex III 1(a). Recital 22 and Art. 3(41): only 1:N remote biometric identification triggers the Annex III classification." ;
+  rdfs:comment "Documents the 1:1 verification exclusion from Annex III 1(a). Recital 15, Recital 17, and Annex III 1(a) operative carve-out: only 1:N remote biometric identification triggers the Annex III classification. Article 3(36) defines 1:1 verification; Article 3(41) defines the RBI system." ;
   iao:0000136 :BiometricVerificationCapability ;
   iao:0000136 :BiometricIdentificationCapability .
 

03_TECHNICAL_CORE/reasoning/select_system_comment.sparql

@@ -3,8 +3,9 @@ PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
 # EMISSION LAYER — binds rdfs:comment of the system under evaluation.
 #
 # Used by the negative-case output to surface fixture-supplied regulatory
-# reasoning (e.g., the kiosk fixture's comment naming Recital 22 / Article
-# 3(41) and the verification-vs-identification distinction). The comment
+# reasoning (e.g., the kiosk fixture's comment naming Recital 15 + Recital
+# 17 + Annex III 1(a) carve-out and the verification-vs-identification
+# distinction). The comment
 # is fixture-authored ground truth and ships with the TTL; this query
 # avoids embedding fixture-specific legal text as Python literals in the
 # emitter (per CLAUDE.md Output discipline).

03_TECHNICAL_CORE/scripts/run_pipeline.py

@@ -442,9 +442,10 @@ def get_system_comment(g: Graph, system_local: str) -> str:
     """Return rdfs:comment of the system instance, or empty string.
 
     Used by the negative-case Provider Obligations panel to surface fixture-
-    authored regulatory reasoning (e.g., the kiosk fixture's note on Recital
-    22 / Article 3(41)) as a documentary scope text rather than a Python
-    literal in the emitter. Returns "" on query failure or empty result;
+    authored regulatory reasoning (e.g., the kiosk fixture's note on
+    Recital 15 + Recital 17 + Annex III 1(a) carve-out) as a documentary
+    scope text rather than a Python literal in the emitter. Returns "" on
+    query failure or empty result;
     emitter is responsible for skipping the panel when empty.
     """
     try:
@@ -1240,8 +1241,9 @@ def edge_el(rel, iri_label=""):
         # ARCO does not model Title IV obligations; see LIMITATIONS §2). It
         # is dropped here.
         # When the loaded fixture provides a system-level rdfs:comment with
-        # regulatory framing (e.g., the kiosk fixture's note on Recital 22
-        # / Art. 3(41)), surface it via the documentary scope text path
+        # regulatory framing (e.g., the kiosk fixture's note on Recital 15 +
+        # Recital 17 + Annex III 1(a) carve-out), surface it via the
+        # documentary scope text path
         # declared in output_manifest_v2.yaml. Otherwise the panel reports
         # the OWA-bounded non-entailment note alone.
         if system_comment:

LIMITATIONS.md

@@ -111,7 +111,7 @@ Gate 1 locates the capability disposition on a `SystemComponent`, not on the `Sy
 
 A second, narrower simplification sits inside this gate: for a model-driven biometric module, the in-repo Sentinel fixture types the bearer as `:HardwareComponent` only, but a strict realist reading would locate the disposition on the *amalgam* of hardware plus the concretized model artifact running on it. The 2024 Capabilities paper's hardware-software-amalgam discussion treats software qua pattern as a generically dependent continuant, not itself a capable continuant; capabilities require a material bearer that concretizes the pattern. ARCO's classification result does not depend on which of these two bearer choices is taken — Gate 1 is satisfied as long as some component bearer instantiates a triggering-capability disposition — so the simplification is documented here rather than rebuilt as a structural change.
 
-A third, related point: for software-configurable AI systems where the same hardware can be configured for different modes (e.g., 1:1 verification vs 1:N identification on the same biometric kiosk hardware), the disposition assertion describes what THIS specific deployment is intended to do under its current commitments, not what the hardware-in-isolation could theoretically do. ARCO does not make closed-world hardware-incapability claims; per-fixture disposition assertions reflect the configured-system commitments under OWA. A different deployment of the same hardware (different configuration, software, or database) would be modeled as a separate `:System` instance with its own asserted disposition. This matches the EU AI Act's classification on intended use (Article 3(36), Recital 15), not on raw hardware capability. Validated 2026-05-10 against vendor documentation for Suprema, ZKTeco, Matrix, HID, and IDEMIA biometric kiosks, all of which advertise the same hardware as configurable for both 1:1 and 1:N modes.
+A third, related point: for software-configurable AI systems where the same hardware can be configured for different modes (e.g., 1:1 verification vs 1:N identification on the same biometric kiosk hardware), the disposition assertion describes what THIS specific deployment is intended to do under its current commitments, not what the hardware-in-isolation could theoretically do. ARCO does not make closed-world hardware-incapability claims; per-fixture disposition assertions reflect the configured-system commitments under OWA. A different deployment of the same hardware (different configuration, software, or database) would be modeled as a separate `:System` instance with its own asserted disposition. This matches the EU AI Act's classification on intended use (Recital 15, Recital 17, and the Annex III 1(a) operative carve-out, which together carry the "intended to be used for biometric verification" framing), not on raw hardware capability. Article 3(36) supplies the underlying 1:1 verification definition. Validated 2026-05-10 against vendor documentation for Suprema, ZKTeco, Matrix, HID, and IDEMIA biometric kiosks, all of which advertise the same hardware as configurable for both 1:1 and 1:N modes.
 
 ### 3.6 Reality/representation split
 
@@ -138,7 +138,7 @@ The IUS subkind family is membership-fixed by Annex III categorial criterion, no
 
 #### 3.7.c Real-time vs. post RBI subclass declaration; Article 5 routing scoped future
 
-ARCO declares `:PostRemoteBiometricIdentificationProcess` (Article 3(43): a remote biometric identification process other than real-time) and `:RealTimeRemoteBiometricIdentificationProcess` (Article 3(42): capturing, comparison and identification all occurring without a significant delay, comprising not only instant identification but also limited short delays in order to avoid circumvention) as disjoint subclasses of `:RemoteBiometricIdentificationProcess`. The disjointness is correct: the regulation defines the two as exhaustive subtypes within the parent term.
+ARCO declares `:PostRemoteBiometricIdentificationProcess` and `:RealTimeRemoteBiometricIdentificationProcess` as disjoint subclasses of `:RemoteBiometricIdentificationProcess`. The regulatory verbatim text uses "system" rather than "process": Article 3(43) defines a post-RBI system as "a remote biometric identification system other than a real-time remote biometric identification system," and Article 3(42) defines a real-time RBI system as one whereby "the capturing of biometric data, the comparison and the identification all occur without a significant delay, comprising not only instant identification, but also limited short delays in order to avoid circumvention." ARCO models these as Process subclasses (BFO Bucket 4 / Occurrent) since classification reasons over the deployment-and-operation occurrence rather than the system artifact alone; the class-name "Process" is ARCO's modeling translation of the regulation's "system" term. The disjointness is correct: the regulation defines the two as exhaustive subtypes within the parent term.
 
 The Annex III 1(a) Gate 2 axiom continues to reference the parent class via `someValuesFrom`, so subclass propagation means an IUS prescribing either a real-time or a post RBI process particular satisfies Gate 2 and entails `:AnnexIII1aApplicableSystem`. No fixture is currently typed into either subclass; both are forward-declared.
 

docs/MODELING_ROADMAP.md

@@ -12,7 +12,7 @@ ARCO is the EU AI Act Annex III classifier I've been building. You hand it a str
 
 Mechanically: the classification axioms are written as `owl:equivalentClass` `owl:intersectionOf` definitions with three gates (capability disposition, intended use, affected role) at `03_TECHNICAL_CORE/ontology/ARCO_governance_extension.ttl`. The reasoning runs against BFO 2020, RO 2025-12-17, IAO 2026-03-30, and CCO v1.7-2024-11-03 commitments under OWL-RL. SHACL runs after reasoning to catch documentation inconsistencies. HermiT (under OWL 2 DL) runs in CI as an independent second reasoner so I'm not trusting a single inference profile. Outputs are gated through a failing-by-design provenance contract (`output_manifest_v2.yaml`, `test_output_provenance.py`) that refuses to ship a value unless its source is either graph-backed (named SPARQL query), run-metadata (declared sources), or a labeled documentary block.
 
-Seven fixtures drive this today: two production positives (Sentinel ID for 1(a), Credit Scoring for 5(b)), one negative control (Verification Kiosk, a 1:1 biometric verification system that should not classify under 1(a), since verification is not identification per Recital 22 and Art. 3(41)), two adversarial fixtures (one decoy that injects an `owl:equivalentClass` to test whether the gates collapse on hostile input, one with an anonymous blank-node disposition to test whether the reasoner needs named individuals), and two flag-test fixtures (where all three Annex III gates are satisfied alongside an audit-layer flag like a provider-asserted derogation claim or a fraud-detection process token, to verify classification and audit don't bleed into each other).
+Seven fixtures drive this today: two production positives (Sentinel ID for 1(a), Credit Scoring for 5(b)), one negative control (Verification Kiosk, a 1:1 biometric verification system that should not classify under 1(a), since verification is not identification per Recital 15, Recital 17, and the Annex III 1(a) operative carve-out (Article 3(36) defines biometric verification as 1:1; Article 3(41) defines the RBI system)), two adversarial fixtures (one decoy that injects an `owl:equivalentClass` to test whether the gates collapse on hostile input, one with an anonymous blank-node disposition to test whether the reasoner needs named individuals), and two flag-test fixtures (where all three Annex III gates are satisfied alongside an audit-layer flag like a provider-asserted derogation claim or a fraud-detection process token, to verify classification and audit don't bleed into each other).
 
 The EU AI Act lists 8 high-risk Annex III categories. I've modeled 2. The other 6 are deferred and I'm honest about that in `LIMITATIONS.md` §1.
 
@@ -65,7 +65,7 @@ These are deliberate choices I've made. Each one is also disclosed in `LIMITATIO
 - BFO Bucket 5 (Site) and Bucket 6 (TemporalRegion) not modeled. ARCO is a design-time classifier, so runtime spatial/temporal regions don't carry weight at the entailment layer. If I extend ARCO to monitor jurisdiction-specific deployment or substantial modification, these activate (LIMITATIONS §3.7).
 - Provider-organization-to-ICE structural link not modeled (per PR #62).
 - Source documents do not auto-promote to reality-side commitments. Promotion is rare, conditional, and human-adjudicated per `docs/EVIDENCE_TO_COMMITMENT_POLICY.md`. I've been deliberate about not letting extraction wire directly to instance TTL.
-- Closed-world hardware-incapability claims for software-configurable systems are forbidden. EU AI Act Annex III 1(a) keys on Article 3(36) "intended to be used" language, not on what the hardware in isolation can do (LIMITATIONS §3.5).
+- Closed-world hardware-incapability claims for software-configurable systems are forbidden. EU AI Act Annex III 1(a) keys on the "intended to be used for biometric verification" language present in Recital 15, Recital 17, and the Annex III 1(a) operative carve-out, not on what the hardware in isolation can do. Article 3(36) supplies the technical 1:1 verification definition (LIMITATIONS §3.5).
 
 ---
 

docs/kiosk_demo_v1/kiosk_demo.md

@@ -62,7 +62,7 @@ The source explicitly refuses two closed-world claims:
 - It does NOT claim the underlying hardware is structurally incapable of identification (the hardware is software-configurable).
 - It does NOT claim what the hardware could be configured to in some other deployment.
 
-Article 3(36) of EU Regulation 2024/1689 keys Annex III 1(a) on intended use, not on raw hardware capability. The source packet describes THIS deployment under THIS configuration.
+Annex III item 1(a) of EU Regulation 2024/1689 keys high-risk RBI classification on intended use ("intended to be used for biometric verification" carve-out per Recital 15, Recital 17, and the Annex III 1(a) operative clause), not on raw hardware capability. Article 3(36) supplies the technical 1:1 verification definition. The source packet describes THIS deployment under THIS configuration.
 
 (\*) **Real vendor document substitution is `OPEN_PROBLEMS.md L1.1`.** The next concrete move replaces this hypothetical with a real vendor packet (datasheet, conformity declaration, or equivalent), with each claim cited.
 
@@ -169,7 +169,7 @@ The vision is the full input-mile-to-honest-certificate chain wired programmatic
 - (\*) **Configuration-level aboutness for regulatory ICEs** — `:AnnexIII_Condition_*` ICEs need explicit `iao:is_about` targets; canonical options surfaced (universal-only / particular continuant / multiple constituents). `M-Aboutness-Config-1 / L2.7`.
 - (\*) **`:CapabilityDisposition` rename to `:Capability`** — Smith-Against-Idiosyncrasy Principle 8 compositional naming fix; mechanical PR. `M-NameDiscipline-1 / L2.8`.
 - (\*) **Gate 3 role-relationship tightening** — current axiom designates the natural-person role universal but does not pin down whether natural persons are subjects of identification, operators, or another role-in-context. `L2.9`.
-- (\*) **Gate 2 use-purpose proxy tightening** — current axiom maps Article 3(36) "intended to be used for" to `cco:prescribes someValuesFrom :Process`; defensible structural proxy but loose. `L2.10`.
+- (\*) **Gate 2 use-purpose proxy tightening** — current axiom maps the "intended to be used for" framing (from Recital 15, Recital 17, and Annex III 1(a)) to `cco:prescribes someValuesFrom :Process`; Article 3(36) supplies the technical 1:1 verification definition the axiom presupposes. Defensible structural proxy but loose. `L2.10`.
 - (\*) **Reasoned-graph and HermiT classification artifact export** — surface the full entailment chain inspectably. `L4.8 parts 1-2`.
 - (\*) **Prose determination narrative emission** — generated from existing SPARQL gate evidence so a non-ARCO-glossary reader can read the conclusion + the reason in one paragraph. `L4.8 part 3`.
 - (\*) **Output provenance tightening** — G/M/D field labels, per-field source-query manifest, name/source mismatches across surrounding cert fields. `L4.4-L4.6`.