Architecture & Methodology
The regulatory reasoning, architectural decisions, and methodological choices behind every component of the engine — documented for evaluators, collaborators, and the regulated industry professionals who need to understand what they’re trusting.
01 — The System Type Taxonomy
The 40 system types were derived from first principles: what categories of regulated system exist, and what makes each one materially different from a validation governance standpoint?
The starting point was the regulatory framework landscape. Seven primary GxP frameworks define the regulated operational environment: FDA 21 CFR Part 11, EU Annex 11, ICH Q10, GCP, GLP, GDP, and GMP. Each framework implies different categories of system, different criticality profiles, and different validation requirements.
Within those frameworks, system types were differentiated by four factors:
Determines Part 11 / Annex 11 applicability and the audit trail requirement profile.
Determines GMP, GCP, GLP, or GDP applicability and the criticality tier.
Determines the proportional validation approach under CSA / GAMP 5 risk principles.
Vendor configuration vs. site-specific configuration changes the validation strategy structurally — not just in degree.
The result is 40 types — enough to distinguish materially different governance requirements, not so many that the taxonomy becomes unmaintainable. Examples of the distinctions that matter:
Both GLP-adjacent. Different criticality profiles and Part 11 applicability warrant separate types and separate template sets.
Both GMP/GDP. Part 11 exposure and qualification approach are structurally different despite operational overlap.
Both GCP. CTMS governs trial logistics; EDC governs data capture with direct regulatory submission implications.
Both GMP manufacturing. MES governs execution; Historian governs data retention. Different Annex 11 section profiles.
02 — The 791 Templates
791 is not a round number for a reason. It is the current count of requirement statements that have been derived from specific regulatory provisions and mapped to one or more system types.
A template is not a best practice statement. It is a requirement with a traceable regulatory basis and an evidence base in the inspection history of the domain.
The derivation methodology for each template:
The actual CFR section, Annex paragraph, or ICH guideline text — not a summary or secondary source.
Not the text itself, but the governance requirement the text creates. “Audit trails shall be computer-generated” → requirement for audit trail architecture, completeness, and review evidence.
Determine which of the 40 types the obligation applies to and at what criticality weight.
Cross-reference against published FDA Warning Letters, 483 observations, and EMA inspection findings in the same domain to confirm the requirement is actively enforced.
Example derivation paths:
“Secure, computer-generated, time-stamped audit trails” → multiple templates covering audit trail configuration, completeness, and review evidence. Applied to all Part 11-applicable types.
More specific than FDA equivalent — requires all GMP-relevant changes and deletions be captured → distinct template set for Annex 11 systems beyond the CFR baseline.
Change management obligations → process templates for change control integration, applied particularly to systems managing quality records across their lifecycle.
Periodic evaluation requirement → lifecycle review templates that exist in Annex 11 systems but not in pure Part 11 systems — a structural difference between the two frameworks.
03 — The 19-Section Validation Plan
The 19 sections are not arbitrary. Each corresponds to a documentation category that FDA, EMA, or ICH guidance either explicitly requires or expects to see addressed in a validation package. The plan structure is not a template — it is derived from the regulatory obligation profile of each specific system type and assessment context.
| Section | Regulatory basis | Status |
|---|---|---|
| 1. System Overview & Intended Use | Required basis for all risk and validation decisions | Always present |
| 2. Regulatory Framework Applicability | Establishes which frameworks govern this system | Always present |
| 3. System Classification | GxP criticality, Part 11 applicability, GAMP category | Always present |
| 4. Risk Assessment Summary | CSA / GAMP 5 proportional validation basis | Always present |
| 5. Supplier Assessment | EU Annex 11 §4.3, ICH Q10 supplier qualification | Always present |
| 6. Installation Qualification | FDA/EU infrastructure verification requirements | Always present |
| 7. Operational Qualification | Functional verification against user requirements | Always present |
| 8. Performance Qualification | End-to-end process verification | Always present |
| 9. User Requirements Specification | Formal intended system behavior documentation | Always present |
| 10. Functional Requirements | Traceability to URS | Always present |
| 11. Configuration Verification | Site-specific configuration validation | Always present |
| 12. Data Migration Assessment | Conditional: only when historical data is migrated | Conditional |
| 13. Interface & Integration Testing | Conditional: only when system integrations exist | Conditional |
| 14. Security & Access Control | 21 CFR §11.10(d), Annex 11 §12 | Always present |
| 15. Audit Trail Verification | 21 CFR §11.10(e), Annex 11 §9 — Part 11/Annex 11 only | Framework-conditional |
| 16. Backup & Recovery Testing | EU Annex 11 §17, FDA data integrity expectations | Always present |
| 17. Training Documentation | Annex 11 §2, 21 CFR §211.68 training requirements | Always present |
| 18. Periodic Review Protocol | Annex 11 §11, ICH Q10 lifecycle management | Always present |
| 19. Validation Summary Report | Closes the validation record per FDA/EU expectations | Always present |
Sections 12, 13, and 15 are the adaptive sections. Section 12 generates only when data migration is part of the implementation scope. Section 13 generates only when the system has documented integrations. Section 15 generates only for systems assessed as Part 11 or Annex 11 applicable. This is what “adaptive” means — the plan reflects the actual obligation profile, not a generic template applied uniformly.
04 — Trust Scoring
Trust scores represent the engine’s assessment of a system’s current governance posture relative to its regulatory obligation profile. The score is a deterministic Completeness & Criticality Index — not a calibrated statistical confidence, probability, or compliance determination. It is computed as a fixed function of open requirement findings by criticality (95 − critical_ratio×20 − major_ratio×8), bounded to a 60–95 base, with up to +3 for declared regulatory-framework coverage (hard ceiling 97). The same inputs always produce the same score. It is computed from four inputs:
Available system documentation relative to the required documentation set for its system type and framework profile.
Age of the most recent validation activity relative to applicable change control triggers and periodic review obligations.
Outstanding required actions from current or previous assessments that have not been addressed.
Whether the system’s current validation approach addresses the specific frameworks applicable to its function — not frameworks in general.
05 — What Remains Manual
Building this is also an exercise in knowing what not to automate. The engine does not claim to replace the following:
The engine provides a governance framework. A qualified validation professional applies it to the specific manufacturing process, product portfolio, and regulatory history of a particular organisation. That contextual judgment is irreplaceable.
The engine generates test strategy guidance and required evidence specifications. It does not execute tests, observe system behaviour, or generate executed test records.
When a system type is genuinely novel — a first-generation AI decision support tool in a GMP environment, for example — the engine provides a framework but the specific regulatory interpretation requires expert engagement with the applicable framework authors.
The engine is designed to eliminate the cognitive overhead of routine governance assessment so that qualified professionals can focus their judgment where it genuinely matters. That is a different claim than automating professional judgment entirely.
06 — Next Step
The best way to assess whether the engine’s regulatory logic holds up is to run it against a system you know well — one where you already understand the validation requirements and can evaluate whether the output matches what your QA team would produce independently. That is what pilot access is for.