ISO 42001 Mapping

The evidence concentrates in operation, monitoring, and Annex A logging

Five clause families carry most of Chio's contribution.

1. Clause 7.5, documented information. Signed receipts, checkpoints, compliance certificates, and evidence bundles, each in canonical JSON with a timestamp and key reference.
2. Clause 8.1, operational planning and control. The guard pipeline, the capability lifecycle (issue, delegate, revoke, expire), and tool-server lifecycle evidence through signed manifests.
3. Clause 9.1, monitoring and measurement. The receipt query API, checkpoint-status reporting, receipt analytics, and SIEM export.
4. Annex A.6.2.8, event logging. A signed receipt per invocation, Merkle-committed batches, and DPoP attribution.
5. Annex A.7, data for AI systems. Data-layer guards: SQL and warehouse access guards, vector-store constraints, column-level restrictions, and response sanitization.

Clauses 4 (context), 5 (leadership), most of 6 (planning), 7.1 through 7.4 (resources, competence, awareness, communication), and 10 (improvement) are largely organizational. Their rows name the operator as owner and the Chio record that supports it, where one exists.

The organization runs the management system; the kernel records its operation

The kernel owns four rows: 6.3, 7.5.3, 8.1, and 9.1. Every other row names the operator as owner and the Chio record that supports its work.

Clauses 4 and 5: context and leadership

4.3Scope of the AIMS

Capability issuance marks which tool servers sit inside the governed scope. The operator documents deployment-level scope per site.

4.4AI management system

The operational layer of guards, receipts, and revocation runs continuously and produces signed records.

5.1Leadership and commitment

Top management demonstrates leadership and commitment. The operator records that commitment and the management decisions, as it does for context and interested parties under 4.1 and 4.2.

5.2AI policy

Policy-as-code artifacts compile from chio-policy, and every receipt embeds the policy hash.

5.3Roles, responsibilities, authorities

The issuer and delegation chain on every capability attribute technical authority. Human roles are the operator's record.

Clause 6: planning

6.1Actions to address risks and opportunities

Guard pipeline deny paths, capability scoping, and budget caps act on identified risks.

6.1.2AI risk assessment

Underwriting tier classification and receipt analytics aggregates supply the technical inputs.

6.1.3AI risk treatment

Revocation, scope tightening, and approval tokens for step-up review carry out selected treatments. The operator owns the treatment plan, acceptance decisions, and effectiveness review.

6.1.4AI system impact assessment

Underwriting risk reasons and receipt impact data feed the assessment, whose format is the operator's.

6.3Planning of changes

The policy hash in every receipt ties each call to a policy version, and request matching ties the call to a request-schema version.

The underwriting inputs come from chio-underwriting, which classifies an agent into one of four risk tiers, Baseline, Guarded, Elevated, or Critical, from evidence references: receipt history, reputation, certification, runtime assurance, settlement exposure, and metered billing. Its evaluator fails closed and emits typed reason codes such as low_reputation, missing_certification, and pending_settlement_exposure.

The tier and its reasons populate the risk column of a 6.1.2 risk assessment and an 8.4 impact assessment, and the assessment itself stays the operator's document. Underwriting is an optional module, off in default builds of the kernel, core, trust control plane, and CLI.

Clause 7: support

7.4Communication

SIEM export, the trust-control dashboard, and compliance certificates carry information to interested parties.

7.5Documented information

Receipts, checkpoints, compliance certificates, and evidence bundles are signed records.

7.5.2Creating and updating

Each signed record uses its specified canonical encoding, signature, timestamp, and key reference. The operator controls document naming, review, approval, and changes.

7.5.3Control of documented information

Archival through evidence retention keeps receipts verifiable, and inclusion proofs detect changes against a trusted checkpoint. The operator owns access controls, retention schedules, retrieval tests, and document approval.

Clause 8: operation

8.1Operational planning and control

