HITRUST i1 Readiness Package

One tenant, one release, and one environment bound the assessment

The package covers a single Chio deployment of the assessed release, serving one healthcare design-partner tenant in one production environment. The boundary names the product and the deployment, so it stays fixed when an assessor engagement begins, whichever tenant identity the engagement records.

• In scope. The runtime kernel binaries; capability issuance, validation, attenuation, revocation, and sender constraints; guard evaluation and fail-closed behavior; receipt generation, signature, and export under audit-log schema v1; and the build-provenance, SBOM, cargo-vet, CVE-monitoring, threat-model, and formal-invariant evidence in the repository.
• Excluded. Mobile patient-app surfaces; the AWS Bedrock and MCP marketplace listings; other Chio tenants and releases; other operator systems; and ISO 42001, SOC 2 Type II, and HITRUST r2.

A control claimed against anything outside the boundary has no standing in this package. The full decisions, with the scope-memo preimage, are in scope-boundary.md.

Each control family names its evidence record and its owner

Five families rest on Chio's own code and release evidence: access control, risk management, security policy, asset management, and development assurance. Access control adds the operator's quarterly review. The rest pair a Chio record with an operating cadence, a contract, or a provider attestation the operator holds.

Access control is enforced in the kernel: capability attenuation, revocation, and sender constraints run in evaluate.rs before any governed call dispatches. Incident containment uses the same mechanisms, with chio emergency-stop refusing every governed call until an operator resumes the kernel.

Four model-checked invariants back the access and audit rows

The audit-integrity and access-control rows cite bounded checks over trust-boundary properties in the formal/ tree. Each check covers its model, and formal/MAPPING.md links every invariant to the Rust call site it constrains.

• MonotoneLogApalache: receipt-log state only advances, and committed entries stay in the log. Supports audit controls, integrity, and operations.
• RevocationCutCompleteness: a revocation cut removes future authority for revoked grants within the modeled boundary. Supports access control and incident containment.
• ReceiptBeforeAllow: a modeled allow decision has receipt evidence before the operation counts as complete. Supports audit controls and compliance evidence.
• KernelTransitionCancelSafe: a canceled kernel transition leaves no allowed tool call without the modeled checks. Supports fail-closed operations and development assurance.

The specs, configurations, and run records live in formal/, and CI runs the model checker through .github/workflows/apalache-safety.yml and .github/workflows/apalache-temporal.yml. The bridge narrative in narratives/ maps each invariant to the HITRUST concern it supports.

Read more in Formal Assurance, which carries the theorem inventory and the assurance pipeline.

Recorded evidence stays outside the PHI boundary

Kernel telemetry for the assessed deployment holds protocol decisions, receipt ids, control ids, hashes, error classes, and timing metadata. Payload content, patient identifiers, and free-text clinical data stay out of it under the de-identification policy, which follows 45 CFR 164.514.

A sample that could cross the PHI boundary appears in the package only as a hash plus a private evidence reference. PHI-bearing samples move through a BAA-approved channel and never through a commit to the repository.

Review evidence comes from one verified package

The complete evidence workflow produces three signed receipts, samples allow and deny decisions from the same recorded window, exports them with checkpoint proofs, and verifies the package. It carries the kernel host, every command, the captured results, and two deliberate refusals.

For a deployment review, substitute its receipt database and the approved tenant and time boundary. Preserve the original package, record the trusted kernel public key through an independent channel, and attach the framework owner, assessment scope, findings, and open work. A passing cryptographic check is one input to that review.

cargo run --locked --bin evidence

two allowed calls; one out-of-scope denial; handler calls 2
three receipt signatures verified; checkpoint batch size 1
wrote evidence-run/receipts.sqlite3, window.json, and kernel-public-key.txt

EVIDENCE_SINCE=$(jq -r .since evidence-run/window.json)
EVIDENCE_UNTIL=$(jq -r .until evidence-run/window.json)
mkdir -p samples
chio receipt list --receipt-db evidence-run/receipts.sqlite3 --admin-all \
  --since "$EVIDENCE_SINCE" --until "$EVIDENCE_UNTIL" \
  --outcome allow --limit 100 > samples/allow.jsonl
