NIST AI RMF

Chio's records answer Map and Manage most directly

Capabilities, guards, receipts, and revocation are the tool-layer form of context identification, control cataloging, and risk response. Each operator-owned outcome still names the Chio record that supports it.

Govern subcategories are mostly organizational, and Chio contributes where policy as code and workload identity meet organizational records. Measure starts from the raw signed data the kernel emits.

Govern rests on the operator's policies, with the policy hash as evidence

Govern asks for organizational culture, policies, roles, and accountability. Chio contributes policy definitions, signed policy hashes in receipts, workload identity attribution, and the revocation and decommissioning mechanics.

GOVERN-1.1Identify and maintain applicable legal requirements.

Capability tokens carry issuer, issued_at, and expires_at, and every receipt carries the policy hash in force. The operator keeps an applicability register with jurisdiction, role, owner, and review date.

GOVERN-1.2Integrate trustworthiness into organizational practices.

The guard pipeline fails closed, and chio-policy defines the policy artifacts its defaults compile from. A policy artifact carries rules only, so the operator documents which trustworthiness objectives each technical policy supports.

GOVERN-1.3Choose risk-management effort using organizational risk tolerance.

Velocity configuration, max_total_cost, and max_cost_per_invocation encode tolerance as executable configuration. The operator records the risk decision that justifies each configured limit.

GOVERN-1.5Plan periodic risk review and assign responsibilities.

The receipt store, the checkpoint monitor, and the chio trust serve dashboard give reviewers their records. The operator assigns reviewers, review frequency, escalation criteria, and follow-up actions.

GOVERN-1.6Maintain and resource an inventory of AI systems.

Each tool server publishes a signed ToolManifest, and each capability carries WorkloadIdentity metadata. The operator connects tool and workload records to the organization's full AI-system inventory.

GOVERN-1.7Retire AI systems safely.

Capability revocation, grant expiry, and delegation revocation end the authority a retired system held. The operator defines retirement responsibilities and dependencies, then verifies the effect after deactivation.

GOVERN-2.1Document risk roles and communication responsibilities.

CapabilityToken.issuer and the delegation chain attribute authority at the protocol layer. The operator maintains accountable human owners and communication routes.

GOVERN-2.2Train personnel and partners for their risk responsibilities.

Training and competence are organizational records. The operator retains them for its personnel and partners.

GOVERN-4.1Establish organizational practices for critical thinking and safety.

Kernel evaluation fails closed and signs a deny receipt on every error path. The operator records review practices and decisions, with deny receipts as technical inputs.

GOVERN-4.3Enable testing, incident identification, and information exchange.

Signed evidence bundles from the export envelope carry portable audit exchange. The operator maintains incident identification and sharing procedures with named recipients.

GOVERN-5.1Collect and use external feedback about AI impacts.

Receipts link a feedback-driven change to the policy used afterward. The operator collects and prioritizes stakeholder feedback and documents how it changes system decisions.

GOVERN-6.1Address third-party AI risks, including rights and intellectual property.

Capability scoping restricts which third-party tools an agent reaches, and delegation attenuation prevents authority amplification. The operator assesses suppliers and contractual risks beyond tool access.

For GOVERN-1.1, the signed token body gives a reviewer the issuer and the validity window. The applicable laws themselves live in the operator's applicability register.

pub struct CapabilityTokenBody {
    pub id: String,
    pub issuer: PublicKey,
    pub subject: PublicKey,
    pub scope: ChioScope,
    pub issued_at: u64,
    pub expires_at: u64,
    #[serde(default, skip_serializing_if = "Vec::is_empty")]
    pub delegation_chain: Vec<DelegationLink>,
    #[serde(default, skip_serializing_if = "Option::is_none")]
    pub aggregate_invocation_budget: Option<AggregateInvocationBudget>,
}

The policy hash is the audit anchor. When an auditor asks which rule refused a call, the receipt names the hash, the retained policy source defines the rule, and the signed bundle ties the two together once the receiver pins the expected signer. Compare the compiled hash of the retained source with the receipt, because a valid signature alone leaves the policy relationship unchecked.

Map reads the context the kernel already records

Signed tool manifests, capability-scoped grants, the guard catalog, and per-invocation receipts with full provenance already describe each tool call. Map's context identification, risk scoping, inventory, and control cataloging draw on those records.

MAP-1.1Document intended use, users, context, and potential impacts.

