EU AI Act

Article 19: Automatically Generated Logs

Article 19(1) requires high-risk AI systems to automatically generate logs of their operation for a period appropriate to the intended purpose, with sufficient detail to enable traceability of the system's actions during its lifetime. Chio can provide technical logging evidence at the tool-invocation layer.

The kernel records each governed call with a signed receipt:

• Automatic: the kernel emits a receipt for allow and deny decisions in the governed-call path.
• Tamper evidence: the receipt batches are Merkle-committed into signed kernel checkpoints. A changed receipt no longer matches its recorded Merkle root.
• Attributable: every receipt carries capability_id, tool_server, tool_name, policy_hash, parameter_hash, decision, and a kernel key reference.
• Cost-tracked: monetary invocations embed FinancialReceiptMetadata recording cost_charged, attempted_cost, and settlement_status.

{
  "receipt_id": "rcpt-01HQ...",
  "sequence": 31417,
  "capability_id": "cap-01HQ...",
  "tool_server": "billing-api",
  "tool_name": "charge.create",
  "parameter_hash": "sha256:5b7f...",
  "decision": "allow",
  "policy_hash": "sha256:a39c...",
  "kernel_key": "ed25519:80f2b577...",
  "guard_evidence": [
    { "guard": "velocity", "verdict": "ok" },
    { "guard": "secret_leak", "verdict": "ok" }
  ],
  "financial": {
    "cost_charged_usd_cents": 1250,
    "attempted_cost_usd_cents": 1250,
    "settlement_status": "succeeded"
  },
  "emitted_at_unix": 1768042512,
  "signature": "ed25519:4e2f..."
}

Denials Carry Equal Weight

Article 19 expects logs to record denied operations with sufficient detail for audit. Chio's kernel fails closed: every error path, every guard denial, and every revocation hit produces a signed deny receipt with the same field set as allow. There is no code path that emits a decision and no receipt.

# Filter the receipt store for deny events.
# --outcome takes allow, deny, cancelled, or incomplete;
# --since is Unix seconds (1775001600 is 2026-04-01T00:00:00Z).
$ chio receipt list \
    --receipt-db ./receipts.sqlite3 \
    --outcome deny \
    --since 1775001600

# Explain why a specific receipt was allowed or denied,
# rendering its capability chain and guard evidence.
$ chio receipt explain rcpt-01HQ0A... \
    --receipt-db ./receipts.sqlite3

Annex IV: Retention and Archival

Annex IV Section 2(g) expects records to be retained for a period appropriate to the intended purpose and to remain accessible for post-hoc review. Chio's retention config ships with configurable time-based and size-based rotation plus checkpoint-preserving archival.

Annex IV Section 7: Tamper-Evident Monitoring

Annex IV Section 7 expects technical documentation to describe measures that ensure log integrity. Chio's Merkle checkpoint pipeline is the implementation answer.

• Every checkpoint-sized batch of receipts produces a signed KernelCheckpoint carrying the Merkle root over the batch.
• Individual receipts can be verified to belong to the log via Merkle inclusion proofs, without re-reading the full batch. An evidence export writes those proofs to inclusion-proofs.ndjson.
• Archived receipts remain verifiable against checkpoint rows copied into the archive database.
• The checkpoint signature is canonical JSON (RFC 8785) signed by the kernel's Ed25519 keypair, so an auditor can verify the signature with public information alone.

# Report the current receipt-checkpoint chain status.
$ chio receipt checkpoint status \
    --receipt-db ./receipts.sqlite3

# Verify the integrity of the whole receipt-checkpoint chain.
$ chio receipt checkpoint verify \
    --receipt-db ./receipts.sqlite3

Article 14: Human Oversight

Article 14 requires that high-risk AI systems enable human oversight. Actions must be attributable to the invoking entity, replay of oversight evidence must be prevented, and stale oversight material must be rejected.

Article 9: Risk Management

Article 9 requires risk management that addresses monetary and operational consumption of AI systems. Chio's budget and velocity primitives are the tool-layer implementation.

