What your client receives at AI handover.
A signed acceptance plan, a report linked to the agreed criteria, and a clear record of what was checked and what remains missing. This worked example shows the documents we assemble for one acceptance decision.
€3,000 fixed · One system · Up to three criteria · First draft within 3 working days of receiving your documents · details
1. The example at a glance
run_acceptance.py at seed 422. The four documents
Below is what each document says. The signed files, their signatures and seal records are in the repository.
Acceptance plan · AP-2026-001
Signed by the client’s decision owner (Head of Credit Risk, illustrative) and the supplier’s delivery lead (illustrative), then sealed. The signed plan was sealed before the run-start records were registered. Scope: one system version, one acceptance round. Any later change to a criterion, threshold, test data or configuration counts as a deviation and needs a new plan version, signed and sealed again; the earlier version stays in the record.
| ID | Metric | Pass if | Test data | Criteria record |
|---|---|---|---|---|
| C1 | Impact ratio for sex (female ÷ male selection rate) on the held-out split | ≥ 0.80 | UCI German Credit, stratified 70/30 split, seed 42 | 5ce3c9c3484d… |
| C2 | Accuracy on the held-out split | ≥ 0.70 | same | 464df2bee6b4… |
Rationale, written by the client’s decision owner (illustrative). C1: the system recommends credit decisions for natural persons; approval rates for women should not be substantially lower than for men. 0.80 is the four-fifths rule of thumb from bias-audit practice, not a legal standard, used as a floor for this round. C2: below 0.70 accuracy the recommendations would add more review work than they save. Falsify records this rationale and who approved it; it does not assess whether the metric or threshold is appropriate. Full text.
Acceptance report · AR-2026-001
| Criterion | Pass if | Observed | Result |
|---|---|---|---|
| C1 impact ratio (sex) | ≥ 0.80 | 0.857919 | PASS |
| C2 accuracy | ≥ 0.70 | 0.74 | PASS |
Deviations from the plan: none. Decision: accepted. Signed by the supplier’s test lead and the client’s decision owner (demo keys). A failing result would have been recorded exactly as it came out. The report is the parties’ document: Falsify sealed its hash and linked it to the plan and to the system version as the record identifies it, by the training script’s hash and the seed, without a hash of the trained model (section 3). Falsify does not certify its content. Full text.
Change and re-review conditions · CR-2026-001
| Situation | What was agreed |
|---|---|
| Retraining on refreshed data from the same pipeline | No new acceptance round, as long as C1 and C2 still pass on the sealed test split; the supplier sends the client the new results within 10 working days |
| New data source or input features, new model family or configuration, new business process or applicant population | A new acceptance round against the same sealed criteria, unless both sides sign a new plan version |
| Production impact ratio below 0.80 for two consecutive months, or more than 25% of recommendations overridden in a month | Re-review of the acceptance within 30 days |
A commercial agreement recorded at acceptance. Falsify records these conditions and does not monitor them. The agreement does not by itself make any change a “pre-determined change” under Article 43(4) of the AI Act. Full text.
Verification statement · VS-2026-001
Issued by Falsify OÜ. It lists the records by hash, the checks we performed and did not perform (section 4), and the gap we found (section 3). Registry receipts carry the registry’s technical signature; the statement itself is signed separately, here with a demo key. It was prepared with AI assistance and reviewed by Falsify OÜ. Full text.
3. A gap found during verification
4. What we checked, and what we did not
| Checks we performed | Checks we did not perform |
|---|---|
|
Criteria hashes, test-data bytes and verdicts from the results Run-final records chain to run-start and criteria records Two valid signatures on the plan, the report and the conditions Seal records list the exact bytes of every signed document Every registry hash recomputes from the files Every registry receipt signature (Ed25519) verifies Every RFC 3161 timestamp verifies The timestamps are in order: criteria, signed plan, run-start, run-final, report seal The report refers to the sealed plan and both criteria records by hash |
Whether the criteria are appropriate Whether the results are correct beyond recomputing the verdict Whether the tests ran after the plan (runner times are the supplier’s statement) Whether other plans or runs existed The identity of the signers (demo keys here) Transparency-log inclusion proofs A legal compliance assessment (section 5 shows where the record goes in the file) |
5. Where this record goes in an AI Act file
Had this system been put on the EU market, it would fall under Annex III, point 5(b) of the AI Act: systems “intended to be used to evaluate the creditworthiness of natural persons or establish their credit score”. The requirements and provider obligations for these systems apply from 2 December 2027. For them there is no outside assessor: the provider follows the internal-control procedure (Article 43(2), Annex VI), in which it “examines the information contained in the technical documentation” to assess compliance, and keeps that documentation for ten years for the national authorities (Article 18). The provider is whoever develops the system, or has it developed and puts it into service under its own name (Article 3(3)); in a delivery that is often the client. The acceptance record is built to go into that file.
| Document | Where it goes | What it supplies | What stays with the provider |
|---|---|---|---|
| Acceptance plan, signed and sealed | Art. 9(8): testing “against prior defined metrics and probabilistic thresholds” · Art. 17(1)(d): test and validation procedures · ISO/IEC 42001 A.6.2.4 | The metrics, thresholds, rationale and approvers, fixed and timestamped before the test runs were recorded | Whether the metrics are appropriate to the intended purpose (Annex IV, point 4) |
| Acceptance report, dated and signed | Annex IV, point 2(g): metrics for accuracy “as well as potentially discriminatory impacts”, and “test reports dated and signed by the responsible persons” | One dated, signed report per acceptance round, linked by hash to the plan, the criteria and the runs. C1 here is a discriminatory-impact metric | The testing itself and the test logs |
| Change and re-review conditions | Annex IV, point 6: “relevant changes made by the provider to the system through its lifecycle” | The agreed rule for which changes need a new acceptance round, and what triggers a re-review | The changes themselves, and any pre-determined change plan (Art. 43(4), Annex IV, point 2(f)) |
| Verification statement, links and timestamps | Art. 11(1): technical documentation · Art. 18(1): kept for ten years · ISO/IEC 42001 A.6.2.7 | What was checked and what was missing, and a way to show years later, offline, that the documents have not changed since they were sealed | Drawing up and keeping the rest of the documentation |
What only the provider can do. The provider draws up the EU declaration of conformity (Article 47) after the conformity assessment (Article 43). This record is evidence for that assessment, not the assessment, and nothing on this page says the example system complies. Risk management as a whole, data governance, human oversight, runtime logs and post-market monitoring are outside it. The full map, with the article texts, is in how PRML maps to the AI Act and ISO/IEC 42001; every Pack includes a one-page version for the client’s system. This is our reading of Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744, not legal advice.
6. The record, in the order it was made
Times are the registry’s receipt times (UTC). Each record also has an RFC 3161 timestamp from timestamp.sigstore.dev and an entry in the public Rekor transparency log. The signed plan was sealed before the run-start records were registered; the runner times inside those records are the supplier’s statement.
| Time | Step | Registry record | Rekor index |
|---|---|---|---|
| 11:50:23 | Criterion C1 recorded (impact ratio for sex ≥ 0.80) | 5ce3c9c3484d… | 122162600 |
| 11:50:27 | Criterion C2 recorded (accuracy ≥ 0.70) | 464df2bee6b4… | 122162688 |
| 11:50:42 | Acceptance plan signed by both sides and sealed | da55fc4ac5cc… | 122163063 |
| 11:51:18 | Test run declared against C1 (run-start record) | 14bc38f2bd35… | 122163511 |
| 11:51:21 | Test run declared against C2 (run-start record) | 231970705630… | 122163513 |
| 11:51:37 | C1 result recorded (run-final record) | 86c224c760c7… | 122163530 |
| 11:51:41 | C2 result recorded (run-final record) | 74415372626b… | 122163532 |
| 11:52:20 | Acceptance report and change conditions signed and sealed | 86f76e446db7… | 122164037 |
| 11:55:30 | Falsify verification statement signed and sealed | fbec1be1aa3a… | 122166615 |
7. Verify it yourself
- Clone github.com/studio-11-co/falsify and open
examples/acceptance-record/. - Run
./VERIFY.sh. It needs Python 3 with PyYAML, OpenSSL 3 (the LibreSSL shipped with macOS cannot verify these timestamp tokens) and OpenSSH 8 or later. No network is used. - Eight checks run: criteria and verdicts, linkage chains, document signatures, seal records, registry hashes, receipt signatures, RFC 3161 timestamps, and their order.
8. What this shows, and what it does not
- The criteria and the signed plan existed no later than 11:50:42 UTC on 23 September 2026 and have not changed since. The run-start records were registered after that, and the report was sealed after the run-final records.
- It does not show that the criteria are appropriate, that the results are correct, or that the tests ran after the plan.
- It does not show that no other plan or run existed. A reviewer can ask for the producer id (
acceptance-record-example.falsify) and look at its other records.
€3,000 fixed · One system · Up to three criteria · First draft within 3 working days of receiving your documents · details