Merge pull request #7 from Amosk21/claude/enterprise-positioning-shift-LIoEQ

Claude/enterprise positioning shift l io eq

Author: Amosk21

CLAUDE.md

@@ -1,159 +1,70 @@
-# ARCO — Claude Code Project Instructions
+# ARCO — Claude Code Instructions
 
-## Project Identity
+ARCO = BFO/CCO-aligned OWL ontology for deterministic EU AI Act risk classification. OWL-RL reasoning + SHACL validation + SPARQL ASK produce outputs. No LLMs in the pipeline.
 
-ARCO (Assurance & Regulatory Classification Ontology) is a BFO/CCO-aligned ontological framework for deterministic AI system risk classification under the EU AI Act. It produces regulatory determinations as logical consequences of modeled system structure, not probabilistic assessments.
-
-## Repository Structure
-
-```
-03_TECHNICAL_CORE/
-  ontology/
-    ARCO_core.ttl              — Core ontology (BFO-aligned classes, bridge axioms)
-    ARCO_governance_extension.ttl — Provider roles, documentation workflow
-    ARCO_instances_sentinel.ttl   — Sentinel-ID demo system instances
-  validation/
-    assessment_documentation_shape.ttl — SHACL shapes
-  reasoning/
-    check_high_risk_inference.sparql
-    check_assessment_traceability.sparql
-    detect_latent_risk.sparql
-    ask_provider_role_inheres_in_org.sparql
-  scripts/
-    run_pipeline.py            — Main execution pipeline
-```
-
-## Tech Stack
-
-- Python 3.10+, rdflib, pyshacl, owlrl
-- OWL 2 (Turtle syntax), SHACL, SPARQL ASK queries
-- OWL-RL reasoning profile via owlrl library
-- GitHub Actions CI (`.github/workflows/arco-demo.yml`)
-
-## Build & Verify Commands
+## Build & Verify
 
 ```bash
 pip install -r requirements.txt
 python 03_TECHNICAL_CORE/scripts/run_pipeline.py
 ```
 
-Pipeline must: load ontology + instances → run OWL-RL reasoning → run SHACL validation → run all SPARQL ASK queries → emit REGULATORY DETERMINATION CERTIFICATE → write artifacts to runs/demo/
-
-## Hard Constraints (NEVER violate these)
-
-1. **BFO/CCO Maximal Alignment**: Every class must trace to a BFO 2020 category. Every relation must use BFO or RO IRIs. No invented object properties. If CCO provides an applicable class or relation, use it. If a new domain class is needed, it must be a proper subclass of an existing BFO/CCO class with explicit justification. When reusing CCO IRIs locally (without full import), declare them with proper OWL typing (`owl:Class`, `owl:ObjectProperty`) — not just `rdfs:label` triples.
-
-2. **No Ad-Hoc Relations**: Do NOT create custom object properties like `intended_for_use_in`, `deployed_in_context`, `affects_persons`, etc. Use existing BFO/RO/IAO/CCO relations. When modeling "intended use," use the CCO Directive Information Content Entity + `cco:prescribes` pattern (see Ontological Patterns below).
-
-3. **Backward Compatibility**: Do not delete existing classes, instances, or inference chains. The Sentinel-ID demo must continue to pass all existing checks after any change. New additions must be additive.
-
-4. **Reality vs. Representation Separation**: System capabilities are reality-side (BFO dispositions inhering in independent continuants). Regulatory provisions, plans, and classifications are representation-side (IAO Information Content Entities). Never conflate these.
-
-5. **Deterministic Pipeline**: Classification must be derivable via OWL reasoning + SPARQL ASK queries. No probabilistic, scoring, or LLM-based classification in the pipeline itself.
-
-6. **Relation Vocabulary**: Use `ro:0000091` (has_disposition) for disposition relations, NOT `ro:0000053` (bearer_of). This is already established in the codebase.
-
-7. **No Future Particulars**: Do NOT create instances of processes that have not occurred. Intent is represented via directive information entities that are *about* universals (classes), not as instantiated future events. If modeling "the system is intended for biometric identification," create a Directive ICE that `cco:prescribes` a process *type* (class) — not a process instance.
-
-8. **Legal Categories Are Not Biological Kinds**: "Natural person" is a legal designation under EU law, not a biological universal. Model it as `NaturalPersonRole ⊑ bfo:0000023 (Role)`, not as a subclass of Object or Person. Anchor the role to a person continuant (`cco:Person`) so readers know what kind of entity bears it, but do NOT create person instances or role-bearing axioms for the demo. This applies to any legal status or classification.
-
-## Ontological Patterns (Use These)
-
-### Modeling "Intended Use" (CCO-Aligned)
-
-The EU AI Act classifies systems based on "intended use" (Annex III: "AI systems intended to be used for..."). In BFO/CCO, intended use is NOT a relation from system to context. It is a **Directive Information Content Entity** that **prescribes** a process type.
-
-**CCO Pattern**: `cco:DirectiveInformationContentEntity` uses `cco:prescribes` (domain: DirectiveICE, range: Entity). The `prescribes` relation means "serves as a rule or guide for an Occurrent, or serves as a model for a Continuant."
-
-**Implementation**:
-```turtle
-# Class level (in governance extension)
-:IntendedUseSpecification rdfs:subClassOf cco:DirectiveInformationContentEntity .
-
-# Instance level
-:Sentinel_IntendedUse_001 a :IntendedUseSpecification ;
-  cco:prescribes :RemoteBiometricIdentificationProcessType ;
-  iao:0000136 :Sentinel_ID_System ;
-  iao:0000136 :RemoteBiometricIdentificationProcessType .
-```
-
-This means: "There exists a directive information artifact that is about the Sentinel system and that prescribes a remote biometric identification process type."
-
-### Modeling Use Scenario Context (CCO-Aligned)
-
-Annex III items specify not just capability and process, but **affected entities** ("of natural persons"). This context is modeled as a separate Directive ICE — a `UseScenarioSpecification` — that constrains the realization context. It is `iao:0000136` (is_about) the system, the process type, the person universal, and the legal role:
-
-```turtle
-:UseScenarioSpecification rdfs:subClassOf cco:DirectiveInformationContentEntity .
-
-:Sentinel_UseScenario_001 a :UseScenarioSpecification ;
-  iao:0000136 :Sentinel_ID_System ;
-  iao:0000136 :RemoteBiometricIdentificationProcessType ;
-  iao:0000136 cco:Person ;
-  iao:0000136 :NaturalPersonRole .
-```
-
-This reads: "the scenario concerns persons, specifically under the legal designation natural person." It gives a **three-gate** Annex III classification: capability (reality-side) + intended use (process prescribed) + scenario (who is affected).
-
-### Modeling Regulatory Provisions
-
-Annex III conditions are ICE instances. They use `iao:0000136` (is_about) to reference ALL universals they regulate — capability, process type, and affected role. This makes conditions interoperable across systems (different AI systems can be evaluated against the same regulatory condition without bespoke mapping).
-
-### Modeling Classification Determination
-
-`HighRiskDetermination` is a subclass of `ComplianceDetermination` (which is an ICE). It is `iao:0000136` (is_about) the system AND the Annex III condition. It is the **output** of a process (`cco:has_output`).
-
-### Component-Level Disposition Tracing
-
-AI systems (ObjectAggregate) `bfo:0000051` (has_part) SystemComponents. SystemComponents `ro:0000091` (has_disposition) CapabilityDispositions. This traces regulatory exposure to the component that bears the capability — the "latent capability" insight. Preserve this pattern.
-
-## EU AI Act Alignment Requirements
+Run after every change. Must print "ALL CHECKS PASSED" and exit 0.
 
