Colorado SB 24-205

Regulation at a glance

The clause numbers below reference SB 24-205 as enacted. Confirm the current enrolled text and apply this mapping to the deployment's own self-assessment before filing.

§6-1-1703(1): Disclosure of Capabilities and Limitations

Subsection (1) requires a developer to disclose the material capabilities and limitations of a high-risk AI system. Chio answers this at the tool surface through the signed ToolManifest. Each tool server publishes a manifest containing one signed ToolDefinition per tool it exposes.

• description: human-readable statement of what the tool does.
• input_schema and output_schema: JSON Schema for the tool's arguments and result, so the declared interface is described in JSON Schema for programmatic validation.
• has_side_effects: a boolean that names whether the tool writes files, sends network requests, or modifies state. This is the manifest's structured limitation flag.
• latency_hint and optional pricing: operational characteristics the deployer can surface to consumers.

The manifest is signed by the tool server's keypair, so a deployer can verify that the disclosed surface has not drifted from what the server actually exposes. The sign-and-verify round trip is exercised by sign_and_verify_manifest in crates/platform/chio-manifest/src/lib.rs.

§6-1-1703(2): Record-Keeping and Retention

Subsection (2) requires records of high-risk AI system outputs to be generated, retained for a configurable period, and to remain verifiable after that period expires. Chio generates a signed ChioReceipt for every invocation, then rotates and archives receipts under RetentionConfig without ever discarding the proof that ties an archived receipt back to a signed checkpoint.

Time-based rotation is checked by retention_rotates_at_time_boundary and the size trigger by retention_rotates_at_size_boundary, both in crates/kernel/chio-kernel/tests/retention.rs. The verifiability requirement in §6-1-1703(2)(b) is the reason archival preserves checkpoint rows: an archived receipt still verifies against the Merkle checkpoint root copied into the archive database. Archival only copies checkpoint rows whose batch end sequence is fully covered by archived receipts, so no partial batch leaves an orphaned proof behind.

use chio_kernel::RetentionConfig;

// A deployment that must retain evidence for two years.
let retention = RetentionConfig {
    retention_days: 730,
    max_size_bytes: 50 * 1024 * 1024 * 1024, // 50 GB
    archive_path: "receipts-archive.sqlite3".to_string(),
    tenant_id: None,
    check_interval_secs: 3600,
    ..RetentionConfig::default()
};

§6-1-1703(3): Decision Audit Trail

Subsection (3) requires that AI system decisions be attributable and reviewable. Every receipt pairs a decision with the capability_id and policy_hash that produced it, and the whole body is signed by the kernel keypair. The kernel fails closed: every guard denial, every revocation hit, and every evaluation error produces a signed deny receipt with the same field set as an allow. There is no code path that reaches a verdict without emitting a receipt.

The Decision enum is tagged, so a denial is self-describing: it carries the human-readable reason and the guard that triggered it. An investigator reading a deny receipt learns both what was blocked and which rule blocked it.

{
  "id": "rcpt-01HQ0A...",
  "timestamp": 1768042512,
  "capability_id": "cap-billing-q2",
  "tool_server": "billing-api",
  "tool_name": "charge.create",
  "content_hash": "sha256:5b7f...",
  "decision": {
    "verdict": "deny",
    "reason": "grant budget exhausted",
    "guard": "budget"
  },
  "policy_hash": "sha256:a39c...",
  "kernel_key": "ed25519:80f2b577...",
  "metadata": {
    "financial": {
      "cost_charged": 0,
      "currency": "USD",
      "attempted_cost": 2000,
      "settlement_status": "not_applicable"
    }
  }
}

Coverage of the allow-and-deny invariant is asserted by all_calls_produce_verified_receipts in crates/kernel/chio-kernel/src/kernel/tests/receipts.rs, and the denial-carries-financial-detail path by monetary_denial_receipt_contains_financial_metadata.

§6-1-1703(4): Tamper-Evident Storage

Subsection (4) requires that records not be silently altered and that an individual record be provably part of the log. Chio commits every batch of receipts into a signed KernelCheckpoint carrying the Merkle root over the batch.

