Colorado AI requirements

Disclosure of capabilities and limitations

Each tool server publishes a signed ToolManifest with one ToolDefinition per tool it exposes. That declaration describes the operations an operator admits:

• description: a 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 validates programmatically.
• has_side_effects: a boolean naming whether the tool writes files, sends network requests, or modifies state. It is the manifest’s structured limitation flag.
• latency_hint and optional pricing: operational characteristics the deployer can surface to consumers.

The tool server’s keypair signs the manifest, so a deployer verifies that the disclosed tools match what the server exposes. sign_and_verify_manifest in crates/platform/chio-manifest/src/lib.rs exercises the round trip.

Record-keeping and retention

The governed-call path produces a signed ChioReceipt for each recorded decision, then rotates and archives receipts under RetentionConfig with the checkpoint records that keep them verifiable. RetentionConfig accepts any ceiling, so the operator sets it to the three-year schedule.

retention_rotates_at_time_boundary checks time-based rotation and retention_rotates_at_size_boundary the size trigger, both in crates/kernel/chio-kernel/tests/retention.rs. The maintenance worker runs rotation without operator polling.

An archived receipt still verifies against the Merkle checkpoint root copied into the archive database (archived_receipt_verifies_against_checkpoint). Archival copies only the checkpoint rows whose batch end sequence the archived receipts fully cover, so no partial batch leaves an orphaned proof. The watermark query is in crates/platform/chio-store-sqlite/src/receipt_store/evidence_retention.rs, and archive_preserves_checkpoint_rows in the retention test file pins it.

Install retention and verify an archive

Configure the host, produce a checkpointed receipt, and exercise the archive transfer with an explicit local cutoff.

Complete the project setup, then run the program from federation-guide/. The download includes every constructor and input.

cargo run --locked --bin retention

retention schedule: installed in kernel configuration
explicit local cutoff: 1 checkpointed receipt archived
live receipts: 0; archive receipts: 1
next: export and verify retention-run/archive.sqlite3

The 1,096-day value is an example live-store window, not a calendar-based legal retention calculator. This local exercise explicitly advances the archival cutoff; retain production archives under the approved full schedule, access controls, and backups.

use chio_kernel::RetentionConfig;
use chio_store_sqlite::SqliteReceiptStore;
use federation_guide::{host_with_retention, now, record, request, Error};
use std::path::Path;

#[tokio::main]
async fn main() -> Result<(), Error> {
    let directory = Path::new("retention-run");
    let archive_path = std::env::current_dir()?
        .join(directory)
        .join("archive.sqlite3");
    let config = RetentionConfig {
        retention_days: 1096,
        max_size_bytes: 50 * 1024 * 1024 * 1024,
        archive_path: archive_path.to_string_lossy().into_owned(),
        tenant_id: None,
        check_interval_secs: 3600,
        ..RetentionConfig::default()
    };
    // Install the schedule in the host, not merely in an unused local value.
    let host = host_with_retention(directory, Some(config))?;
    let response = host
        .kernel
        .evaluate_tool_call(&request(&host.capability, "retain-1"))
        .await?;
    assert_eq!(response.verdict, chio_kernel::Verdict::Allow);
    record(directory, "original", &response)?;
    drop(host);
    let live = SqliteReceiptStore::open(directory.join("receipts.sqlite3"))?;
    assert_eq!(live.tool_receipt_count()?, 1);
    // A local exercise advances the cutoff beyond this run's receipt.
    // This explicitly invokes archival; it does not simulate waiting three years.
    let archived = live.archive_receipts_before(now() + 1, archive_path.to_str().unwrap())?;
    assert_eq!(archived, 1);
    assert_eq!(live.tool_receipt_count()?, 0);
    let archive = SqliteReceiptStore::open(&archive_path)?;
    assert_eq!(archive.tool_receipt_count()?, 1);
    println!("retention schedule: installed in kernel configuration");
    println!("explicit local cutoff: 1 checkpointed receipt archived");
    println!("live receipts: 0; archive receipts: 1");
    println!("next: export and verify retention-run/archive.sqlite3");
    Ok(())
}

Open the source file. Each program asserts its expected refusals; keys, timestamps, and digests change between runs.

chio evidence export --receipt-db retention-run/archive.sqlite3 --admin-all --require-proofs --output archive-package
chio evidence verify --input archive-package