chio receipt list --receipt-db evidence-run/receipts.sqlite3 --admin-all \
  --since "$EVIDENCE_SINCE" --until "$EVIDENCE_UNTIL" \
  --outcome deny --limit 100 > samples/deny.jsonl
jq -s length samples/allow.jsonl
jq -s length samples/deny.jsonl

2
1

EVIDENCE_SINCE=$(jq -r .since evidence-run/window.json)
EVIDENCE_UNTIL=$(jq -r .until evidence-run/window.json)
chio evidence export --receipt-db evidence-run/receipts.sqlite3 --admin-all \
  --since "$EVIDENCE_SINCE" --until "$EVIDENCE_UNTIL" \
  --require-proofs --output evidence-package
chio evidence verify --input evidence-package

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

The assessor checks each receipt signature, checkpoint proof, and signer key against the steps in verify security evidence.

The assessment export refuses a window without checkpoint coverage

The operational and audit-control rows rest on signed receipts. chio evidence export assembles the receipts for the assessment window into a package an assessor verifies without touching the live kernel. --since and --until take Unix seconds; the pair below is the first quarter of 2026.

chio --receipt-db ./receipts.sqlite3 evidence export \
    --policy-file ./policy.yaml \
    --admin-all \
    --since 1767225600 \
    --until 1775001599 \
    --require-proofs \
    --output ./hitrust-i1-evidence
chio evidence verify --input ./hitrust-i1-evidence

--require-proofs makes the tamper-evidence property of the audit-integrity rows a condition of the export. Against a store whose durable tail has no checkpoint yet, the export refuses, reports how many receipts lack coverage, and lists up to five of them with their sequence numbers:

$ chio --receipt-db ./.chio/receipts.db evidence export \
  --output ./evidence-proofs --admin-all --require-proofs

error[CHIO-ATTEST-PROVENANCE-MISSING]: evidence export requires checkpoint coverage, but 2 receipt(s) are uncheckpointed: f8128d2289c69d835348f229edfdd2714a8b3c6f064f4f7324b652a299e9a4b3@1, e7a4fc95979cc9b31d8b740c27cd58f1fde209aac323aaeac115544d82be2ee7@2
  help: export again once a checkpoint covers these receipts, or drop --require-proofs
  code: urn:chio:error:attest:provenance-missing
  docs: https://chio.computer/docs/reference/errors#error-attest-provenance-missing

No directory is written: validate_evidence_bundle_requirements runs before write_evidence_package reaches ensure_clean_output_dir. Verification exits 0 when every receipt signature and checkpoint proof in the package reproduces. Local reads require --admin-all, an administrative export across every tenant, or --tenant <id> for one tenant; the two are mutually exclusive.

$ chio evidence verify --input ./evidence

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

The package carries the window's receipts, their checkpoint coverage, and the attached policy file, so the audit-log schema v1 rows and the receipt-integrity rows verify from one artifact.

Read more in Verify Receipts Offline, which walks the receipt-level checks.

The operator runs the reviews, contracts, and facilities each family needs

Each duty below has a policy or plan in the package and an evidence record the operator retains for the assessor.

1. Access review. Each quarter, a person reviews the operator, capability-admin, and audit-log-export roles, plus break-glass grants, under policies/access-review.md. Access Control and Operations.
2. Key rotation. Rotate on the schedule in policies/key-rotation.md and retain each rotation record. Operations.
3. Operational samples. Pull 30-day audit-log samples with chio evidence export under schema v1, per operational-samples.md. Operations.
4. Incident cycle. Exercise ir-runbook.md and retain each cycle's record. Incident Management.
5. BAA chain. Attach the private BAA reference through the approved evidence channel before any PHI sample is used. Privacy and Compliance.
6. Workforce, facilities, continuity. Keep HR policy and training references, record provider attestations per encryption-at-rest.md, and hold the design-partner disaster-recovery reference.
7. Program and assessment. Run the security-review cadence, keep operating-role evidence, and engage the external assessor through the MyCSF object.

Next: build the evidence package an assessor verifies