Assurance & Regulatory Classification Ontology
ARCO was built to take some of the weight off the people deploying AI systems under new regulation. Whether a system counts as high-risk under the EU AI Act tends to surface late, and the answer has to be right early, before the build is already shaped around a guess and the time is sunk. You can't put a lawyer on every design decision, and even a good one doesn't know the system the way the team building it does, so what comes back is slow and hedged.
The underlying problem is older than AI regulation and better documented. A decade after the Basel Committee published its principles for risk data aggregation, its own 2023 review found two of thirty-one globally systemic banks fully compliant. That is evidence that data-governance problems can persist after years of investment. It establishes nothing about whether an ontology fixes them, and nobody in that report is selling one.
ARCO gives a first, scoped answer to the high-risk question and shows the work behind it. You give it a reviewed structured description of a system: which capability reviewers are prepared to commit to, what the system is meant to be used for, and which affected role the use scenario names. ARCO tests whether those commitments satisfy its encoding of one of two modeled Annex III categories. It then lays out the evidence path and axioms behind that result, giving leadership, a regulator, or counsel a structured starting point and a specific place to challenge the model.
It's a working proof that a tool like this can be built and checked, not a finished product. Under the pinned logic and dependencies, the same structured description produces the same result, so another reviewer can re-run it. The missing product layer is a usable workflow that takes a plain vendor document, surfaces candidate commitments, and supports expert adjudication before they enter the graph. That is not done yet.
Underneath, ARCO runs on a formal foundation called BFO. It's an international standard (ISO/IEC 21838-2), and in January 2024 the Department of Defense Chief Digital and AI Officer and the Intelligence Community Chief Data Officer directed it as one of three baselines for their own formal ontology work. In plain terms, BFO supplies public upper-level categories and relations. It does not make an input true, but it makes ARCO's commitments more explicit than labels alone.
The two modeled categories share the same three-part pattern: what capability is committed, what the system is intended for, and which affected role is named. The last two are what the Annex III conditions themselves turn on. The capability check is ARCO's own addition rather than something the law asks for, which means ARCO wants more evidence before it will fire and can therefore stay silent on a system the Act would catch. The pattern may transfer to other categories or rulebooks, but that has to be established case by case through new legal, evidence, and modeling work. It has been built out for two EU high-risk categories so far.
The straight version: this is a solo open-source project. Two of the eight high-risk categories so far, no lawyer has signed off on the legal reading, and it's a working proof of the idea, not something to drop into a compliance team tomorrow. Everything it can't do is written down plainly in LIMITATIONS.md, on purpose.
flowchart LR
SRC["Source documentation<br/>(vendor docs, intended use,<br/>technical specs)"]
ADJ["Human adjudication<br/>(evidence ledger)"]
COMMIT["Reviewed RDF commitments<br/>(BFO-grounded model)"]
REASON["OWL entailment<br/>OWL-RL + HermiT cross-check"]
AUDIT["SHACL completeness<br/>+ SPARQL evidence audit"]
CERT["Certificate<br/>+ evidence path"]
SRC -.-> ADJ
ADJ -.-> COMMIT
COMMIT --> REASON
REASON --> AUDIT
AUDIT --> CERT
style SRC fill:#cbd5e1,stroke:#475569,color:#0f172a,stroke-width:2px
style ADJ fill:#fed7aa,stroke:#c2410c,color:#7c2d12,stroke-width:2px
style COMMIT fill:#bfdbfe,stroke:#1d4ed8,color:#1e3a8a,stroke-width:2px
style REASON fill:#bbf7d0,stroke:#15803d,color:#14532d,stroke-width:2px
style AUDIT fill:#fde68a,stroke:#b45309,color:#78350f,stroke-width:2px
style CERT fill:#f5d0fe,stroke:#a21caf,color:#581c87,stroke-width:2px
Solid arrows run on every push. The two dashed arrows are the source-to-commitment step: designed, disclosed, and not yet programmatically backed for any fixture.
From reviewed RDF commitments onward, every implemented arrow is inspectable. The source-to-commitment step is documented but not yet programmatically backed in a public fixture: the kiosk demo uses a hypothetical packet and evidence ledger. Human adjudication determines which source claims warrant RDF commitments in ARCO's BFO-grounded model. The OWL reasoner derives ARCO's classification by entailment over those commitments and the public axioms. A second reasoner (HermiT, full OWL 2 DL profile) independently agrees on every push. SHACL validates that the supporting documentary record is structurally complete. SPARQL queries inspect the reasoned graph for the specific evidence each classification rests on. The certificate writes the classification, the evidence path, and the supporting structure in one place.
When a classification looks wrong, the chain helps narrow the disagreement to a modeled commitment, an axiom, or an output step. It does not establish whether the original commitment was true.
git clone https://github.com/Amosk21/ARCO.git
cd ARCO
python -m venv .venv
source .venv/bin/activate # Windows PowerShell: .venv\Scripts\Activate.ps1
python -m pip install -r requirements.txt
python 03_TECHNICAL_CORE/scripts/run_pipeline.pyRequirements: Python 3.10 or newer. Outputs land at runs/demo/: the certificate, a JSON summary, evidence bindings, the SHACL report. The same pipeline runs in CI on every push and pull request and uploads runs/demo/ as a downloadable artifact. Every merge to main also redeploys the latest output to GitHub Pages, so the current certificate is one click away without cloning.
ARCO encodes two Annex III categories as one architectural pattern instantiated twice. Under this encoding, a system enters a category-specific applicable-system class only when all three conditions hold simultaneously:
| Annex III category | Capability (reality) | Intended use (representation) | Affected role (representation) |
|---|---|---|---|
| 1(a) Remote biometric identification | biometric identification | remote biometric identification | natural-person role |
| 5(b) Creditworthiness evaluation | creditworthiness evaluation | creditworthiness evaluation | natural-person role |
The three conditions together are a single OWL equivalentClass axiom, not a procedural check sequenced in code. The same pattern instantiates per category by referencing different capability and process classes. Cross-category isolation falls out of this structure: a biometric-only system cannot fire the creditworthiness axiom because its capability and intended-use are wrong for that axiom, no separate enforcement rule needed.
A separate flag (HighRiskSystem) fires from the capability gate alone. That flag is useful for surfacing latent risk where a system has the structural prerequisite without (yet) the documented intent, but it is not the legal high-risk classification.
ARCO's two encoded categories share a three-part shape: capability, intended use, and affected role. That demonstrates reuse inside this narrow scope, not that the architecture transfers unchanged to other domains. Whether other rulebooks key on the same three is worth testing case by case rather than assuming.
The existing setup may provide a starting point for a hiring or emergency-triage category. A new category may require different evidence, relations, context, or exception handling, so extension is modeling work rather than a simple content swap.
The same modeling machinery could also be aimed at uses I wouldn't sign off on, like profiling people at scale. There's no mechanism in the code that can stop that. Keeping ARCO pointed where it's pointed is a line I hold, not a lock I built. The full disclosure is in LIMITATIONS.md §12.
Items marked with (*) are work-in-progress: a modeling discipline articulated in the technical core but not yet exercised in fixtures, or a pending modeling decision with a clear path forward. Tracked in ARCO's internal working register.
Within its current scope, ARCO models an assessed system as a physical aggregate with hardware components. A reviewer may commit that a configured component bears a capability disposition. ARCO does not infer that capability from raw hardware structure; it reasons from the reviewed commitment. Under that commitment, the disposition exists whether the system is running or sitting idle.
Software running on the hardware is treated as information content (a Generically Dependent Continuant per BFO 2020, bfo:0000031). The software generically depends on the hardware that runs it (bfo:0000084 g-depends); the software is concretized by an inscription quality borne by the hardware (bfo:0000058 is concretized by); and the hardware is what bears the capability disposition. The software-hardware concretization layer is documented as discipline in an rdfs:comment at ARCO_core.ttl:208, not asserted as axioms, and is not yet exercised in any fixture; the hardware-software amalgam is disclosed as a deliberate simplification at LIMITATIONS.md §3.5.
Separately, there are documents about the system. The vendor writes an Intended Use Specification saying what the system is for. The vendor writes a Use Scenario Specification saying which role categories the system operates on. These are claims the provider makes about the system; they are typed as Information Content Entities (iao:0000030). They describe the system; they are not the system.
ARCO's encoding concludes a system is Annex III applicable when three commitments come together:
- The system's hardware bears a regulated capability. (*) This first gate is ARCO's design-time evidential addition, not an Annex III condition: the Act's trigger is the documented intended purpose carried here by gates 2 and 3. If that intent is documented but no capability commitment has been reviewed, ARCO does not entail category applicability. That non-entailment is not a negative legal conclusion; a report-only audit check surfaces the evidence mismatch for human review. Whether Gate 1 should remain necessary for ARCO's primary classification is an open modeling decision, disclosed in LIMITATIONS.
- The vendor's intended use specification commits the system to a regulated process via the IUS subkind defined-class (
cco:prescribes someValuesFrom :Process). - The use scenario specification designates the affected role category. For Annex III 1(a), this is natural persons. (*) The relationship between this designated role and the system's process is pending tightening; the current axiom does not pin down whether natural persons are subjects of identification, operators of the system, or another role-in-context.
When all three appear in a reviewed graph, the defined-class axiom entails category applicability. The execution, cross-check, and independent re-derivation mechanics are described below.
Some pieces of the picture are kept partial on purpose:
- ARCO does not mint specific natural-person particulars; no source warrant for them at design time.
- It does not model when or where the system runs (deliberate scope cut for a design-time classifier).
- It surfaces Article 6(3) derogation claims for human legal review without evaluating their validity.
- It surfaces Annex III 5(b) fraud-detection exclusion claims the same way: as audit-layer flags, not classification gates.
Some modeling decisions remain open (*):
- Capability + Interest framing. The canonical capability framing is "a disposition whose realization is associated with the interest of an organism or group." ARCO currently models the disposition side; the interest hookup for capability accountability is pending decision.
- Regulatory text aboutness. How to express what the Annex III text is about beyond the universal class (canonical options surfaced; decision pending).
One vocabulary cleanup has landed. The compositional class name
:CapabilityDispositionwas renamed to:Capability. The reason is concrete: a name composed of two terms should not exist in an ontology that lacks one of them, and ARCO had no:Capabilityclass. The rename supplies the missing anchor and lets the BFO parent carry the Disposition typing.
The architectural detail (BFO 2020 grounding, the seven modeling buckets, how the reasoner does its work) is in the section below.
Two choices make ARCO's classification result re-derivable and challengeable.
First, ARCO writes its scoped regulatory encoding as formal definitions, and a reasoner works out whether reviewed commitments satisfy them. No line of Python makes the class-membership call, so anyone with a standard reasoner can re-derive the result from the public definitions. That shows the result follows the encoding; it does not show the commitments are true or the encoding is legally complete.
Second, the definitions are grounded in BFO 2020 (ISO/IEC 21838-2:2021) and the Common Core Ontologies, which supply shared categories for material entities, dispositions, processes, and information artifacts. ARCO models a capability as a hardware-borne disposition, present whether realized or not. Writing those distinctions down precisely enough for a reasoner to use is one payoff. Building on a shared public foundation may also help another reviewer interpret the model without inheriting every local label. ARCO's seven-bucket discipline uses BFO categories to check what the model populates and where it makes a scope cut. BFO fixes the upper categories; ARCO's local classes, evidence mappings, and regulatory boundaries remain contestable. The BFO 2020 axioms live at imports/bfo-2020.owl; the seven-bucket discipline is laid out in the diagrams at docs/modeling_decisions/.
Reality and representation are kept separate. ARCO represents capabilities as dispositions borne by hardware components in the reality-side section of ARCO_core.ttl. Intended uses, use scenarios, and compliance determinations are documentary: IAO information content entities about the system. BFO 2020 disjointness between Independent Continuant and Generically Dependent Continuant constrains that separation; the binding mechanism that catches some category errors at materialization time is implemented in 03_TECHNICAL_CORE/scripts/probe_disjointness_and_binding.py.
ARCO's intended source path runs through human adjudication, not automated extraction. Candidate claims from vendor documentation, intended-use specs, and technical evidence are meant to pass through a reviewed evidence ledger before becoming RDF commitments. Promotion of a claim to a reality-side commitment is rare, conditional, and human-adjudicated. No automated extraction writes to instance TTL. The public kiosk demo v1 (docs/kiosk_demo_v1/) is a structural sketch using a hypothetical packet; replacing it with publishable real-document evidence and wiring the source-to-commitment chain programmatically remains OPEN_PROBLEMS.md L1.1.
The next worked example carries one real vendor document through that path. It will separate what the source warrants from what the reviewer adds, state what follows under ARCO's encoding, and name the unanswered fact that blocks a stronger conclusion.
Dispositions exist as particulars, not just class declarations. Every fixture instantiates its capability disposition and asserts the bearer relation via ro:0000091 has_disposition. Sentinel additionally asserts the realization chain via bfo:0000055 realizes (ARCO_instances_sentinel.ttl:37, 86). Other fixtures leave realization unmodeled at design time, disclosed at LIMITATIONS.md §3.7.a. The graph carries explicit disposition individuals, not just class hierarchies.
Classification is entailment, not procedure. The Annex III applicability classes are defined by their conditions (three-gate equivalentClass axioms at ARCO_governance_extension.ttl). When a system satisfies them, the reasoner adds the membership triple. No Python decides the classification; the axioms do, mechanically. Exposing the full entailment chain in published artifacts is active surfacing work (OPEN_PROBLEMS.md L4.8); the classification is already re-derivable from the public axioms by anyone with an OWL reasoner.
Two reasoners cross-check every classification. OWL-RL (rule-based, materializes tens of thousands of entailed triples per run) and HermiT (tableau-based, full OWL 2 DL profile) agree on every classification across the certificate-grade fixtures. Agreement across different algorithms is a stronger check on entailment behavior than either reasoner alone; it says nothing about whether the input commitments are true. The CI workflow at .github/workflows/robot-validate.yml runs the cross-check on every PR.
The three layers do different jobs and are not interchangeable. OWL-RL classifies (entails membership in the Annex III applicability classes). SHACL validates that the documentary record supporting a determination is structurally complete. SPARQL audits the post-reasoning graph and surfaces conditions for human review. A SHACL pass does not mean the system is high-risk. A SPARQL false does not overturn an OWL classification. The certificate's auditability turns on keeping the layers distinct.
Actual OWL inference fires, not string matching. Two adversarial fixtures, one per modeled Annex III category, type their capability dispositions only as a decoy class (:WeirdScanner for 1(a), :WeirdCalculator for 5(b)); the regulated class is not asserted as the disposition's type, and the connection runs through an owl:equivalentClass declaration in each. A third fixture's disposition has no IRI at all (anonymous blank node, ARCO_instances_adversarial_blanknode.ttl:28). All three classify correctly because the reasoner performs actual OWL inference: the decoys via owl:equivalentClass propagation, the blank-node fixture via owl:someValuesFrom satisfaction. An approach that did string matching on class names, or required named individuals at every position, would miss them.
Layer separation is verified by fixtures. Two flag-test fixtures present cases where all three Annex III gates are satisfied AND an audit-layer flag (a provider-asserted :DerogationClaim, or a :FraudDetectionProcess token) is also present. The OWL classification fires regardless of the audit flag; the flag fires alongside the classification. Classification and audit do not bleed into each other.
Gate independence is empirically verified. A regression test removes the supporting triples for each Annex III 1(a) and 5(b) gate in turn and confirms the classification fails. Each gate is independently necessary in both categories; removing any one breaks the entailment. Content-mutation variants (wrong process type, wrong designation target) verify that the gates check content, not just existence.
The certificate's classification binds to graph queries. Classification field and evidence path are bound to SPARQL queries against the reasoned graph; the contract lives in 03_TECHNICAL_CORE/scripts/output_manifest_v2.yaml, enforced by test_output_provenance.py. The former Article 6(3) mixed-provenance failure is closed; broader provenance-label and schema hardening remains active work (tracked in the local working register; LIMITATIONS.md §7.5).
The graph is designed to stay explicit about what it doesn't know. Project policy forbids adding participant facts, temporal regions, role-bearer particulars, or other instance-level content without source warrant. Current public fixtures are synthetic commitments, not evidence about deployed systems. Under the Open World Assumption, absent triples mean "not asserted under the current commitments," not "denied." Keeping the graph sparse where evidence is sparse is a project discipline enforced in code review.
The claim that anyone with a standard OWL 2 DL reasoner can re-derive ARCO's classification is meant to be exercised, not taken on faith. Everything you need ships in this repository, and there is a written path for a reader who has never seen the project before: docs/RE_DERIVATION_RECIPE.md.
The short version. The reasoning input is eight files under 03_TECHNICAL_CORE/ontology/: the core and governance ontologies, a fixture (input facts), the pinned BFO 2020 file, three slim modules for RO, IAO, and CCO, and catalog-v001.xml. The ontology IRIs use a domain that is currently unregistered, so nothing resolves online today; the catalog is the authoritative resolution regardless of what that domain serves in the future, mapping every import to its pinned local file. Tools that read OASIS XML catalogs (Protege, ROBOT, and other OWL API loaders) pick it up automatically when it sits next to the file being opened. Without the catalog, ROBOT refuses the load at the first unresolvable import; other OWL tools may report missing imports and continue with a partial ontology, so confirm the import closure resolved before trusting a load. That is by design: the alternative, live web IRIs, could silently fetch a different upstream version than the one the classification was verified against.
Two ways in:
- Protege. Open
ARCO_instances_sentinel.ttl, start the bundled HermiT reasoner, and look at the inferred types onSentinel_ID_System: the reasoner derivesAnnexIII1aApplicableSystemandHighRiskSystemfrom the axioms and the input facts. OpenARCO_instances_verification.ttl(a walk-up verification kiosk) the same way and neither type is derived forVerificationKiosk_001. The recipe has the click-by-click steps. - Command line. The recipe inlines the exact ROBOT command sequence that was executed cold from a fresh directory containing only the published files, with imports resolved purely through the catalog and no ARCO code in the loop. A dated record of that run (tool versions, timings, verdicts, merged-closure hashes) is pinned as the Reference run snapshot at the end of the recipe.
What has been shown, with its bounds. Three reasoner engines agree on both fixtures: OWL-RL (the pipeline's rule engine), HermiT (tableau, run through three separate invocation paths: CI, a clean-room Python bridge, and a catalog-resolved ROBOT load), and Pellet 2.3.1 (tableau, clean room). Agreement means: the positive fixture is entailed Annex III 1(a) applicable and high-risk, the negative fixture is entailed neither, and both graphs are consistent with zero unsatisfiable classes. The bounds: Pellet's build cannot process the full file union (it runs out of memory preparing the RO module's 110 property-chain axioms, a limitation of that reasoner build, not an ARCO axiom), so its agreement is demonstrated on assemblies that exclude the RO slim; HermiT covers the full union and returns identical verdicts either way on the checked fixtures. The checks are class-membership on three named classes plus consistency, not a full diff of every inferred axiom. And the negative result is an open-world statement: not entailed under the current commitments, which is not a claim that the kiosk could never be high risk under different commitments.
If you follow the recipe and get a different answer than the one it states, that is a finding. Please open an issue with your log.
The three-gate pattern (capability + intended use + affected role) has been instantiated for two EU AI Act categories. Whether it generalizes to another category or regime must be tested against that category's evidence and legal structure; extension may require architectural change. The table below tracks load-bearing modeling decisions and scoped active work.
| What | Stage |
|---|---|
Renaming the main capability class from :CapabilityDisposition to :Capability so the name represents one concept rather than two glued together |
Landed |
| Deciding whether Gate 1 should remain necessary for ARCO's primary classification or instead be reported as a separate evidence-strength layer; under the current encoding, documented regulated intent without a reviewed capability commitment does not entail category applicability | Decision pending |
| Moving the Gate 3 design rationale out of inline code comments into proper modeling docs so a reviewer can find the reasoning without reading the TTL | Ready to land |
| Adding the "who has an interest in this capability" relationship to the capability model. Right now ARCO captures what a capability can do but not who its outcomes serve; three approaches being weighed | Decision pending |
| Specifying what each Annex III rule actually points at inside ARCO. Currently it points at a class; tightening to point at specific systems or sets of things together is under consideration | Decision pending |
| Tightening Gate 3 to specify HOW the system relates to the natural persons it affects. Today it just says natural persons are involved; it doesn't distinguish between persons being identified by the system, persons operating it, or persons simply nearby | Decision pending |
| Tightening Gate 2's match to the regulation's actual wording. Today Gate 2 checks that the system is documented to perform a specific process kind; the regulation actually keys on the intended purpose, which is a slightly looser match | Decision pending |
| Replacing the kiosk demo's hypothetical vendor packet with a real vendor document, so the demo runs on actual source evidence rather than hypothetical content | Active work |
| Publishing the second reasoner's per-fixture result alongside the already-published reasoned graph, so anyone can independently check both the conclusions and that two different reasoners agree | Active work |
| Labeling every certificate field with where its value came from (a graph query result, the run's metadata, or a scope-disclosure note) and adding a CI check that verifies every field traces back to its declared source | Active work |
| Extending the test that confirms each Gate is necessary from Annex III 1(a) to also cover 5(b), so both classifications have the same proof that none of the three gates is decorative | Landed 2026-05-14 |
Day-to-day rows live in OPEN_PROBLEMS.md (internal); the public roadmap with verified core, resolved modeling decisions, and execution sequence is at docs/MODELING_ROADMAP.md.
- No citation chain from intended use to specific clauses in vendor documents (Article 3(12)). Queued.
- No Article 6(3) derogation evaluation. The claim is surfaced for human legal review, not judged.
- No Article 5 prohibition routing. The 5(1)(h) real-time-in-publicly-accessible-spaces subset is not split out from the parent 1(a) class.
- No automatic obligation chain. Article 16 (provider) and 26 (deployer) duties are not entailed from positive classification.
- Only 2 of 8 Annex III categories modeled.
- No raw document ingestion. ARCO consumes structured RDF; turning vendor PDFs into structured RDF is a separate upstream problem.
For the complete disclosure surface, see LIMITATIONS.md.
| Ontology | Version | Loaded as |
|---|---|---|
| BFO | BFO 2020 (ISO/IEC 21838-2:2021) | Full ontology, imports/bfo-2020.owl |
| RO | OBO Relations Ontology release 2025-12-17 |
ROBOT BOT slim module |
| IAO | Information Artifact Ontology release 2026-03-30 |
ROBOT BOT slim module |
| CCO | Common Core Ontologies v1.7 (pinned semantic-IRI release) | ROBOT BOT slim module + local bridge declarations |
The BOT-extracted slim modules carry a formal entailment-preservation guarantee (syntactic locality module extraction, Cuenca Grau et al. 2007/2008): for any axiom whose signature is contained in the seed signature, the slim module entails the axiom if and only if the full upstream ontology does. The slim modules are not lossy abbreviations; they are logically equivalent to the full upstreams for the seed signature ARCO uses, with substantially faster reasoning. The seed term lists are version-controlled at 03_TECHNICAL_CORE/ontology/imports/seeds/ and the slim modules can be regenerated reproducibly from the pinned upstream releases.
LIMITATIONS.md. Scope cuts, disclosed non-claims, and dual-use disclosure.docs/modeling_decisions/. Canonical diagrams and decisions justification map; every load-bearing modeling decision anchored to a specific TTL file or canon citation.docs/kiosk_demo_v1/. Narrative walkthrough of one fixture from source documentation to certificate. Programmatic wiring to the TTL fixture is pending (OPEN_PROBLEMS.md L1.1); source packet is hypothetical.