• The checkpoint signature is an Ed25519 signature over the canonical JSON of the checkpoint body, so an auditor verifies it with public information alone. This round trip is checked by build_checkpoint_signature_verifies in crates/kernel/chio-kernel/src/checkpoint.rs.
• Any single receipt can be proven to belong to the log via a Merkle inclusion proof from build_inclusion_proof, without re-reading the full batch. The proof-verifies property is asserted by inclusion_proof_verifies_for_leaf_n.
• Altering a stored receipt after the fact breaks the batch's Merkle root, which breaks the checkpoint signature. Tampering is detectable without a trusted third party.

§6-1-1703(5): Proof of Possession

Subsection (5) requires that agent actions be bound to the acting entity. Chio's DPoP (Demonstration of Proof-of-Possession) module binds an Ed25519 proof over capability_id + tool_server + tool_name + action_hash + nonce to the agent's registered keypair. The binding is enforced by verify_dpop_proof_stateless in crates/kernel/chio-kernel/src/dpop.rs.

DPoP is requested per grant. When dpop_required is set on a ToolGrant, the kernel refuses any call that lacks a valid proof, so the acting entity is provable on every sensitive invocation. All three DPoP tests live in crates/kernel/chio-kernel/tests/dpop.rs.

§6-1-1703(6): Budget Accountability

Subsection (6) concerns AI systems that carry monetary authority. Every receipt for a monetary grant carries FinancialReceiptMetadata. Allow receipts record the actual cost_charged reported by the tool server rather than the worst-case cap, alongside currency, budget_remaining, budget_total, and settlement_status. Deny receipts record the attempted_cost so that non-execution is itself evidenced.

The caps max_total_cost and max_cost_per_invocation are enforced atomically: the budget store opens a SQLite TransactionBehavior::Immediate transaction so a concurrent invocation cannot overspend a grant through a read-modify-write race. Allow-side and deny-side metadata are checked by monetary_allow_receipt_contains_financial_metadata and the exhaustion transition by monetary_full_pipeline_three_invocations_third_denied in crates/kernel/chio-kernel/src/kernel/tests/budget.rs.

For the operational view of budgets and metering, see Budgets & Metering.

§6-1-1703(7): Checkpointing Interval

Subsection (7) concerns the cadence of tamper-evident commits. checkpoint_batch_size (default 100) controls how frequently a Merkle checkpoint is produced: the kernel triggers a checkpoint automatically after every N receipts. Lowering the value tightens the window in which an unresolved batch sits uncheckpointed. The default cadence is verified by checkpoint_triggers_at_100_receipts in crates/kernel/chio-kernel/src/kernel/tests/receipts.rs.

Clause Mapping

Enforcement Pipeline

Verification

Every mechanism cited above is backed by a passing test. Run the workspace suite to confirm the mapping, or run the targeted filters to reproduce a single clause.

# Confirm the whole mapping.
$ cargo test --workspace

# Retention and verifiable archival - 1703(2).
$ cargo test -p chio-kernel -- retention

# Proof of possession - 1703(5).
$ cargo test -p chio-kernel -- dpop

# Tamper-evident checkpoints - 1703(4), 1703(7).
$ cargo test -p chio-kernel -- checkpoint

# Budget accountability - 1703(6).
$ cargo test -p chio-kernel -- monetary

# Capability and manifest transparency - 1703(1).
$ cargo test -p chio-manifest -- sign_and_verify_manifest

Non-Goals

• Chio does not decide whether a deployment is a high-risk AI system under the Act, nor which of a developer's or deployer's obligations attach. It supplies the technical controls the statute's record-keeping and accountability clauses describe.
• Chio does not evaluate model-layer properties such as bias, accuracy, or the algorithmic-discrimination concerns the Act addresses. Those live above the tool-invocation boundary.
• Chio does not author the consumer notices, impact assessments, or disclosures the deployer files. It produces the signed evidence those documents reference.

Cross-References

• Receipts for the signed record format cited across §6-1-1703(2) and (3).
• Verify Receipts Offline for the checkpoint and inclusion-proof workflow behind §6-1-1703(4).
• EU AI Act for the parallel Article 19 logging and Article 14 oversight mapping.
• NIST AI RMF for the Govern, Map, Measure, and Manage mapping of the same primitives.