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.
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 August 2026 (Article 113).
Article 12 — Record-keeping (logging)
| 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 | Registry permalinks support badge-embedded receipts on model cards and reports |
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.
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 satisfies the 10-year retention requirement under Article 18(1) without depending on Studio 11 infrastructure.
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. 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 ([email protected] · WG2) | 2026-05-15 (planned) |
| UK AISI (Inspect AI) | Schema interop discussion (GitHub) | 2026-05-12 (planned) |
| ISO/IEC SC 42 | Awaiting v0.2 freeze before formal input | 2026 Q3 |
| NIST AISIC | Reachable via working group; no formal request yet | — |
v0.2 RFC is open for community comment until 2026-05-22 23:59 UTC at spec.falsify.dev/v0.2-rfc. Comments from compliance leads at high-risk AI providers are particularly welcome — your concerns shape the freeze.
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 (12 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 open through 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
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. Studio 11 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.