The fundamental unit turns out not to be the document but the claim: an assertion made by someone, evidenced by something, evaluated by a named person, valid until a date, and then expired, challenged, or withdrawn. "This plywood is free from SVHC substances above 0.1 weight per cent" is a claim. So is a Declaration of Conformity, a laboratory accreditation, and an operator's training certificate. Model the claim lifecycle and compliance becomes navigable rather than archival.

Why Nick. Structured content, workflows, granular permissions, versioning, relations, search, and a mature security model are most of what a compliance system needs, and Plone has had them for twenty years. Nick carries that forward with a REST API and a content model that made it realistic for one person to build this: roughly eighty per cent of the required infrastructure was already there. What I have added sits on top — the claim and evidence types, the traceability links, and an approach of serving structured PostgreSQL data through Nick's API as browsable content rather than leaving it behind psql.

It is not a proposal on a whiteboard. The framework has been governing its own construction for the past year — the project's own development is its first compliance case, its architecture decisions are claims with evidence and evaluation, and its session documentation is the audit trail. The process is the product. The corpus holds 2,799 controlled documents: 272 design records, 233 bug records, 18 corrective and preventive actions, 11 standard operating procedures, 13 policies, quality audits, security audits, and a cybersecurity file, with document control and change control enforced in the database rather than requested in a style guide. The regulated anchors are real: ISO 14971, IEC 62304, EU IVDR, and a predetermined change control plan.

Privacy is not a feature of this system. It is the reason anyone would use it. Compliance data is where an organisation keeps its fines, its failures, and its workarounds. Nobody wants that pooled in a shared repository. So the platform is designed for parties who do not fully trust each other: it holds the complete picture while no single participant sees everything, and visibility is determined by relationship and role rather than by folder. The audit trail is complete and immutable; access to it is not uniform. Without that property the system has no users, however good its data model.

Sovereignty decides the architecture, not the marketing. Consider a CNC machine built in one country and operated in another. The operator's training certificate is personal data and stays in the EU. The manufacturer's proprietary specifications stay where they were made, under a different regime. The compliance question — is this operator trained to use this machine? — crosses the boundary as a validated token, not as data. The employer never sends personal data abroad; the manufacturer never sends specifications back. That is not one database with careful permissions. It is a federation, and deciding it late is not possible.

The same reasoning runs all the way down. The language models used in this project run on local hardware and never on the production server, because enabling AI endpoints on a regulated system is a significant change requiring security re-audit and notified-body notification. Source control is self-hosted inside the EU, because repositories holding compliance records and audit findings are themselves regulated material. Sovereignty is not a slide at the end of the deck; it is why the compute sits where it sits.

Working with an AI as a team member, held to the same standard as one. The governing principle is that AI is subject to the same discipline as a human developer: everything auditable, every change documented before deployment. Making that real required treating the assistant's own failures as nonconformities. There are 59 recorded AI procedural violations — each an occasion where the assistant skipped a required read, acted on an unverified assumption, or bypassed a control — written up with root cause and preventive action exactly as any other deviation would be, and eighteen corrective and preventive actions raised behind them, several tracking recurring failure classes. The instruction file governing the collaboration is long, and every clause in it is traceable to a specific incident, because an AI's memory is whatever someone wrote down for it. If you intend to put AI anywhere near a regulated process, this is the mechanism I would argue you need — not better prompts.

The modelling decisions, and what they cost. When a legal text should be stored, referenced, or decomposed into individual requirements. How to keep a policy, a procedure, a control, a risk, and a piece of evidence genuinely distinct when every user wants to file everything as "a document". How to maintain traceability without an interface only its author can operate. How to represent overlapping national law, EU regulation, standards, and internal requirements without duplication. How to support several languages without growing separate compliance systems that quietly diverge. And how to design workflows around organisational responsibility rather than document status.

Examples are drawn from occupational safety, manufacturing, quality management, and regulated operations — including a furniture producer whose single product required compliance evidence assembled from more than a dozen suppliers across four countries, and an importer fined by the national safety authority for a machine that arrived without CE marking, who then became the legal manufacturer of the machine they had bought.

What attendees will take away: why compliance is a connected-information problem rather than a document-storage problem; the claim as a modelling primitive; which parts Nick already gives you and which you must build; why privacy and jurisdiction constrain the architecture from the first day rather than the last; where AI genuinely helps with regulatory analysis and what has to be in place before it is allowed near the work; and why maintainability and sovereignty are compliance requirements rather than preferences.

This is a progress report, not a solved problem. The user-experience layer is the least finished part, and the questions I would most like to put to this community are the ones I have not answered.