$ orc verify --file ./eu-ai-act-mapping.md --workspace public --strict run_id 01KR2X9HK4N1

EU AI Act compliance posture, verified by the runtime itself.

This page maps orc to the EU AI Act articles most relevant to operators of high-risk AI systems (Annex III). It is itself an audit artifact: every claim below points at specific source files, behaviors, or roadmap items that can be inspected. Articles 12, 13, and 14 are satisfied in v0.1.1, including the two-natural-persons verification required by Article 14 §5. Articles 9, 10, 11, 26, and 72 are partly covered by today's runtime with explicit roadmap items for the rest. Orc is a tool used by deployers of high-risk systems, not itself a high-risk system — the compliance obligations remain with the deployer.

deadline: 2026-08-02 · Annex III obligations enter into force
regulation: Regulation (EU) 2024/1689 · Articles 9, 10, 11, 12, 13, 14, 15, 26, 72
penalty: up to €15M or 3% worldwide annual turnover · whichever is higher
scope: tool for deployers / providers of high-risk systems · not itself a high-risk system

article-by-article summary — click a tick to jump

article_12 · record-keeping · the core fit

claim_art12 verifying

Orc satisfies Article 12's logging requirements by construction, not by configuration.

Article 12 requires automatic recording of events over the lifetime of the system, with logs that identify risk situations, support post-market monitoring, and monitor operation. Article 26(6) requires retention of at least six months. Orc's trace + replay subsystem is the machinery to meet these requirements. It cannot be disabled, runs by default on every invocation, and produces append-only artifacts.

art12_§1
auto log

Automatic recording of events over the lifetime.

Every CLI or MCP invocation opens a Run, which writes a row to the run table and a JSON file under traces/<YYYY>/<MM>/<run_id>.json. There is no flag to turn this off.

code · src/orc/runs/runner.py · evidence: every test fixture in tests/unit/test_run_context.py asserts trace creation

verifying

art12_§2a
risk id

Logs identify risk situations.

Verdict labels contradicted, not_found, and partial explicitly mark unreliable outputs. Runtime errors are recorded with status="error" and error_message. A run with status=error is, by definition, a risk-flag event.

code · src/orc/storage/schema.sql:run · src/orc/runs/runner.py:close

verifying

art12_§2b
post-market

Facilitate post-market monitoring (Art. 72).

orc trace list enables longitudinal queries across runs. orc replay <run_id> re-executes against the recorded corpus_version so drift between corpus snapshots is detectable.

code · src/orc/cli_commands/trace.py · src/orc/runs/replay.py

verifying

art12_§2c
operation

Monitor operation per Art. 26(5).

Per-run metrics: total_input_tokens, total_output_tokens, total_cache_read, total_cache_creation, model identifier, elapsed time, retrieval set size — all recorded automatically.

code · src/orc/runs/runner.py:close, finalize_run_row

verifying

article_13 · transparency to deployers

claim_art13 verifying

Every Orc output is interpretable, cited, and inspectable.

Article 13 requires sufficient transparency that deployers can interpret and appropriately use the output. Orc's verdict shape is structured JSON with confidence + chunk citations + reasoning, which is materially more interpretable than the conversational outputs typical of LLM tooling.

art13_§1
interpret

Output is interpretable by the deployer.

Every verdict ships with: structured label (supported / partial / contradicted / not_found), confidence score, reasoning text, chunk-level citations, the full retrieval set.

code · src/orc/directives/research/skills/verify_claim.py:run

verifying

art13_§3bii
limits

Capabilities and limitations documented.

README.md plus this page. Known limitations: BM25 retrieval only (no embeddings in v0.1), no PDF ingestion, prompt-cache threshold ~3K tokens for sonnet (see claim_08 on the landing page).

file · README.md · docs/compliance/eu-ai-act.md · landing page claim_08 (publicly self-disclosed)

verifying

art13_§3biii
harm risks

Foreseeable circumstances likely to lead to harm.

The runtime structurally prevents hallucinated citations: chunk IDs returned by the model are validated against the retrieval set and dropped if absent. not_found is preferred over confabulation when the corpus is silent.

code · src/orc/directives/research/skills/verify_claim.py (candidate_ids filter)

verifying

art13_§3bv
input data

Input data specifications.

The workspace is the input-data spec. Every evidence item carries SHA-256 hash, ingestion timestamp, source path, and corpus version. Provenance is intact across the lifecycle.

code · src/orc/ingest/pipeline.py · src/orc/storage/schema.sql:evidence

verifying

article_14 · human oversight · one item open

claim_art14 verifying

Effective human oversight, including the two-person verification required by Article 14 §5.

Article 14 requires effective oversight by natural persons. For some Annex III systems (notably biometric ID under §1(a)) it requires two natural persons to verify identifications. Both surfaces are now satisfied: the single-approver path and the multi-approver workflow with duplicate-approver prevention and full per-decision audit trail.

art14_§4d
override

Decide not to use, or override, the output.

orc approve reject <id> --note "..." records the override decision with timestamp and free-text reason. The rejection is preserved in the queue and the trace.

code · src/orc/queue/approval.py:reject · src/orc/cli_commands/approve.py

verifying

art14_§4e
intervene

Intervene or interrupt.

The approval queue is structurally between Orc's analysis and any external action. Action-taking outputs land in the queue; nothing leaves Orc until a human accepts. Compromised or malfunctioning runs cannot bypass this — there is no path that doesn't pass through the queue.

architecture · approval queue is the only sanctioned write path

verifying

art14_§5
two-person

Two natural persons verify (shipped v0.1.1).

