ISO/IEC 42001:2023 crosswalk for PRML — clause-by-clause evidence map
ISO/IEC 42001:2023 is the first ISO management-system standard scoped specifically to artificial intelligence. Like ISO 27001 for information security, it specifies the structure of an AI Management System (AIMS) and the documented evidence that audit will ask to see. Pre-Registered ML Manifests don't replace the AIMS — they make the evaluation-evidence layer arithmetically verifiable instead of attested.
Scope and posture
PRML (v0.1 spec, Zenodo DOI 10.5281/zenodo.20177839) is an open content-addressed format that binds an evaluation claim — metric, comparator, threshold, dataset hash, seed, producer identity — to a SHA-256 hash before the experiment runs. Any retroactive edit breaks the hash. The reference implementations are byte-equivalent across Python, JavaScript, Go, and Rust against 20 conformance vectors.
This is a primitive, not a programme. ISO/IEC 42001 asks an organisation to establish, document, operate, monitor, and continually improve an AIMS. PRML is the artefact format inside Clauses 7 (Support — documented information), 8 (Operation), 9 (Performance evaluation), and Annex A control A.6.2.4 (Validation and verification). It does not, on its own, satisfy the leadership, policy, planning, or improvement clauses.
The three coverage tags used below:
- FULL — the clause is mechanically satisfied by a PRML manifest plus the registry / CI pattern. The manifest is the documented evidence the auditor will request.
- PARTIAL — PRML supplies a binding piece of evidence the clause requires, but supporting documentation (policies, role descriptions, training records) is also needed.
- NONE — PRML does not address this clause. Listed only where it would be reasonable to mistake it for in-scope; the leadership and improvement clauses are mostly omitted to keep the table readable.
Clause 7 — Support (documented information)
| Clause | Text (paraphrased) | PRML mechanism | Coverage |
|---|---|---|---|
| 7.5.1 | The AIMS shall include documented information required by this standard and determined by the organisation as necessary for effectiveness. | The manifest is required documented information for the evaluation-decision step. SHA-256 makes it tamper-evident across the system's lifetime, which most policy-text alternatives are not. | Full |
| 7.5.2 | Documented information shall be appropriately identified, described, and reviewed and approved for suitability. | The manifest carries producer.id (accountability), created_at (identification), and claim_id (description). The lock step is the approval gate. |
Full |
| 7.5.3 | Documented information shall be controlled to ensure it is available, suitably protected, and retained in a way that preserves its integrity. | SHA-256 over the canonical bytes is the integrity preservation mechanism. Any retroactive edit breaks the hash; the registry permalink and reference implementations make the integrity check independent of the producer. | Full |
Clause 8 — Operation
| Clause | Text (paraphrased) | PRML mechanism | Coverage |
|---|---|---|---|
| 8.1 | Operational planning and control: the organisation shall plan, implement, and control processes needed to meet AIMS requirements, including criteria for the processes. | The locked manifest is the operational record of one such criterion (the evaluation threshold) being committed before the process executes. | Partial |
| 8.2 | AI risk assessment: the organisation shall perform AI risk assessments at planned intervals. | PRML doesn't perform risk assessment, but the prior_hash amendment chain is the assessment-cadence evidence — each scheduled re-evaluation produces a forward-only link with a reason field. |
Partial |
| 8.3 | AI risk treatment: the organisation shall implement the AI risk treatment plan and retain documented information. | The manifest is the documented information for the evaluation-risk-treatment step. The treatment (the threshold itself) is committed before the run; the chain documents subsequent treatments. | Partial |
| 8.4 | AI system impact assessment: the organisation shall assess the potential consequences of the AI system in its intended context. | PRML does not perform impact assessment. It does, however, provide the evidence layer the impact-assessment report can point at when claiming "we evaluated for X with threshold Y on dataset Z, sample size N, before deployment." | Partial |
Clause 9 — Performance evaluation
| Clause | Text (paraphrased) | PRML mechanism | Coverage |
|---|---|---|---|
| 9.1 | Monitoring, measurement, analysis, and evaluation: the organisation shall determine what needs to be monitored, the methods, when to perform it, and when to analyse results. | metric + comparator + threshold + dataset.hash together define exactly that. The lock timestamp answers "when committed"; the run timestamp answers "when measured". |
Full |
| 9.2 | Internal audit: the organisation shall conduct internal audits at planned intervals to provide information on whether the AIMS conforms. | An auditor with the manifest + sidecar + a reference implementation can re-derive the SHA-256 offline. No vendor runtime, no producer trust. The verification artefact is content-addressed across decades. | Full |
| 9.3 | Management review: top management shall review the AIMS at planned intervals. | The chain's terminal hash is a single 32-byte summary that compresses the full evaluation history. Management review can verify "did we hold our thresholds across the year" arithmetically rather than narratively. | Partial |
Annex A controls (selected)
ISO/IEC 42001 Annex A lists reference controls organisations choose from when treating AI risks. PRML lands cleanly on a handful:
| Control | Text (paraphrased) | PRML mechanism | Coverage |
|---|---|---|---|
| A.6.2.4 | Validation and verification of AI systems: documented procedures for V&V activities throughout the AI lifecycle. | The manifest format is the documented V&V procedure for the evaluation-claim layer. The four reference implementations make the procedure portable across stacks. | Full |
| A.6.2.6 | AI system deployment: documented criteria for deployment readiness. | A locked manifest with a passing verdict is exactly that — a deployment-readiness gate that fails closed (exit 10) if the threshold isn't met. |
Full |
| A.6.2.8 | AI system performance: documented procedures for monitoring and maintaining performance after deployment. | The amendment chain records each post-deployment re-evaluation with prior_hash and reason. The auditor reads a single forward-only chain. |
Full |
| A.7.4 | Data quality for AI systems: documented information about data sources, quality criteria, and provenance. | Manifest dataset.id + dataset.hash bind evaluation to specific dataset content. Any swap fails verification. |
Full |
| A.9.3 | Objectives for the responsible use of AI: criteria documented and traceable to outcomes. | The threshold in a manifest is exactly such a documented criterion, and the SHA-256 makes it traceable across the system's lifetime. | Partial |
What this map does not give you
Honest read: of ISO/IEC 42001's 10 main clauses and 38 Annex A controls, PRML contributes evidence to roughly 10–12 items. The standard is overwhelmingly process and governance — leadership commitment, AI policy text, role definitions, competence records, communication procedures, incident handling, supplier relationship management. PRML is the small primitive that makes the evaluation-evidence layer arithmetically verifiable. That layer happens to be where AIMS audit interviews most often pivot from "show me the policy" to "show me the evidence," which is why naming it specifically matters.
If your AIMS programme is being built or audited against ISO/IEC 42001 right now, the marginal value of PRML is highest at clauses 7.5.1, 7.5.2, 7.5.3 (documented information), 9.1 and 9.2 (monitoring and internal audit), and Annex A controls A.6.2.4, A.6.2.6, A.6.2.8, A.7.4 (V&V, deployment, performance, data). Those nine items are where attested process work tends to collapse under interrogation, and where a deterministic hash is a cleaner artefact than any procedure document.
Pairing PRML with the rest of the standard
ISO/IEC 42001 expects an integrated management system. PRML doesn't replace any of that. What it does is give the relevant clauses a content-addressed artefact to point at. A policy that says "Evaluation claims for production AI systems shall be pre-registered via PRML before release, with the manifest hash retained as documented information per 7.5.3" is a one-sentence policy that an auditor can verify by re-deriving the hash. A policy that says "Evaluation claims shall be documented in accordance with internal procedures" is verifiable only by reading whatever procedure document the team produced, which is the gap ISO keeps trying to close with the documented-information clauses.
Pair the manifest with the rest of the programme:
- Use PRML for the evaluation-evidence artefact layer.
- Use ISO/IEC 42001 for the management-system structure that surrounds it.
- Use the EU AI Act Article 12 pattern for the EU regulatory layer (Article 18 retention is satisfied by plain UTF-8 storage of the manifests).
- Use the NIST AI RMF subcategory map for the U.S. voluntary-standard layer (MEASURE function overlaps substantially with Clause 9).
- Use Sigstore or similar attestation for execution-integrity beyond what PRML §8.1 covers.
Pre-register your first evaluation claim. Paste a PRML draft into registry.falsify.dev and get a SHA-256 permalink plus a README badge. No account, no server-side state beyond the hash. The reference implementations are at github.com/studio-11-co/falsify (Python, byte-equivalent JS / Go / Rust in sibling repos).