-### Annex III Structure
-Every Annex III item follows the pattern: "AI systems **intended to be used** for [capability/process] **of** [affected entities] in [domain context]". Full classification requires:
-- The system bears the relevant capability disposition (reality-side)
-- There exists an intended use specification prescribing the regulated process type (directive ICE)
-- There exists a use scenario specification constraining the realization context to affected entities (directive ICE)
+## Context Selection
 
-### Article 6(3) Derogation
-An Annex III system may NOT be high-risk if it "does not pose a significant risk of harm" — specifically if:
-- (a) intended to perform a narrow procedural task
-- (b) intended to improve the result of a previously completed human activity
-- (c) intended to detect decision-making patterns without replacing/influencing assessment
-- (d) intended to perform a preparatory task
+### PRIORITY (auto-load for technical tasks)
+- `03_TECHNICAL_CORE/ontology/*.ttl` — Ontology + instances
+- `03_TECHNICAL_CORE/validation/*.ttl` — SHACL shapes
+- `03_TECHNICAL_CORE/scripts/run_pipeline.py` — Pipeline
+- `03_TECHNICAL_CORE/reasoning/*.sparql` — SPARQL ASK queries
 
-**Exception to the exception**: profiling of natural persons ALWAYS triggers high-risk.
+### SECONDARY (only if explicitly needed)
+- `01_COMMERCIAL/`, `02_SYSTEM_OVERVIEW/`, `04_DIAGRAMS_AND_MODELS/`, `05_TECHNICAL_IMPLEMENTATION/`
+- `README.md`, `ONTOLOGY_REVIEW.md`, `.github/workflows/`
 
-Model derogation claims as ICE artifacts (descriptive, asserting non-significance) that can be queried.
+### NEVER AUTOLOAD
+- `runs/demo/*`, `03_TECHNICAL_CORE/.venv/`, generated artifacts, logs
 
-### Annex III Category 1 — Biometrics (Current Focus)
-- 1(a): Remote biometric identification systems (NOT verification-only)
-- 1(b): Biometric categorisation by sensitive attributes
-- 1(c): Emotion recognition
+## Architectural Memory
 
