PRML maps to EU AI Act, NIST AI RMF, and ISO/IEC 42001:2023.
A primitive does not relieve a provider of obligations. It supplies the cryptographic record those obligations name. This page documents — clause by clause — which named obligations PRML mechanically supports and which it explicitly does not.
Status. Working draft. Editorial position by the spec author. Not legal advice. Authoritative compliance determination is the responsibility of qualified legal counsel under the relevant jurisdiction.
The distinction matters when a reviewer outside the institution reads the file. External regulators, notified bodies, and class-action plaintiffs increasingly read “signature plus workflow” as attestation rather than proof. The cryptographic record is the version that survives that read. Same content, same fields, no new policy.
The failure mode this addresses is documented outside compliance literature as well. A 2026 review of 240 testing and evaluation practices for agentic systems in military command and control notes that “a recalibrated baseline can absorb slow degradation” and should therefore be “paired with a validated fixed reference” (arXiv:2608.20597, n.13 p.39). That paper means statistically validated, not cryptographically pinned, and it does not discuss pre-registration or PRML. The point it shares with this page is only that a reference which can be re-set quietly stops functioning as one.
1. EU AI Act — Regulation (EU) 2024/1689
Articles cited reference the consolidated text published in the Official Journal on 12 July 2024. General entry into force was 1 August 2024; high-risk obligations apply from 2 December 2027 (Article 113).
The closest fit is Annex IV §2(g), which requires the metrics used to measure accuracy and robustness to appear in the technical file; a PRML manifest is that record in serialised, hash-anchored form. The provisions below are listed in article order, and their fit varies — some direct, some partial. Each entry says which.
Separately from conformity, non-compliance with mandatory safety requirements in Union law now carries a consequence in litigation: under Article 10(2)(b) of the revised Product Liability Directive (EU) 2024/2853, transposed by 9 December 2026, it gives rise to a rebuttable presumption that the product was defective. The liability framing is set out on the insurance-readiness page.
Article 12 — Record-keeping (logging) · partial
Article 12 concerns automatic runtime logging. A PRML manifest is one record that can sit inside such a log; it is not the logging system, and the mapping is partial for that reason.
| Provision | PRML mechanism |
|---|---|
| 12(1) — automatic recording of events | YAML manifest emitted by training/eval pipeline; no human authoring required |
| 12(1) — tamper-evidence | SHA-256 over canonical bytes; any post-hoc edit breaks the hash |
| 12(2)(a) — identification of risk situations | Threshold + direction committed pre-run; threshold tampering becomes detectable |
| 12(2)(b) — post-market monitoring | Optional public anchor at registry.falsify.dev provides stable URL + re-derivable hash |
| 12(2)(c) — monitoring of operation | Not addressed. Operational monitoring is a runtime function; a pre-run manifest records the bar, not the operation |
Article 17 — Quality management system
The PRML manifest format is itself a documented procedure within the meaning of Article 17(1)(d). Conformity claim: a provider that emits PRML manifests for high-risk evaluations satisfies the format portion of QMS documentation; the review and approval portion remains a separate organisational obligation.
Articles 25(2) and 75a — New in Regulation (EU) 2026/1744
The Digital Omnibus on AI (Regulation (EU) 2026/1744, in force 27 July 2026) adds two duties that reward tamper-evident evaluation records. Under the amended Article 25(2), an initial provider whose high-risk system is taken over by another provider must hand over technical documentation, documented known limitations and failure modes, and targeted technical access for testing and validation — a breach is now fineable under Article 99(4). Under the new Article 75a(6)(b), the AI Office can order operators to retain all data and documents needed to assess compliance. A pre-registered manifest with an independent timestamp is a record that survives both events without argument about when it was written. The hand-over duty has its own explainer: the Article 25(2) hand-over pack.
Article 18 — Documentation keeping
PRML manifests are content-addressed via SHA-256 and are durable for the spec's intended lifetime regardless of registry availability — the canonical bytes plus the hash function are sufficient for re-derivation. This supports the 10-year retention requirement under Article 18(1): the hash makes archived evidence independently re-verifiable by any party, but retention itself still requires the bytes to be stored — export the pack and archive it in your own document store.
Article 50 — Transparency obligations
Article 50(1) requires that natural persons interacting with an AI system are informed of that fact when not otherwise apparent. In application since 2 August 2026 — the date the AI Office and national authorities also began enforcement, with the Article 85 complaint tool live. PRML does not address this obligation directly but provides the cryptographic anchor for any public claim made about the system's behaviour, which 50(1) disclosures may reference.
Article 72 — Post-market monitoring
| Provision | PRML mechanism |
|---|---|
| 72(1) — systematic data collection | Each evaluation event produces a manifest + hash; chronological log emerges naturally |
| 72(3) — post-market monitoring plan | The set of pre-registered manifests is the plan, made cryptographically binding |
Article 73 — Reporting of serious incidents
When a serious incident occurs, the provider must report under 73(1)–(3). PRML supports incident reporting by providing cryptographic citations to the pre-incident evaluation manifests — competent authorities can re-derive the hash and verify what the provider committed to before the incident, independent of the provider's word.
Annex IV — Technical documentation
Annex IV §2(g) requires "the metrics used to measure accuracy, robustness, cybersecurity and compliance with other relevant requirements." PRML manifests are those metrics in serialised, hash-anchored form. Annex IV §3 (testing) is supported when each test cycle emits a manifest.
Full article-by-article worked example with a hypothetical Annex III system is in the spec repository at github.com/studio-11-co/falsify/blob/main/spec/compliance/AI-Act-mapping-v0.1.md.
2. NIST AI Risk Management Framework v1.0
Cross-mapping to NIST AI RMF v1.0 (NIST AI 100-1, January 2023) functions and categories. PRML primarily supports Govern (documentation infrastructure) and Measure (validation evidence).
| Function · Category | PRML alignment |
|---|---|
| Govern.1.5 | "Ongoing monitoring and periodic review of the risk management process and its outcomes are planned" — the manifest set is the planned monitoring artefact |
| Govern.5.2 | "Mechanisms are established to enable AI system end-users and operators to provide feedback on... potential bugs and risks" — registry permalinks are stable and shareable |
| Measure.1.1 | "Approaches and metrics for measurement of AI risks... are selected" — manifest's metric + threshold + threshold_direction fields commit selection pre-run |
| Measure.1.3 | "Internal experts who did not serve as front-line developers... are involved in regular assessments" — independent verifiers re-derive the hash without coordinating with developers |
| Measure.2.4 | "Performance is documented and disseminated" — README badges from registry.falsify.dev embed re-derivable receipts |
| Measure.2.13 | "Effectiveness of the [model] performance and trustworthiness characteristics... are documented" — pre-registered claim is the documentation |
The Map and Manage functions are organisational and not directly addressed by a serialisation primitive. PRML supplies evidence; an organisation supplies governance.
3. ISO/IEC 42001:2023 — AI Management System
Cross-mapping to selected clauses of ISO/IEC 42001:2023 (AIMS — Artificial Intelligence Management System). PRML primarily supports documented information obligations under clause 7.5 and operational planning and control under clause 8.
| Clause | PRML alignment |
|---|---|
| 7.5.1 — General | Manifest is the prescribed form of documented information for evaluation claims |
| 7.5.2 — Creating and updating | Manifest creation is automated; updates produce new manifests with fresh pre_registered timestamps (forward-only chain) |
| 7.5.3 — Control of documented information | SHA-256 anchor + optional public registry provides distribution control and integrity |
| 8.1 — Operational planning and control | Pre-registered manifests are the operational plan in cryptographically binding form |
| 9.1 — Monitoring, measurement, analysis, and evaluation | Each measurement cycle emits a manifest; the set of manifests is the measurement record |
| A.6.2.4 — System verification and validation | Manifests anchor what was verified and how; re-running against the manifest's threshold is the validation step |
| A.6.2.6 — System operation and monitoring | Registry permalinks support continuous monitoring artefacts |
4. Standards-body input status
PRML v0.1 has been submitted as an open, non-proprietary primitive to the following bodies. The spec is licensed under CC BY 4.0 and accompanied by an irrevocable, royalty-free patent non-assertion grant; reference implementations are MIT.
| Body | Status | Date |
|---|---|---|
| CEN-CENELEC JTC 21 | Comment paper submitted (jtc21@din.de · WG2) | next input scheduled for the v0.3 cycle |
| UK AISI (Inspect AI) | Schema interop discussion (GitHub) | next input scheduled for the v0.3 cycle |
| ISO/IEC SC 42 | v0.2 frozen 2026-05-22; formal input follows the v0.3 cycle | 2026 Q3 |
| NIST AISIC | Engagement runs through formal comment windows on published drafts | per call |
v0.2 RFC was frozen on 2026-05-22 (comment window closed) at spec.falsify.dev/v0.2-rfc. The frozen draft is published for review at the link above.
5. Intellectual property posture
The spec, all reference implementations, and the patent non-assertion grant are designed to satisfy the procedural requirements of standards bodies that require non-proprietary, royalty-free primitives.
| Artefact | License |
|---|---|
| PRML v0.1 specification | CC BY 4.0 |
| Reference implementations (Python, JS, Go, Rust) | MIT |
| Conformance vectors (13 v0.1 + 8 v0.2) | CC BY 4.0 |
| Patent non-assertion grant | Worldwide, royalty-free, irrevocable |
| This compliance document | CC BY 4.0 |
The patent grant covers (a) the manifest schema, (b) the canonical byte serialisation algorithm, (c) the registry anchor protocol, and (d) any combination thereof, for any conforming implementation. Termination occurs only if a grantee asserts patents against any conforming PRML implementation. Full text in the spec appendix.
For compliance leads — what to do next
If your organisation is preparing for Article 12 logging or equivalent obligations under another framework:
- Review the v0.1 spec. 15 pages, plain English, no jargon. spec.falsify.dev/v0.1
- Review v0.2 RFC. Five proposals, comment window closed 2026-05-22. spec.falsify.dev/v0.2-rfc
- Pilot one published claim. Write a manifest, hash it, anchor it via the registry. ~20 minutes, no commitment.
- Open a discussion if the spec doesn't fit your obligation set. github.com/studio-11-co/falsify/discussions
Further reading: Model cards vs pre-registration: what counts as evidence under the EU AI Act · PRML cookbook patterns.
This document is an editorial position by the spec author. It is not legal advice. Compliance determination is the responsibility of qualified legal counsel and competent authorities under the relevant jurisdiction. The author makes no warranty regarding the regulatory acceptance of PRML manifests by any specific authority. Citations are to publicly available regulatory texts as of 2026-05-09.