HITRUST i1 Readiness Package

Package contents

The package lives under compliance/hitrust/ in the Chio repository. Each table row links to a file; the self-assessment points to current implementation evidence instead of a frozen bundle or draft report.

Assessment Scope

The scope is deliberately narrow: a single Chio deployment of the assessed release, serving one healthcare design-partner tenant, in one production deployment environment. The boundary binds the product surface and deployment, not any tenant identity, and it would stay the same if a real assessor engagement began. Anything not named in the scope boundary is out of scope and cannot be used to claim a control is satisfied.

In scope are 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 that already lives in the repository.

Implementation-status legend

Every row in control-mapping.csv carries a status flag. The mapping uses three values, applied under a fail-closed rule: a control is promoted only when it ties to a real source artifact and a named owner.

Control-Family Posture

The strongest families are the ones the protocol enforces in code: access control, risk management, security policy, asset management, and development assurance. The partial and gap families depend on operational cadence, out-of-tree legal and HR evidence, or cloud-provider inheritance. Every row is owned by chio-security.

Control-Mapping Format

The mapping is a flat CSV so a reviewer can diff it, sort it, and join it against an assessor's control list. The columns are control_id, family, narrative_path, evidence_sources (semicolon-separated repo paths), status, owner, and notes.

control_id,family,narrative_path,evidence_sources,status,owner,notes
ctl-access,Access Control,compliance/hitrust/narratives/i1-seed-access.md,spec/PROTOCOL.md; spec/SECURITY.md; crates/kernel/chio-kernel-core/src/evaluate.rs; formal/MAPPING.md,implemented,chio-security,Capability algebra evidenced by kernel code and formal proofs.
ctl-ops,Communications and Operations Management,compliance/hitrust/narratives/i1-seed-ops.md,spec/audit-log/export-schema.v1.json; crates/kernel/chio-kernel/src/receipt_store.rs; .github/workflows/ci.yml,partial,chio-security,Audit-log schema and receipt pipeline exist; 30-day operational samples are a gap.
ctl-privacy,Privacy Practices,compliance/hitrust/narratives/i1-seed-privacy.md,crates/observability/chio-log-redact/src/lib.rs; compliance/hitrust/policies/de-identification.md,partial,chio-security,Receipt redaction implemented and de-id policy documented; BAA receipt is out-of-tree.

Each narrative_path points at a plain-language control narrative under narratives/. Every narrative ends with a fail-closed note that states exactly what denies access or blocks promotion when the control is not met, so an assessor reads the enforcement boundary, not a marketing claim.

Formal Evidence Bridge

The audit-integrity and access-control rows lean on the formal/ tree. These are bounded, focused checks over trust-boundary properties, not a proof of the whole system. The bridge narrative maps each named invariant to the HITRUST concern it supports; the authoritative link from an invariant to the Rust call site it constrains is formal/MAPPING.md.

The specs, configs, and run records live in formal/ and are enforced in CI (.github/workflows/apalache-safety.yml, .github/workflows/apalache-temporal.yml). For the full inventory of theorems and the assurance pipeline behind them, see Formal Assurance.

Open Gaps and Closure Paths

The package names every gap and the artifact that closes it. A gap that depends on out-of-tree legal, HR, provider, or design-partner DR evidence stays a gap until that evidence exists; it is never marked satisfied on the basis of a plan.

Assembling the Evidence Package

The operational and audit-control rows are backed by signed receipts. chio evidence export assembles those receipts into a verifiable offline package that an assessor checks without touching the live kernel. The --require-proofs flag fails the export if any selected receipt lacks checkpoint coverage, which is exactly the tamper-evidence property the audit-integrity rows assert.

# Assemble the offline evidence package for the assessment window.
# --since / --until are Unix seconds; the pair below is the Q1 2026 window.
$ chio --receipt-db ./receipts.sqlite3 evidence export \
    --policy-file ./policy.yaml \
    --admin-all \
    --since 1767225600 \
    --until 1774915199 \
    --require-proofs \
    --output ./hitrust-i1-evidence

# Verify the package offline. Exit 0 means every receipt signature and
# checkpoint proof in the package reproduces.
$ chio evidence verify --input ./hitrust-i1-evidence

Local reads fail closed: pass --admin-all to export across every tenant as an administrative operation, or --tenant <id> to scope the export to one tenant. The two are mutually exclusive. The exported package carries the receipts for the window, the checkpoint coverage, and the attached policy file, so the audit-log schema v1 rows and the receipt-integrity rows verify from one artifact. For the receipt-level verification workflow, see Verify Receipts Offline.

MyCSF Portal Handoff

No MyCSF object exists yet; the object and its control count are created by HITRUST when an engagement begins. The portal config records the values the package would request and the inherited evidence packets it would load first. The upload model is deliberate: coarse inherited evidence first, control-specific evidence after remediation, with access limited to assessor reviewers and the chio-security evidence owner.

Two operational cadences back the partial rows. The access-review policy defines a quarterly human review of operator, capability-admin, and audit-log-export roles. The key-rotation policy sets the rotation schedule the operations rows depend on:

Capability signing rotation uses a fail-closed cutover: publish the new key id to the verifier set, issue only from the new key, hold the old key verify-only for the maximum capability lifetime, then revoke it and record the cutover receipt. If the verifier set cannot load the new key, issuance pauses and access is denied rather than falling back to an untracked signer. For the runtime mechanics of rotation and revocation, see Rotate Keys & Revoke.

Cross-References

• Compliance Frameworks for the HIPAA Security Rule mapping that the healthcare scope builds on, plus SOC 2 and PCI DSS.
• Receipts for the signed record format that backs the audit-control and operational families.
• Capabilities for the scoping, attenuation, and revocation model behind the access-control family.
• Formal Assurance for the theorem inventory that the formal-evidence bridge draws from.
• ISO/IEC 42001 and NIST AI RMF for the same evidence surface mapped onto the AI-management standards.