• max_total_cost and max_cost_per_invocation are enforced atomically inside the kernel. Exhaustion produces a signed deny receipt.
• Velocity guards cap invocation rate and spend rate across time buckets, preventing runaway consumption.
• Allow receipts for monetary actions record the actual charged cost reported by the tool server, so downstream reconciliation can compare intended and actual cost.
• Deny receipts for monetary denials record the attempted cost and the reason, so non-execution is evidenced.

{
  "server_id": "billing-api",
  "tool_name": "charge.create",
  "operations": ["invoke"],
  "constraints": [
    { "type": "minimum_autonomy_tier", "value": "delegated" },
    { "type": "require_approval_above", "value": { "threshold_units": 200000 } }
  ],
  "max_invocations": 2000,
  "max_cost_per_invocation": { "units": 2000, "currency": "USD" },
  "max_total_cost": { "units": 500000, "currency": "USD" },
  "dpop_required": true
}

A ToolGrant carries the budget caps directly (max_cost_per_invocation and max_total_cost, each a minor-unit amount plus currency). Rate limiting is a separate concern: the velocity guard caps invocation and spend rate from the guard configuration, not from the grant. Autonomy is expressed as a minimum_autonomy_tier constraint, whose value is a GovernedAutonomyTier (direct, delegated, or autonomous); grant lifetime is bounded by the enclosing capability token's expires_at.

Article 50: Transparency

Article 50 imposes transparency obligations on certain AI systems, including the obligation to disclose the acting entity. The disclosure itself is an application-layer responsibility, but Chio's identity surfaces supply the attribution primitives it draws on: every call names the actor, and that attribution is signed.

• The capability subject is a did:chio identifier. Every receipt carries that subject, so downstream consumers can name the acting entity in human-readable terms.
• WorkloadIdentity metadata on the capability can include operator-chosen display attributes. This is how a tool server can say "this call came from the quarterly billing agent operated by Acme Inc.".
• Agent passports bundle the subject's reputation and attribution into a signed artifact the downstream counterparty can show to its own users, so the transparency chain does not rely on out-of-band identity claims.

Article 72: Post-Market Monitoring

Article 72 introduces post-market monitoring obligations. Providers must observe their deployed system, collect data on its performance, and report serious incidents. Chio does not run the monitoring program, but its receipt query API and reputation surfaces are the observability layer such a program consumes at the tool boundary.

Annex III High-Risk Systems

Annex III lists categories of systems that are treated as high-risk: biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, and administration of justice. Agents that call tools in these domains benefit from Chio's fail-closed posture:

• Fail-closed default: every unknown tool, every expired capability, every revoked capability, every evaluation error produces a deny receipt rather than a silent allow.
• Signed evidence as default: there is no code path that invokes a tool without emitting a signed receipt. Audit material is produced as a side effect of normal operation.
• Explicit autonomy tiers: GovernedAutonomyTier names the level of human involvement expected for each capability. Sensitive categories stay at tiers that require step-up approval.
• Revocation latency bounded: revocations propagate across the cluster on the next repair sync; edges re-check on every call.

Pipeline Diagram

Verification Commands

# Run the full receipt-log audit: claim-log projection validation
# plus a complete checkpoint-chain verification.
$ chio receipt audit --receipt-db ./receipts.sqlite3

# Verify the integrity of the whole receipt-checkpoint chain.
$ chio receipt checkpoint verify --receipt-db ./receipts.sqlite3

# Build the Article 19 evidence package for the quarter.
# --since / --until are Unix seconds (Q1 2026 here).
$ chio evidence export \
    --policy-file ./policy.yaml \
    --receipt-db ./receipts.sqlite3 \
    --since 1767225600 \
    --until 1775001599 \
    --require-proofs \
    --output ./q1-article-19-package

Non-Goals

• Chio does not perform conformity assessment. It supplies the logs an assessor inspects.
• Chio does not register AI systems in the EU database (Annex VIII). Registration remains the provider's responsibility.
• Chio does not evaluate model-layer properties such as bias, robustness under distribution shift, or hallucination rate.
• Chio's evidence posture does not replace the technical file (Annex IV). It supplies inputs that populate sections about logging, oversight, and monitoring.

For the process-oriented management-system framing of these controls, continue with ISO/IEC 42001. For the operational log surface itself, see Receipts and Receipt Query API.