AI Act readiness, vendor-neutral.
An open spec and a CLI your audit practice can include in client deliverables without lock-in.
Falsify publishes PRML, a Community Specification License 1.0-licensed specification for pre-registered machine-learning evaluation manifests, plus four MIT-licensed reference implementations that agree byte-for-byte on the published conformance vectors. It is the layer your AI Act readiness engagements can deploy inside the client environment, cite in the final report, and leave behind for the regulator — without buying SaaS licenses, without naming a vendor, without your team writing the standard from scratch.
First engagement: the Acceptance Evidence Pack, €3,000 fixed — one real evaluation’s acceptance criteria from a client engagement, independently timestamped, linked to the test runs, with an offline verification bundle you and your client keep. Scope and terms →
01The problem this solves
A client retains your practice for AI Act readiness. They want evidence aligned to Article 12 (automatic logging), Article 17 (quality management), and Article 18 (ten-year retention). Often a high-risk Annex III system. What the client hands you is a set of results; what an opinion needs is the rule those results were measured against, and across 29 published assurance engagements a reader can recover that rule in three.
You build a custom deliverable each time. Then the client’s general counsel asks the question that matters: is this published somewhere we can cite, and can anyone outside this room verify it? If the template was authored inside your firm for this engagement, the answer is no. If you cite a proprietary tool, the answer becomes a procurement conversation you did not want.
PRML is a published specification with a Zenodo DOI, a Community Specification License 1.0, four reference implementations that produce byte-equivalent output on the published conformance vectors, and an Article 12 / 17 / 18 / 50 / 72 / 73 crosswalk under public review. Your deliverable cites the spec. The artifacts are reproducible offline by the notified body. No proprietary tooling enters the client’s environment.
02What audit firms get
- A1A citable specification for Article 12 logging evidence patterns, with a clause-by-clause AI Act crosswalk already drafted for legal review.
- A2A reference CLI you ship into client environments: MIT-licensed Python, a single runtime dependency (PyYAML).
- A3A public conformance vector suite (21 locked vectors across four language implementations) for assurance and second-opinion work.
- A4A GitHub Action and an MLflow plugin so client CI/CD pipelines can verify manifests at build time without bespoke integration.
- A5No mandatory vendor dependency. Clients verify SHA-256 hashes offline against any reference implementation; nothing phones home and using the standard never requires a Falsify account. Managed retention and organisational controls are available separately for teams that want them.
03Where the line sits
- PRML is designed to complement existing audit practices rather than compete with them. The conformity assessment market is yours; the evidence layer underneath it is what we build.
- The standard is the deliverable, not a dashboard. Clients verify everything offline, forever, with no licence required. Managed retention and written engagements exist separately for teams that want them; see /pricing.
- PRML remains an independently attributable open specification: Community Specification License 1.0, editorially maintained, named in your report rather than white-labelled into it. That is what lets you cite it as a methodology instead of a supplier.
04How an audit engagement can use PRML
- During client discovery, identify which Article 12, 17, and 18 evidence the client currently cannot produce for in-scope ML evaluation claims.
- Lock a PRML manifest for each in-scope claim during the engagement — metric, comparator, threshold, dataset hash, seed, producer identity — bound to a single SHA-256.
- Verify with the CLI (
falsify verify) before the regulator does. Exit codes are deterministic: 0 PASS, 10 FAIL, 3 TAMPERED, 11 GUARD. - Cite the specification (
spec.falsify.dev/v0.1) and the Zenodo DOI in your final report’s technical-documentation appendix. - Hand the manifest hashes and chain hash to the client for ongoing CI integration and post-market monitoring under Article 72.
The full Article-by-article mapping, with coverage scoring per obligation and open legal questions, is at spec/compliance/AI-Act-mapping-v0.2.md. v0.1 is the current published version and the one to implement against; the specification itself remains a working draft open for public review. Substantive comments on the clause-level bindings are welcome via GitHub issues.
05Partnership
Placement is earned, never bought: we neither pay for it nor accept payment for it. We publish a Featured implementers page for firms that contribute back: a notified-body case study, a clause-level mapping document against your existing methodology, or a written RFC-quality comment (the v0.2 window closed 2026-05-22; comments roll into the v0.3 cycle). Anything that improves the spec is in scope. Anything that brands the spec is not.
Write to [email protected] with subject prefix [AUDIT-FIRM] and one written question. Expect a written response within two working days. Prefer to talk first? Say so in the email and we will find 20 minutes; anything agreed on a call is confirmed in writing the same day.