-The Sentinel-ID demo covers 1(a). The exclusion for "biometric verification the sole purpose of which is to confirm identity" is important and should eventually be modelable.
+### Classes — Reality-Side (`ARCO_core.ttl`)
+- `System` ⊑ ObjectAggregate — has_part some SystemComponent
+- `SystemComponent` ⊑ Object; `HardwareComponent` ⊑ SystemComponent — has_disposition some CapabilityDisposition
+- `CapabilityDisposition` ⊑ Disposition; `BiometricIdentificationCapability` ⊑ CapabilityDisposition
+- `SoftwareArtifact` ⊑ ICE — NOT a SystemComponent
 
-## Current Known Issues (Fix These)
+### Classes — Representation-Side (`ARCO_core.ttl`)
+- `ComplianceDetermination` ⊑ ICE; `HighRiskDetermination` ⊑ ComplianceDetermination
 
-**NOTE: The pipeline (Phase 0) is already fixed and working.** It runs OWL-RL reasoning, all SPARQL queries, SHACL validation, emits the certificate, and prints "ALL CHECKS PASSED." The issues below are what remain:
+### Classes — Governance (`ARCO_governance_extension.ttl`)
+- `IntendedUseSpecification`, `UseScenarioSpecification`, `ComplianceObligationSpecification` ⊑ DirectiveICE
+- `ProviderOrganization` ⊑ Organization; `ProviderRole`, `DeployerRole` ⊑ Role
+- `NaturalPersonRole` ⊑ Role; `RemoteBiometricIdentificationProcess` ⊑ Process
+- `AnnexIII1aApplicableSystem` ≡ 3-gate (capability + intended use + scenario)
 
-1. **Instance typing**: `HighRisk_Determination_001` is typed as `:ComplianceDetermination` but should be `:HighRiskDetermination` (which subclasses it).
+### Bridge Axioms
+- `AnnexIIITriggeringCapability` ≡ union(BiometricIdentificationCapability)
+- `HighRiskSystem` ≡ System ∩ has_part some (has_disposition some AnnexIIITriggeringCapability)
 
-2. **No intended use modeling**: Current bridge axiom fires on capability alone without intended use context. This is ontologically incomplete per Annex III.
+### Relations (all BFO/RO/IAO/CCO — no custom properties)
+`bfo:0000051` has_part · `ro:0000091` has_disposition · `iao:0000136` is_about · `cco:prescribes` · `cco:has_output` · `ro:0000057` has_participant · `ro:0000087` has_role
 
-3. **Hardware-only component constraint**: `SystemShape` SHACL requires hardware components only. Should allow broader `SystemComponent` class.
+### Pipeline Flow
+Load TTL → OWL-RL → SHACL → SPARQL ASK → certificate → `runs/demo/`
 
-## Regression Testing
+## Execution Rules
 
-Run `python 03_TECHNICAL_CORE/scripts/run_pipeline.py` after every coherent unit of change. Pass criteria: OWL-RL reasoning runs, all SPARQL queries return True, SHACL conforms, certificate emits, "ALL CHECKS PASSED" prints, exit 0. If a step breaks the pipeline, fix it before proceeding. Do not batch changes that touch existing triples, restrictions, or shapes — test immediately.
+- Use Architectural Memory before reading files. Do not re-derive architecture. Do NOT read TTL files to answer conceptual questions — use the Architectural Memory. Only read TTL files when editing them or verifying exact syntax, unless instructed for an extensive or full review.
+- No repo-wide scanning. Grep within `03_TECHNICAL_CORE/` only.
+- Minimal patches. No full rewrites unless requested.
+- After every change, run pipeline. Do not batch changes to triples/shapes.
+- If usage is low: save state, short summary, stop.
 
-## What NOT To Do
+## Detail Files (load only when needed)
 
-- Do not rewrite the HighRiskSystem OWL equivalentClass axiom yet (keep capability-based inference as "latent risk detection")
-- Do not model all 8 Annex III categories — biometrics only for now
-- Do not create a separate file for every Annex III item
-- Do not add CCO as a full import (too heavy) — declare needed CCO classes/relations locally with their IRIs and proper OWL typing
-- Do not refactor directory structure
-- Do not touch GitHub Actions workflow files unless pipeline output format changes require it
-- Do not model NaturalPerson as a biological subclass — if you need a person universal, use `cco:Person`; represent "natural person" as `NaturalPersonRole ⊑ bfo:Role`
-- Do not create Person instances or role-bearing axioms for the demo — use aboutness (`iao:0000136`) only
+| File | Read when... |
+|------|-------------|
+| `docs/agent/ontology_rules.md` | Editing TTL, adding classes/relations, modeling new concepts |
+| `docs/agent/coding_rules.md` | Modifying pipeline, scripts, CI, repo structure |
+| `docs/agent/eu_ai_act_rules.md` | Working on Annex III, Article 6, classification logic |