The guard pipeline and grant-scoped operational controls run with a fail-closed default.

8.2AI risk assessment

Receipt histories and underwriting assessments supply technical inputs. The organization performs and records risk assessments at planned intervals and when material changes occur.

8.3AI risk treatment

Scoped capabilities, revocation, approval controls, and policy changes implement selected risk treatments. The organization owns the treatment plan, acceptance decisions, and effectiveness review.

8.4AI system impact assessment

Tool declarations and decision records describe operational effects. The organization assesses impacts on individuals, groups, and society, and retains the assessment and review decisions.

Clauses 9 and 10: performance evaluation and improvement

9.1Monitoring, measurement, analysis, evaluation

The receipt query API, chio receipt checkpoint status, and receipt analytics supply the measurements.

9.2Internal audit

Evidence export bundles, compliance certificates, and Merkle inclusion proofs make evidence assembly repeatable. The operator runs the audit program at planned intervals and retains its findings.

9.3Management review

Compliance certificates summarize operational posture as an input to the review the operator holds.

10.1Continual improvement

Receipts feed improvement workflows; policy evolution is the operator's decision.

10.2Nonconformity and corrective action

Deny receipts, revocation, scope reduction, and approval escalation carry corrective action. Because every deny is signed, the receipt chain answers which policy refused an action and whether a mitigation was applied.

The monitoring rows rest on three named mechanisms: the receipt query API, receipt analytics, and the checkpoint-lag metrics chio_receipt_seconds_since_last_checkpoint and chio_receipt_uncheckpointed_seq_range, which chio receipt checkpoint status reports on demand. SIEM export streams the same events to the operator's analytics.

Annex A logging, data, use, and third-party controls carry the strongest evidence

Annex A supplies a reference set of AI-specific controls, with identifiers at family and nested levels in the pattern A.x.y or A.x.y.z; A.6.2.8, for example, identifies event logging. Chio contributes most to A.6 (life cycle), A.7 (data), A.8 (information sharing), A.9 (use), and A.10 (third parties).

A.2Policies related to AI

Policy-as-code through chio-policy, with the policy hash in every receipt. The operator approves and reviews the organizational AI policy and its relationship to executable rules.

A.3Internal organization

The issuer and delegation chain attribute authority at the protocol layer. The operator assigns human responsibilities and a channel for reporting concerns.

A.4Resources for AI systems

The tool manifest catalogs tools, and budget caps manage compute spend. The operator inventories data, tooling, compute, and human resources within the assessment scope.

A.5Assessing impacts of AI systems

Underwriting tier classification and receipt-based impact aggregation are inputs. The operator documents effects on individuals, groups, and society; a runtime risk tier feeds that assessment and leaves it to the operator.

A.6AI system life cycle

The capability lifecycle runtime, revocation, and grant expiry. For the family and each A.6.2 control below, the operator retains lifecycle objectives, design decisions, validation evidence, deployment approvals, and operating records.

A.6.2.2Requirements and specification

Tool definition parameter schemas inside signed manifests.

A.6.2.3Design and development

Workspace-wide clippy -D warnings, a denylist on unwrap_used, a canonical encoding defined for each signed artifact, and Lean 4 proofs for protocol invariants, covering Chio's tested implementation.

A.6.2.4Verification and validation

Workspace-level cargo tests, guard integration tests, and a conformance suite for external implementations (chio conformance run).

A.6.2.5Deployment

Capability issuance, grant constraints, and velocity guards.

A.6.2.6Operation and monitoring

The receipt store, the dashboard, SIEM export, and checkpoint-status reporting.

A.6.2.7Technical documentation

Signed tool manifests and compliance certificates.

A.6.2.8Recording of event logs

A signed receipt per invocation, allow or deny, with Merkle checkpoints over batches.

A.7Data for AI systems

Data-layer guards for SQL, warehouses, and vector stores, response sanitization, and column-level constraints. The operator documents the data-management process, quality checks, provenance, and preparation controls.

