Compliance documentation is one of the most consistently expensive workstreams in regulated EA practice. The pattern is familiar: every quarter, an architect (or several) spends two to three weeks hunting through Confluence pages, integration specs, validation reports, and access-control matrices, then assembling a coherent narrative across systems that almost certainly weren't designed with that narrative in mind. The result is usually stale by the time it's printed.

It doesn't have to be. When your architecture lives as a structured model rather than as scattered documents, a compliance report becomes a projection of that model through a regulatory framework — a query, not a writeup. This post walks through what that projection looks like in practice for 21 CFR Part 11, what makes it possible, and where human judgment still has to be in the loop.

~30 sec

for the projection. Hours, not weeks, to validate the output.

What 21 CFR Part 11 actually demands

If you've never worked under 21 CFR Part 11, here's the short version. It's the FDA regulation that governs electronic records and electronic signatures in pharma, biotech, and medical devices. It applies to any system that holds GxP-relevant data — manufacturing records, clinical trial data, laboratory information systems, batch records, the whole pipeline.

The regulation has specific architectural requirements:

Audit trails. Every change to a GxP record must be captured with who, what, when, and why. The audit trail itself must be immutable and reviewable.
Access controls. Only authorized individuals can access electronic records, with role-based segregation enforced at the system level.
Validation. Every system in scope must have documented evidence that it does what it's supposed to do — installation qualification, operational qualification, performance qualification.
Electronic signatures. Where signatures are required, they must be linked to specific individuals, non-repudiable, and tied to the record in a way that prevents tampering.

What this means in practice is that any system architecture under 21 CFR Part 11 needs documentation that traces, for every application and integration point, what the regulation requires, whether the architecture satisfies it, and where the evidence lives. That documentation has to be current, defensible, and produceable on demand for an FDA inspector.

The traditional version of this is a three-week project per quarter that's already stale by the time it's printed.

What a model-driven compliance projection produces

The output document, when you project an ArchiMate-modeled architecture through a 21 CFR Part 11 framework, falls into five sections — each grounded in specific model elements rather than free-text generation.

Architecture decisions log

Every architectural decision in the model — captured as a decision record with rationale, alternatives considered, owner, and date — extracted and presented in chronological order. The decisions come from the model's decision elements, which auto-discovery populates from architecture decision records (ADRs), design documents, and meeting notes in the source material. Where a decision rationale can't be found in the source, the projection flags the gap rather than inventing one.

Integration risk assessment per touchpoint

For each integration point, the projection assesses: what data crosses this boundary (PII, GxP, financial, operational), who owns each side of the integration, what authentication and authorization controls are in place, what audit logging exists, and what residual risk remains. The risk levels derive from the model's actual properties, not guesses. Where data classifications are missing, the touchpoint is flagged as "classification unknown — requires review" rather than assuming a level.

Technology infrastructure compliance flags

This is the section that surfaces the most surprises. The projection looks at every technology component in the model, cross-references what's running on it (applications and data objects, traced through the application and business layers), and flags compliance gaps: an end-of-life OS hosting a GxP-relevant application, a database without documented backup verification, a cloud region in a jurisdiction that hasn't been approved for GxP data. Each flag links to the model element and the regulatory clause that triggered it.

Audit trail summary

A summary of what audit-trail mechanisms each system has, with gaps highlighted. The model doesn't need to have the audit-trail data itself — only the documented description of what each system implements. The projection compares that documentation against the regulatory requirement and identifies systems where the documented audit mechanism doesn't meet 21 CFR Part 11's "complete, secure, computer-generated, time-stamped" standard.

Suggested remediation for flagged risks

For each flag, a specific remediation proposal: upgrade an EOL OS, document the backup verification protocol for a flagged database, complete the data residency assessment for a flagged cloud region. The suggestions are grounded in the model — which applications depend on each component, what scope a remediation would touch.

The output isn't perfect. Expect to spend time on the cases where the model's documented owner has changed and the projection flags an "owner discrepancy detected, verify." That's the kind of correction that takes a human five minutes per item. The majority of touchpoints, in a well-maintained model, will be clean.

Why this works

The obvious next question is: "couldn't I just point an LLM at our Confluence pages and get the same result?" No, and here's why.

The approach isn't free-text generation against documentation. It's structured reasoning against an architecture model — a formal representation of the systems, their relationships, their properties, their compliance metadata. The model is the substrate. The AI renders the substrate into the document the regulator wants.

Three things specifically:

The model has the metadata.

Each application component carries properties: data classification, regulatory scope, owner, last-validated date, validation status. These properties exist because auto-discovery extracted them from source documents and structured them. The projection doesn't guess data classifications — it reads them off the model.

The relationships are typed.

When the projection traces a data flow, it knows whether the relationship is "uses," "realizes," "implements," or "flows to" — those are different semantically and they affect the compliance analysis. A typed relationship is much stronger evidence than a free-text mention.

The reasoning is bidirectional.

For each regulatory clause, the projection traces from the clause to the applications affected (forward), or from any application to the clauses that constrain it (backward). That bidirectional traversal is what makes "find every component affected by this regulation" a half-minute query instead of a three-week project.

The compliance report isn't generated. It's projected — from the structured model, through the regulatory framework, into the document format the regulator expects. That's a fundamentally different operation than asking an LLM to write a compliance report.

What this changes for regulated organizations

If you're working under 21 CFR Part 11, FDA 21 CFR Part 820, EU GMP Annex 11, GDPR, SOX, PCI-DSS, or any other regulatory framework that imposes architectural requirements, the implications are significant:

Compliance documentation becomes a continuous output rather than a periodic project. When the model is current, the documentation is current. When the model changes, the documentation regenerates. No "annual refresh project" required.
Audit preparation collapses from weeks to hours. When an inspector asks for evidence, the report is generated on the spot. No more "we'll have that ready by Thursday."
Compliance gaps surface continuously. The flagged risks have usually existed in the architecture for months before anyone runs the analysis. With this approach the analysis runs every time the model changes.
The architect's time moves up the value chain. Instead of spending weeks per quarter producing compliance documents, architects spend that time designing, deciding, and reviewing. The compliance documentation becomes a byproduct of architecture work, not a separate workstream.

What this doesn't change

The boundaries here matter:

The projection doesn't make compliance decisions. When it flags a risk, a human still has to decide what to do about it. When the documented data classification on a system is wrong, a human has to correct the model — the projection can flag the inconsistency but can't fix the underlying data.

It doesn't validate the systems either. It documents the architecture's compliance posture based on what's in the model. The qualification work — IQ/OQ/PQ for new systems, periodic revalidation for existing ones — is a separate workstream that lives outside the architecture model.

And it doesn't substitute for QA judgment. A regulatory audit isn't just about producing documents. It's about demonstrating that your organization understands what the regulation requires and has implemented controls accordingly. The documents help, but the underlying controls — and the people who run them — are what actually satisfy the regulator.

Try it

If you're working in a regulated environment and this resonates, early access is open. We're particularly interested in talking to teams working under 21 CFR Part 11, Annex 11, and Part 820 — those are the frameworks the projection covers first. We're expanding the framework coverage continuously; if you operate under a regulatory regime we don't yet cover, tell us — that's exactly the kind of feedback that drives the roadmap.

Compliance documentation shouldn't be a project. It should be a byproduct of doing architecture well.