evidence package verified
tool_receipts:          1
child_receipts:         0
checkpoints:            1
checkpoint_publications: 1
checkpoint_witnesses:   0
checkpoint_consistency_proofs: 0
checkpoint_equivocations: 0
capability_lineage:     1
inclusion_proofs:       1
uncheckpointed_receipts: 0
authorized_receipts:     1
trace_observations:      0
advisory_evaluations:    0
verified_files:         12
child_receipt_scope:    FullQueryWindow
transparency_preview_logs: 1
publication_state:      transparency_preview

Decision audit trail

A receipt pairs a decision with the capability_id and policy_hash that produced it, and the kernel keypair signs the whole body. The governed-call path records allow and deny decisions, and each executed call ends in exactly one terminal receipt.

The Decision enum is tagged, so a refusal carries its human-readable reason and the guard that triggered it. An investigator reading a deny receipt learns what was refused and which rule refused it. This body abbreviates its fields:

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

all_calls_produce_verified_receipts in crates/kernel/chio-kernel/src/kernel/tests/receipts.rs asserts the allow-and-deny invariant, and monetary_denial_receipt_contains_financial_metadata in crates/kernel/chio-kernel/src/kernel/tests/budget.rs the financial detail on a refusal.

Tamper-evident storage

Chio commits receipt batches into a signed KernelCheckpoint carrying the Merkle root over the batch, so an auditor detects a changed record and verifies inclusion in a committed batch.

• The checkpoint signature is Ed25519 over the canonical JSON of the checkpoint body, so an auditor checks it with public information alone. build_checkpoint_signature_verifies in crates/kernel/chio-kernel/src/checkpoint/tests.rs checks the round trip.
• build_inclusion_proof in crates/kernel/chio-kernel/src/checkpoint.rs proves one receipt belongs to the log without re-reading the batch. inclusion_proof_verifies_for_leaf_n in the same crate’s checkpoint/tests.rs asserts the proof verifies.
• A changed receipt fails its inclusion check against the original signed checkpoint. A root recomputed from changed bytes differs, and replacing the trusted checkpoint requires passing the checkpoint signature check.

Proof of possession

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. verify_dpop_proof_stateless in crates/kernel/chio-kernel/src/dpop.rs enforces the binding.

A proof signed by any other key is refused before the action runs, and a proof from one invocation fails for a different one. The nonce must be unseen within the TTL window, and the expiry must lie in the future within the clock-skew allowance.

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

Budget accountability

A receipt for a monetary grant carries FinancialReceiptMetadata. Allow receipts record the cost_charged the tool server reported, instead of the worst-case cap, with currency, budget_remaining, budget_total, and settlement_status. Deny receipts record the attempted_cost, so 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 concurrent invocations cannot overspend a grant through a read-modify-write race. monetary_allow_receipt_contains_financial_metadata checks the allow-side metadata and monetary_full_pipeline_three_invocations_third_denied the exhaustion transition, both in crates/kernel/chio-kernel/src/kernel/tests/budget.rs. Budgets & Metering covers the operational view.

Checkpointing interval

checkpoint_batch_size (default 100) sets how often the kernel produces a Merkle checkpoint: automatically after every N receipts. A lower value shortens the window in which a batch sits without a checkpoint. checkpoint_triggers_at_100_receipts in crates/kernel/chio-kernel/src/kernel/tests/receipts.rs verifies the default cadence.

The cadence is a deployment setting. checkpoint_batch_size: 0 turns automatic checkpointing off (crates/kernel/chio-kernel/src/kernel/kernel_struct.rs), so a deployment that relies on automatic checkpoints keeps it above zero.

Release evidence

The release's qualification evidence names the retention, proof-of-possession, checkpoint, and budget suites that back each control, with their results. A deployment review reads them beside the recorded controls and the deployment documentation; a passing suite is implementation evidence, and the statutory review stays with the deployer.

chio release verify --evidence qualification

binary         /usr/local/bin/chio  chio 0.2.0  x86_64-unknown-linux-gnu
checksum       matches SHA256SUMS for v0.2.0
signed by      release.yml on backbay-labs/chio, issuer token.actions.githubusercontent.com
qualification  bound to v0.2.0
  kernel: retention and archival     pass
  kernel: proof of possession        pass
  kernel: checkpoints                pass
  kernel: monetary budgets           pass
  manifest: sign and verify          pass
verified