Tool manifest descriptions and workload identity metadata on capability tokens describe the tool layer. The operator maintains the system context and intended-use record beside them.

MAP-1.5Define and document organizational risk tolerance.

Velocity configuration, budget caps, and the GovernedAutonomyTier on capability tokens express tolerance as kernel settings. The operator approves the tolerance explicitly before translating it into those settings.

MAP-2.1Define the AI system's tasks and implementation methods.

Each tool definition in the signed manifest declares its parameter schema, description, and typed constraints. The operator describes the model and task method; the manifest documents the tool interface.

MAP-2.3Identify scientific limitations and suitability of evaluation methods.

Signed manifests and policy versions identify the operational configuration an evaluation ran under. The operator selects the scientific evaluation methods and documents knowledge limits, test methodology, and the populations evaluated.

MAP-3.2Examine potential costs from AI errors and expected outcomes.

Receipts on monetary grants carry FinancialReceiptMetadata under budgets enforced inside the kernel. Monetary cost is the type receipts record, so the operator assesses nonfinancial harms and organizational costs alongside invocation charges.

MAP-3.4Define operator proficiency and performance requirements.

Workload and capability identities name the software actor. The operator documents human competence, performance expectations, and relevant professional requirements as separate records.

MAP-3.5Define and assess human oversight processes.

DPoP proofs attribute each call, and a GovernedApprovalToken anchors step-up review at higher autonomy tiers. The operator names the reviewer, decision authority, intervention path, and effectiveness checks.

MAP-4.1Map technical and legal risks of components and third-party data.

The guard pipeline produces structured verdicts, and receipt analytics surface aggregates. The operator assesses third-party data, software, and rights; access restrictions cover part of that work.

MAP-4.2Identify and document internal risk controls.

The named guards are the control inventory at the tool boundary: velocity, egress allowlist, secret leak, path allowlist, data flow, response sanitization, and patch integrity. The operator maintains the inventory with owner, scope, test, and residual risk.

MAP-5.1Determine likelihood and magnitude of identified impacts.

The receipt store holds the raw data, and the risk scoring layer is the operator's. Receipt counts are one input; the operator adds contextual impact assessment and stakeholder input.

Read more in Capabilities for the scoping model and Guards for the named controls behind MAP-4.2.

Measure starts from signed, queryable records

Every invocation, denial, guard trigger, and cost event routed through the kernel is a signed record. The receipt query API aggregates those records into denial rates, trigger counts, and cost totals, the starting data for Measure's quantitative analysis, tracking, and reporting.

MEASURE-1.1Select appropriate risk measurements and coverage priorities.

The receipt query API exposes counts, denial rates, cost aggregates, and guard-trigger frequencies. The operator records metric definitions, rationale, coverage, and unmeasured risks.

MEASURE-2.3Evaluate performance under representative deployment conditions.

The receipt store records timing, outcome, and cost, and SIEM export streams them to downstream analytics. The operator retains representative test conditions, results, and acceptance criteria.

MEASURE-2.4Monitor production behavior and component functionality.

Signed evidence bundles and session compliance certificates record production behavior. The operator runs monitoring, investigates deviations, and retains the resulting decisions.

MEASURE-2.5Demonstrate validity and reliability and document generalization limits.

The fail-closed pipeline, checkpoint integrity verification, and archived signed receipts are reliability evidence. The operator evaluates the complete AI system, of which fail-closed execution is one property.

MEASURE-2.6Evaluate safety and residual risk against the intended context.

Jailbreak and prompt-injection detectors in the application-layer guard suite run beside the secret_leak, egress_allowlist, and forbidden_path guards. The operator defines safety metrics and acceptable residual risk, then evaluates the whole system.

MEASURE-2.7Evaluate and document security and resilience.

Signed receipts, Merkle checkpoints, DPoP, and capability revocation are the security evidence at the tool boundary. The operator tests the deployed threat model and recovery behavior beyond individual kernel checks.

MEASURE-2.8Evaluate transparency and accountability risks.

Signed receipts attribute recorded decisions and expose their policy and capability references; model reasoning sits outside them. The operator documents the explainability of the decision process, responsible owners, and evidence access.

MEASURE-3.2Plan risk tracking when measurement is difficult or unavailable.

Receipts preserve observable tool decisions. The operator identifies the risks those events cannot measure and adopts qualitative tracking methods for them.