Approvals can be enqueued with approvers_required=N. Each decision is recorded in approval_decision with a UNIQUE constraint on (approval_id, decided_by) — the same natural person cannot vote twice. Status flips to approved only when N distinct acceptances are recorded; any single rejection blocks immediately. Full audit trail preserved per decision.

code · src/orc/queue/approval.py · schema · src/orc/storage/schema.sql (approval_decision table)

verifying

article_26 · deployer obligations

claim_art26 verifying

Deployer obligations are satisfied end-to-end, with a single command for regulator handoff.

Article 26 places the day-to-day obligations on the deployer: monitor the system in operation, keep logs for at least six months, and be able to produce them on request. Orc's trace database is the substrate; orc audit export is the handoff. A regulator gets a single hashed tar.gz containing every run, every trace, the evidence manifest, the approval queue, and the runtime version metadata — readable without access to the live system.

art26_§5
monitor

Monitor the operation of the system.

Every CLI or MCP invocation writes a Run row to SQLite and a full trace JSON to disk. orc trace list + orc trace show surface the live view. orc replay <run_id> reconstructs any individual decision deterministically against the corpus snapshot it ran against.

code · src/orc/runs/runner.py · src/orc/runs/replay.py

verifying

art26_§6
retention

Six-month minimum retention.

Trace JSON files are append-only by default; SQLite run rows are never deleted by Orc. The deployer is responsible for backing the workspace volume up beyond 6 months for their jurisdiction. The retention guarantee is structural, not configurable.

filesystem · ~/.orc/workspaces/<name>/traces/ + run table

verifying

art26_handoff
audit export

Regulator handoff in one command (shipped v0.1.2).

orc audit export -w <workspace> writes a hashed tar.gz containing run rows, every trace JSON (schema-validated on the way out), the evidence manifest with sha256, the approval queue with per-approver decisions, workspace metadata, and orc/python/platform versions. manifest.json carries sha256 for every file in the bundle so the assessor can verify integrity independently — sha256sum -c against the manifest. Range filters via --from / --to on started_at. An unsupported trace schema version aborts the export rather than ship a half-bundle.

code · src/orc/audit/export.py · src/orc/cli_commands/audit.py

verifying

adjacent · articles 9 / 10 / 11 / 15 / 72

claim_adj verifying

Adjacent articles — partial coverage today, mapped roadmap for the rest.

A short status pass on the articles around the core 12/13/14. Some are satisfied substantively by today's runtime; others depend on roadmap features (eval suite, audit export, conformity-helper directive). Each is honestly marked.

art9
risk mgmt

Risk management substrate.

Incident reconstruction via orc trace show. Corpus-version and cache-metric drift detection via replay. The not_found verdict is the runtime's first-line risk mitigation.

runtime · trace + replay

verifying

art10
data gov

Data governance basics.

Every evidence item carries SHA-256 + ingestion metadata. orc ingest is the single audited entry point. Bias/fairness analysis of the corpus remains the deployer's responsibility.

code · src/orc/ingest/pipeline.py

verifying

art11
tech docs

Technical documentation scaffolding.

README + CHANGELOG cover the general description and lifecycle. The conformity-assessment-helper directive (Phase 3) will generate Annex IV scaffolding from a system spec.

file · README.md, CHANGELOG.md · roadmap · Phase 3

verifying

art15
robustness

Accuracy, robustness, cybersecurity (partial).

Accuracy via per-run confidence + golden tests against a fixed corpus. Robustness instrumentation (orc eval consistency / perturb / regression) is on the Phase 3 roadmap. Cybersecurity: dependencies pinned, local-first, no telemetry, approval queue. SOC 2 / ISO 42001 in Phase 4.

tests/golden/ · roadmap · Phases 3-4

verifying

art72
post-market

Post-market monitoring substrate.

The trace database is the post-market monitoring substrate. Every call writes to it. Phase 3 eval commands produce drift metrics against a baseline.

runtime · trace database · roadmap · Phase 3 (eval suite)

verifying

scope · what orc is not · honest framing

claim_scope verifying

Orc is a tool that helps deployers meet obligations. It does not absolve them.

Orc itself is not a "high-risk AI system" per Annex III. It is a tool used by deployers and providers of high-risk systems. Article 12/13/14 obligations strictly fall on the deployer; Orc supplies the machinery to meet them. Buyer-side legal counsel should always confirm your specific obligations.

also out of scope, marked honestly Conformity assessment under Article 43 is a procedural obligation, not a tool output. SOC 2 Type II and ISO/IEC 42001 attestations are on the Phase 4 roadmap; Orc v0.1.0 is open-source, MIT-licensed, fully inspectable code — a different (and arguably stronger) form of trust than a certificate, but not equivalent. General-purpose AI obligations under Articles 51–56 apply to the underlying LLM provider (Anthropic, OpenAI via OpenRouter), not to Orc itself.

next · pilot path · 11 weeks to enforcement

If you're evaluating Orc for an Annex III workflow.

Three ways to engage, ranked by commitment level.

# 1. evaluate the code — 30 minutes, no contact required $ uv pip install git+https://github.com/Thormatt/orc $ orc workspace create eu-ai-act-eval $ orc verify "your test claim" -w eu-ai-act-eval # 2. read the source — github.com/Thormatt/orc # src/orc/runs/runner.py ← article 12 §1, §2 # src/orc/queue/approval.py ← article 14 §4d, §4e # src/orc/directives/research/.../verify_claim.py ← article 13 §1, §3biii # 3. pilot — thormatt@gmail.com · subject "Orc - EU AI Act compliance pilot" # we'll scope to one specific Annex III use case + propose a 30-day evaluation

Source: github.com/Thormatt/orc · Mapping doc: docs/compliance/eu-ai-act.md · MIT-licensed