Stage: LiveThe Annex 11 §4.3 system description, kept current — automatically, with provenance, ready for signature in your validation system.
What it is
The Annex 11 §4.3 system description — physical and logical arrangements, data flows, interfaces, security measures — generated live from your integration chain and kept current automatically.
The pain it solves
Four named requirements — three regulatory, one industry standard — call for an up-to-date, data-flow-aware system description. Today it's a stale Word doc. GlassHood matches each one to a specific behaviour — verbatim quotes and links inside.
How it works
Two-layer architecture: rule-based monitoring 24/7 plus periodic multi-model AI audit. Edges carry data classification (plaintext / ciphertext / metadata / none) so an MHRA §3.4 data-flow violation is a visible diagram, not a buried log.
Where we are today
Live. We use GlassHood internally to monitor our own services — the demo runs on real data. Anchored on Annex 11 §4.3 + MHRA §3.4 + GAMP 5 D6; deliberately outside the scope of draft Annex 22 (AI prepares groundwork for qualified humans, never makes GxP decisions).
What it is
Every regulated manufacturing system needs an architecture document. Physical and logical layout, data flows, interfaces, security measures — Annex 11 requires it, your auditors expect it. So your team writes one. A diagram, a Word file, twenty-four pages. The day it's signed, it's accurate. And then the system changes — a server moves, an interface is added, a connection quietly stops working. The document doesn't change with it.
Here's the problem: that document can't tell you whether it's still true. The only date on it is the day someone last edited it. To actually know if it still matches reality, someone has to walk the whole system by hand.
GlassHood is built the other way around. It connects to your integration chain — ERP, middleware, MES, SCADA, equipment — and reads the architecture from what's actually running. It compares that live picture against your declared design, and the moment the two drift apart, it shows you where.
So the architecture isn't a document that slowly goes stale. It's a live view that's checked continuously. Every node carries its own status — last reached, last confirmed, healthy or not.
And when you need the formal artifact — for a validation file, for an audit — GlassHood exports it on demand. A controlled system description, stamped with provenance: captured at this moment, every node probed within the last few minutes. Ready for signature in your validation system.
GlassHood's monitoring runs continuously and deterministically. Its AI layer reviews, correlates, and drafts findings for a qualified person — it never makes a GxP decision. The architecture stays owned by your people; GlassHood keeps it honest.
The architecture document you can trust — because it's checked against reality.
The pain it solves
Pharma teams already run two categories of tools that each do real work. Monitoring tools (Grafana, Datadog, Dynatrace) render live topology with rich operational metrics — exactly what the SRE team needs to run the system. Validation platforms(Veeva, Kneat, ValGenesis) version, sign, and route architecture documents through the GxP lifecycle — exactly what Quality needs to release a system for regulated use. The gap is between them: monitoring output is a live dashboard, not a controlled deliverable; validation platforms accept controlled deliverables, but the document arrives as a human-produced PDF, not from live reality.
GlassHood bridges the two — generating what monitoring tools observe in the controlled, signed form validation platforms expect. The four regulations below name what that bridging artifact looks like. Each clause is quoted verbatim, with the source link, paired with the specific GlassHood behaviour that addresses it.
EU GMP Annex 11 §4.3 — Validation, System Description (in force, Revision 1, 2011)
“An up to date listing of all relevant systems and their GMP functionality (inventory) should be available. For critical systems an up to date system description detailing the physical and logical arrangements, data flows and interfaces with other systems or processes, any hardware and software pre-requisites, and security measures should be available.”
Source: EudraLex Volume 4, Annex 11 — Computerised Systems (PDF)
Note on currency: the 2025 draft revision of Annex 11 reorganises this material and the system-description requirement has drawn significant industry comment. Whichever way the final 2026 text lands, an up-to-date system description remains required under the in-force 2011 Annex and across PIC/S member inspectorates. GlassHood is built to satisfy the requirement under either version.
How GlassHood addresses this:
- Auto-generates the system description from a declared manifest + live probes of the actual integration chain.
- Stamps every artifact with provenance (manifest hash, observed-state hash, time-of-capture, time-since-last-probe per node) so “up to date” is verifiable, not asserted.
- Renders physical and logical arrangements, data flows, interfaces, hardware/software prerequisites, and security measures as one unified diagram.
- Exports as a controlled deliverable ready for signature in your validation system of record (Veeva Vault Validation Management, Kneat, ValGenesis) — the Part 11 e-signature is captured there, where the validated signing capability already lives.
MHRA GxP Data Integrity Guidance §3.4 — Data Integrity Risk Assessment (in force, March 2018)
“Perform a data integrity risk assessment (DIRA) where the processes that produce data or where data is obtained are mapped out and each of the formats and their controls are identified and the data criticality and inherent risks documented.”
Source: MHRA ‘GxP’ Data Integrity Definitions and Guidance for Industry (gov.uk)
How GlassHood addresses this:
- Every edge in the topology carries a data-classification label: customer plaintext, customer ciphertext, metadata only, or no customer data.
- Criticality is recorded per edge and per flow — the DIRA artifact is the diagram itself, not a separate spreadsheet.
- Edges that cross a trust boundary while carrying plaintext regulated data raise a policy alarm — a violation is a visible diagram, not a buried log line.
GAMP 5 Second Edition, Appendix D6 — System Descriptions (ISPE, July 2022)
Industry-standard deliverable that operationalises Annex 11 §4.3 into a named system-description document type — physical and logical arrangements, data flows, interfaces, security measures, owners, change history. (GAMP 5 is an ISPE industry guidance document; D6 defines a deliverable type rather than stating a quotable regulatory clause, so it is summarised here rather than quoted verbatim.)
Source: ISPE GAMP 5 Guide — 2nd Edition (ispe.org)
How GlassHood addresses this:
- GlassHood output shapes directly into the D6 deliverable format — no manual re-formatting, no Visio + Word reconciliation step.
- Change history is the drift log: every declared-vs-observed divergence is timestamped, signed when reviewed, and carried forward as evidence of controlled evolution.
EU GMP Annex 22 — Artificial Intelligence: why GlassHood sits outside its scope (draft 7 July 2025; final expected 2026)
The draft Annex 22 governs AI used to make or directly shape decisions inside GMP-critical processes. It permits static, deterministic models (“given identical inputs, provide identical outputs”) and states that generative AI and large-language models “should not be used in critical GMP applications.” LLM use is limited to non-critical applications with qualified personnel retaining the final say. EMA is actively reconsidering this boundary — a multistakeholder workshop on guardrail-based use of generative AI is scheduled for 30 June–1 July 2026.
Source: EudraLex Volume 4 — GMP guidelines (health.ec.europa.eu)
Where GlassHood stands:
GlassHood produces drafts and inputs — a current view of the integration chain, an assembled system description, raised issues for review. None of this is a GMP record. A GlassHood output becomes a controlled GxP record only when a qualified person reads it, takes ownership of it, and submits it. Until that moment it has the regulatory status of any other draft: working material, not a controlled deliverable.
That is the bright line, and GlassHood never crosses it:
- GlassHood does not dose, release, classify, decide, or act on any product, batch, or process.
- GlassHood never submits anything to a validation system on its own authority. Whether a document is uploaded by hand or through an integration, a named qualified person reviews it, adopts it as their own, and bears full end-to-end responsibility for it.
- The integration chain runs identically whether GlassHood is on or off. GlassHood adds no process risk — the founding principle of Annex 11.
AI is how GlassHood does its preparatory work well — monitoring continuously, aggregating across systems, keeping a draft current at a freshness a human team cannot match by hand. It is assistance delivered to a qualified human, not a participant in a GxP decision. One qualified person helping another does not transfer responsibility; neither does GlassHood. The person who makes the final call owns it, and is fully equipped to audit, verify, and accept or reject everything GlassHood provides before they do. Where the AI layer runs, it runs on ColdVault — hardware-encrypted, attestation-bearing inference, so every audit pass is tied to a specific, attestable model version. GlassHood agrees with Annex 22's stance and is built accordingly: AI prepares groundwork for people; it never stands in a GMP decision. If Annex 22's boundaries shift as the text is finalised over 2026–2028, GlassHood's position does not need to — it was never on the regulated side of the line.
How it works
Two-layer architecture. Layer 1: rule-based monitoring runs 24/7, tracking every message across the integration chain. Deterministic — identical inputs produce identical outputs — and therefore within the static-model category the draft Annex 22 permits for critical GMP applications. Layer 2: periodic AI audit analyses anomalies, correlates across systems, and drafts investigation-ready findings for a qualified human to review. Multi-model analysis reduces the risk of hallucinated root causes — when models disagree, the finding is flagged for human review rather than asserted. Layer 2 never auto-asserts a conclusion and never acts on the integration chain.
Data classification on every edge. Edges carry one of four labels: customer plaintext, customer ciphertext, metadata only, or no customer data. An edge labelled "plaintext crossing a trust boundary" is itself an audit finding — which is exactly the artifact MHRA GxP Data Integrity Guidance §3.4 asks for when it requires data flows mapped with criticality.
ServiceNow correlation (on the roadmap). Will cross-reference infrastructure logs with SNOW tickets to surface the patterns invisible to individual teams — repeat incidents across different queues that share a single underlying cause.
Where we are today
Live and in continuous use. We run GlassHood internally to monitor our own services; the public demo runs on real data from those systems, not a canned scenario. Each deployment is configured for the specific integration chain it monitors.
Anchored on EU GMP Annex 11 §4.3 + MHRA GxP Data Integrity Guidance §3.4 + GAMP 5 Second Edition Appendix D6 — the three named requirements that call for an up-to-date, data-flow-aware system description today. Annex 22 (AI) is still in draft; we are tracking the consultation and the EMA's June 2026 workshop, and will continue to align as the final text settles over 2026–2028.
See: What is inside (ColdVault & multi-model audit)
The audit reasoning runs on ColdVault — encrypted infrastructure with multi-model aggregation. When models disagree the finding is flagged, not asserted; this is the same defensive posture used to keep recommendations grounded in BatchGuard and TestRobin.
GlassHood is a viewer — it reads from your exported logs and ServiceNow data. It does not configure, enable, or alter logging inside customer systems; visibility is the product, not control.