MEASURE-4.2Validate trustworthiness measurements with relevant experts and actors.

Scoped deployment configuration and receipt histories feed expert and stakeholder reviews. The operator retains the reviewers' conclusions separately.

Scoring belongs to the operator, because it requires taxonomy choices specific to each organization. A program that needs a numerical risk score plans an operator-owned analytics layer that consumes Chio receipts.

Read more in Receipts, which defines the record format Measure reads.

Manage acts through revocation, approval, and the emergency stop

Prioritization, risk response, monitoring, and supersession make up Manage. At the tool boundary, capability revocation, scope reduction, step-up approval, delegation bonds, and evidence export for remediation carry those responses.

MANAGE-1.1Decide whether the system meets its purpose and should proceed.

Underwriting tiering and the GovernedAutonomyTier on capability tokens inform the decision. The operator records the go or no-go decision and the purpose, impact, and risk evidence behind it.

MANAGE-1.2Prioritize risk treatment by impact, likelihood, and resources.

Guard pipeline verdicts, deny receipts, scope reduction, and grant expiry are the treatment mechanisms. The operator maintains a prioritized treatment plan that includes risks outside kernel enforcement.

MANAGE-1.3Plan and document responses to high-priority risks.

Revocation, scope reduction, and approval tokens carry out a response. The operator records the selected response, owner, completion criteria, and residual risk.

MANAGE-1.4Document residual risk.

The operator maintains the residual-risk register and builds it from receipt aggregates.

MANAGE-2.1Consider resources and non-AI alternatives for risk reduction.

Per-grant caps and monetary receipts enforce and record budgets. The operator evaluates operational resources and viable alternatives, with a spend cap as one input.

MANAGE-2.2Apply mechanisms that sustain deployed system value.

Outcome and cost records inform a value review. The operator decides whether the deployed system remains useful and what to maintain or change.

MANAGE-2.3Respond to and recover from newly identified risks.

A guard pipeline deny, step-up approval through GovernedApprovalToken, and evidence export for downstream investigation support the response. The operator maintains an incident and recovery procedure and tests it in the deployment.

MANAGE-2.4Assign and exercise authority to override or deactivate unsuitable systems.

Capability revocation, grant expiry, approval refusal, and chio emergency-stop carry out a documented intervention, and each refuses the calls that follow it. The operator names the responsible person, applies the intervention, and verifies its effect on running work and on work started afterward.

MANAGE-3.1Monitor third-party AI risks and apply documented controls.

Adding a partner card pins the partner's kernel key; signed manifests, treaty admission, and scoped capabilities control the selected counterparty. The operator reviews suppliers and component changes continuously and records treatment decisions.

MANAGE-4.1Implement post-deployment monitoring and response plans.

The receipt stream and checkpoint integrity checks carry post-deployment monitoring. The operator's plan covers appeals, overrides, incident response, recovery, and change management.

MANAGE-4.2Integrate measurable improvement and stakeholder engagement into updates.

Guard evidence in each receipt and the SIEM event stream record what changed. The operator tracks improvement actions and stakeholder feedback through releases.

The prioritization rows draw on chio-underwriting, which sorts an agent into one of four risk tiers, Baseline, Guarded, Elevated, or Critical, from its receipt, reputation, certification, and settlement evidence, and pairs each tier with typed reason codes. Underwriting is an optional module, off in default builds of the kernel, core, trust control plane, and CLI.

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

For MEASURE-2.4, reconcile the governed-call population and the denial samples against the production monitoring plan. For MANAGE-2.4, retain the decision to deactivate an unsafe use and show that subsequent calls are refused. The EU AI Act oversight example carries the signed decision and the stop path; those records support the operator's review, and the review completes the RMF outcome.

The operator owns scoring, residual risk, and the model layer

The RMF is voluntary and process-oriented. Your compliance team owns the process documentation, the review cadence, and the attestation, and four outcomes stay wholly with the operator.

1. Risk scoring. Chio emits the raw data for Measure; the operator scores it.
2. Residual-risk register. MANAGE-1.4 asks for residual risk to be tracked. The operator builds that register from receipt aggregates.
3. Fairness, bias, and environmental impact. MEASURE-2.9 through MEASURE-2.12 concern model-layer properties that a tool-governance layer cannot observe.
4. Workforce subcategories in Govern. Roles, training, leadership commitment, and stakeholder culture are organizational practices.

Next: verify the package before a review relies on it