Documentation and traceability for the EU AI Act

Every package carries a reproduce.json manifest: the three seeds (data, split, weight initialisation), the three epoch counts — declared, capped, actually run— every artefact with its sha256, the environment (python, platform, packages, backend, device), and each metric tied to the digest of the dataset it was measured on. The schema travels too — field_types, field_ranges, excluded_identifiers — and where data came from a recipe the record says declared synthetic rather than passing it off as observed. For clinical work, matrixai report --tripod writes the TRIPOD+AI record (BMJ, 2024; 27 items) from what the run already recorded.

Annex IV documents a system; MatrixAI documents a model. The intended purpose, the hardware, the interface, the human oversight measures, the risk management system of Art. 9 and the monitoring plan of Art. 72 are yours to write — in a real Annex IV file, most of the pages. And the Digital Omnibus amended Art. 11(1) so that SMEs, start-ups and SMCs may supply the Annex IV elements in a simplified manner, on a form the Commission has to establish: a route through the paperwork, not around it.

MatrixAI records build-time and evaluation events. A receipt is emitted when something actually runs — a pipeline, an evaluation — and a simulation emits none and says why, because paper describing nothing reads as proof that something happened. Receipts can be signed, compared against one another, and re-checked by whoever receives them.

This is the article MatrixAI covers least, and that goes first rather than last. Art. 12 is about the deployed system logging its own operation, in production, over its lifetime. MatrixAI does not do that: its receipts describe how the model came to exist and how it scored on a fixed dataset, not what it did afterwards on live traffic. That logging is yours to build, and reading «receipts» as «logs» would be the most expensive misunderstanding available on this page.

The declaration in Art. 15(3) is the part with a real answer here. MatrixAI never publishes a metric without the digest of the data it was measured on, its direction and its tolerance — «94%» over which rows is a question the manifest answers and almost nobody publishes.

Before a single weight moves, six deterministic checks re-run on every change to the model: parser, verifier, safety, typecheck, compiler and backend contract. Once the package is built, matrixai verify rebuilds it and reports four stages separately: manifest (every artefact matches its declared digest, and nothing travels that the manifest does not name), R1 (the dataset rebuilt from the recipe has the declared sha256), training, and R3 (the fresh metrics fall inside their declared tolerance).

Accuracy is one third of the article. MatrixAI does not test adversarial robustness, does not attack your model, and does not assess the cybersecurity of the system you deploy it into. The digests prove that the weights that travel are the weights that were trained; they say nothing about whether the running system resists anybody. Worth knowing too: under the Digital Omnibus, Art. 42 now deems certain cybersecurity requirements satisfied through Regulation (EU) 2024/2847 — a route with nothing to do with this product.

Three views cover part of this shape. A registry in which an entry is never overwritten — publishing again creates a new version beside the old one, which keeps working for whoever was already using it — with a fingerprint per entry and a current tag moved by promotion and rollback. A continual policy that declares, before anything has drifted, the method and threshold per column, the window, the minimum samples and the metric a rollback would watch. And a drift view that keeps every check as history and says, per column, whether it drifted, did not, or was never measured because no method was declared for it — which is not a zero and is not «fine».

Those three views are not in the published Studio yet — not in the public demo, not in the package you can download today. They are documented in the lifecycle manual because they exist and run against the development build, not because they have shipped; until they do, count Article 72 as uncovered here. And even shipped, they are an instrument for a monitoring system, not the system and not the plan: the plan is a document a person writes and keeps inside the technical documentation.