A.7.3Data acquisition

The egress allowlist and internal-network guards limit where an agent can acquire data. The operator records approved sources, acquisition terms, and the data obtained.

A.7.4Data quality

Data-quality programs run in the operator's data platform.

A.7.5Data provenance

Workload identity, DPoP attribution, and the receipt capability chain attribute runtime callers. The operator maintains dataset origin and transformation records, with runtime caller attribution as supporting evidence.

A.7.6Data preparation

Preparation pipelines are the operator's.

A.8Information for interested parties

Compliance certificates and evidence export bundles. The operator provides the required system information, the external reporting process, and incident communications.

A.9Use of AI systems

Capability scoping, delegation attenuation, and approval tokens bound what an agent may do. For the family, A.9.3, and A.9.4, the operator defines intended and responsible use, user responsibilities, and monitoring of actual use.

A.9.3Objectives for responsible use

Budget and velocity caps and the guard suite.

A.9.4Intended use

Tool manifest descriptions and GovernedAutonomyTier declarations.

A.10Third-party and customer relationships

Capability-scoped access to third-party tools and manifest verification signatures. The operator allocates supplier and customer responsibilities and retains due-diligence and agreement records.

Across the A.6 life cycle, Chio covers the deployment and operational portions: the ToolManifest at authoring, capability issuance at deployment, signed receipts at runtime, and revocation with evidence archival at retirement. A model's design, training, and evaluation phases run in the operator's training pipeline, with its own tooling.

A Statement of Applicability entry pairs each decision with the evidence to collect

A Statement of Applicability names each Annex A control, states whether it applies, justifies the decision, and identifies implementation evidence. Chio's records fill the evidence column.

framework: ISO/IEC 42001:2023
system_scope: "replace with the assessed system and environment"
review_status: unassessed
controls:
  A.6.2.8:
    title: Recording of event logs
    applicability_decision: pending
    decision_owner: "assign an accountable owner"
    justification: "record scope, risks, and the applicability decision"
    technical_contribution: signed receipts and checkpoint proofs
    evidence_to_collect:
      - evidence-package/manifest.json
      - evidence-package/receipts.ndjson
      - samples/allow.jsonl
      - samples/deny.jsonl
    review_required:
      - reconcile the population and excluded operations
      - verify signer trust and checkpoint coverage
      - approve access, retention, and incident procedures
    reviewer: null
    reviewed_at: null
    findings: []

Write one entry per applicable control. A.7 is a family heading, so each control beneath it takes its own decision. Record data provenance under A.7.5 with the source and transformation records; training-data provenance comes from those records, with runtime tool receipts as supporting evidence.

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

Internal audit under Clause 9.2 needs repeatable evidence assembly, and the evidence export with the receipt query API supplies it. Every local receipt read fails closed on a tenant boundary: pass --admin-all to read across all tenants as an administrative operation, or --tenant <id> to scope the read to one. The two flags conflict, and a read with neither is an error.

The walkthrough samples and exports from one saved time window. An ACP session certificate is a separate record for an ACP session store; a generic kernel run has no ACP session ID to supply. Retain the verified package and a completed review record for each audit, and verify the package before the audit relies on it.

Scope, data quality, and the review record stay with the operator

An assessor reviews these as the organization's own records, with Chio records attached where the tool boundary sees the activity.

1. The Statement of Applicability. Scope, applicability decisions, justifications, and accountable owners for each control.
2. Data quality and preparation. A.7.4 and A.7.6 run in the operator's data platform and preparation pipelines.
3. The SDLC for its own agents. Chio's build evidence covers Chio; A.6.2.3 evidence for the operator's agent and tool servers comes from its own pipeline.
4. Management review outputs. Compliance certificates summarize operational posture, and the written management-review minutes are the organization's record.

Next: confirm signer trust and checkpoint coverage for the audit