Compliance as Code

This page compares document-based controls with controls enforced in the request path, then links each implementation area to its mechanism.

Document-Based Compliance

Many organizations maintain compliance documentation separately from the operating system. Policies describe expected behavior, questionnaires and interviews report it, and audit preparation reconstructs it from records. The documentation and operating system can drift.

Agents can act faster and at higher volume than document-review cycles. An auditor may sample 25 transactions from a million and extrapolate. The kernel evaluates each mediated call before it runs and signs its decision. This changes the coverage and timing of the control.

For mediated agent calls, governance and compliance records can use the same mechanism. Chio implements this through four related areas: policy, enforcement, signed receipts, and framework mapping.

Four Implementation Areas

Policy defines a control, the request path enforces it, signed receipts record its execution, and framework mappings connect receipt records to controls.

Policy is code

A HushSpec policy declares what an agent may do. The compiler produces the seven-guard default pipeline and capability grants from that policy. The policy file is versioned, reviewed in pull requests, tested in CI, and deployed as code.

hushspec: "0.1.0"
name: phi-access-control
description: Claims-processing agent. PHI stays behind scoped, default-deny grants.
extends: "chio:default"
merge_strategy: deep_merge

rules:
  # The control objective "least privilege for claims data" as an
  # executable rule, not a sentence. Illustrative framework hooks:
  # HIPAA 164.312(a)(1) technical access control, PCI DSS 7.2 default-deny.
  tool_access:
    enabled: true
    default: block
    allow:
      - read_claim
      - summarize_claim
    require_confirmation:
      - export_claim_batch   # human counter-signature above this line
  forbidden_paths:
    enabled: true
    patterns:
      - "**/.env*"

A control objective like “least privilege for claims data” becomes a default: block the kernel enforces. The policy parses with deny_unknown_fields, so a typo becomes a parse error, and a policy diff records the change. The format is documented in HushSpec Policy Format, how policies bind to deployments in chio.yaml Configuration, and how they are exercised before rollout in Testing Guards & Policies.

Enforcement is the request path

Controls in the request path apply to each mediated call. A tool call an agent makes is a mediated call: a capability answers the static question (was this authorized), the guard pipeline answers the dynamic one (should this specific action happen, right now), and both fail closed. Training, review meetings, and runbooks may also be controls, but they rely on a person following a process.

Auditors distinguish control design from operating effectiveness, because a well-designed control can still sit unused. In the request path, a mediated call records that the control ran. Where a control needs a person, the same path records the approval. A RequireApprovalAbove constraint pauses the call as PendingApproval until an authorized approver counter-signs. The mechanics are in Human-in-the-Loop.

Signed receipts

Each mediated decision emits a signed, content-addressed receipt: allow, deny, canceled, incomplete (the state a call suspends into while it awaits approval). The kernel emits the record as part of the mediated call, so audit exports can be built from receipt data.

{
  "id": "9b2e4d7c1a5f8e30b6d9c2a74e1f0b8d5c3a6e9f2b4d7c0a8e1f3b5d7c9a2e4f",
  "timestamp": 1753142400,
  "capability_id": "0192b5d4-3e2a-7f61-8c09-5a7b9d1e3f2c",
  "tool_server": "srv-claims",
  "tool_name": "delete_claim",
  "decision": {
    "verdict": "deny",
    "reason": "tool delete_claim is not in the allow set",
    "guard": "mcp-tool"
  },
  "receipt_kind": "mediated_decision",
  "policy_hash": "7d1f4a9c2b8e6d05",
  "evidence": [
    { "guard_name": "mcp-tool", "verdict": false, "details": "default: block; delete_claim not allowed" }
  ],
  "kernel_key": "9c7b3f1a2e8d4c6b5a09f8e7d6c5b4a3928170f6e5d4c3b2a1908f7e6d5c4b3a2",
  "signature": "c4d5e6f7a8b9..."
}

A denial records a control decision. The receipt above includes the verdict, the guard that produced it, and a policy_hash naming the exact control version that ran. The kernel signs the receipt, whose ID is the hash of its canonical body. An auditor can verify the log offline with the kernel public key. Evidence bundles package a period's receipts for review. The record format is in Receipts, receipt-log verification is in Verifiable Evidence, the export flow is in Compliance Frameworks, and the machine interface is in Regulatory & Audit APIs.

Attestation is a computation

An attestation can be computed from a receipt corpus. The first part is mapping: Chio's shipped components map to named controls in NIST AI RMF, the EU AI Act, ISO 42001, HITRUST i1, and Colorado SB 24-205, plus PCI DSS v4 and indicative SOC 2 and HIPAA mappings. Each mapping page identifies the component associated with a control. Receipts can demonstrate operation over a period.

The second part is formal proof. Some properties are proved over a defined model, including capability attenuation (the P1 monotonicity proof in Lean 4). The rest of the inventory is in Formal Assurance. Formal assurance documents the model, assumptions, and limits for each proof. The theorem inventory is in the Theorem Inventory, and how attestations package for a counterparty is in Compliance Certificates.

Continuous Evidence for Regulated Work

Regulated organizations need records of what an agent did. When governance emits machine-verifiable evidence for mediated calls, operators can provide those records for review.

The same receipt data can support compliance review, settlement, and reputation calculations. Sovereign Agentic Cognition describes workload identity. This page describes compliance evidence for mediated calls. Autonomous Commerce describes settlement and reputation uses, and Proposed Cognition Market proposes a market for governed-agent findings.

Summary

1. Compliance elsewhere is a parallel paper system. Chio compiles it into the request path, so governance and evidence are one mechanism.
2. Policy is code. A HushSpec file is the control: versioned, diffable, tested, and compiled into the guard pipeline plus capability grants.
3. Enforcement is the request path. Capability and guard both have to clear, both fail closed, and there is no unguarded path, so design and operating effectiveness collapse into one fact.
4. Evidence is a byproduct. Every decision emits a signed, content-addressed receipt that verifies offline against the kernel public key alone.
5. Attestation is a computation. Framework mappings roll receipts up to named controls, and formal proofs remove sampling entirely for core properties.

Next Steps

• Guards · the seven-guard default pipeline behind every in-path control
• HushSpec Policy Format · the schema a control is written in, and the compile path to a pipeline
• Receipts · the signed record and its offline verification path
• Verifiable Evidence · how receipt logs are verified
• Compliance Frameworks · the cross-framework mapping and the evidence-export flow
• Formal Assurance · the proof lanes behind the attestation rung