8. Why This Architecture
Three architectural decisions distinguish Wrapper from the typical SME stack:
1. One Log per regulated artefact, not one folder. Folder-based eQMS answers "show me X" with "open this folder and scroll". Log-based eQMS answers with "open this Log, filter by X, see the signed row". The first fails at every NB audit; the second is what the regulator wants. ISO 13485 §4.2.4 record-retrievability is a clause-level audit criterion.
2. One Audit trail across the entire eQMS. Most eQMS products run separate audit logs per module. Wrapper’s polymorphic ObjectApproval + INSERT-only AuditSignature chain is single-source-of-truth across all seven approvable object types. 21 CFR Part 11.10(e) requires the audit trail to be independent of operator and capable of being copied without altering the original — Wrapper’s INSERT-only DB grants enforce this at the storage layer, not just the application.
3. One AI contract — proposal, not action. Most AI-enabled compliance products allow the AI to autonomously act. This puts those products into High-Risk classification under EU AI Act Annex III + Art. 6. Wrapper’s AI architecture is architecturally HITL: the AI writes findings, humans approve actions, every approval is PIN-signed. This keeps Wrapper’s own AI in the Limited-Risk class (Art. 50 transparency only) while still producing regulator-grade evidence.
These three decisions compound: because every artefact is a Log row, the audit trail is automatic; because the audit trail is unified, the AI proposals can be approved against it; because the AI approvals are PIN-signed into the same trail, the HITL evidence is regulator-defensible.
