Technical design document for the Axiom Sentinel regulatory compliance engine — covering the immutable audit trail architecture, 21 CFR Part 11 electronic signature system, automated compliance package rendering pipeline, export control enforcement layer, and substance compliance BOM integration.
CLASSIFICATION
INTERNAL — ENGINEERING
VERSION
2.1.0
FRAMEWORKS
8 REGULATORY STANDARDS
RUNTIME
RUST / AXIOM CORE
01 — ARCHITECTURAL OVERVIEW
Sentinel is not a compliance module. It is a governance layer embedded in the Axiom database write path.
Traditional PLM systems add compliance as a workflow overlay — a separate approval chain bolted onto existing data management. Sentinel inverts this architecture: compliance governance is embedded directly in the database write layer. Every mutation to a governed record passes through the Sentinel interceptor before committing. The interceptor evaluates the mutation against the active compliance framework rules, captures the audit trail entry, validates the electronic signature (if required), and checks export control authorization — all before the write commits. If any compliance check fails, the mutation is rejected at the database level, not at the UI level. Compliance is not enforced by process discipline. It is enforced by architecture.
SENTINEL WRITE-PATH INTERCEPTOR ARCHITECTURE
01
Mutation Request
Any create/update/delete operation on a governed record enters the Sentinel interceptor pipeline
↓
02
Framework Rule Engine
Active compliance frameworks (FDA, AS9100D, ITAR) evaluated. Signature requirements, retention policies, and access rules determined
↓
03
Export Control Gate
User citizenship, clearance, TAA scope evaluated against USML/ECCN classification of the target record. Unauthorized: reject + log + alert
Field-level delta computed (previous value → new value). Append-only entry written to WORM audit store. Entry includes user ID, timestamp, reason code, document hash
Audit Trail Append
↓
06
Commit
All compliance checks passed → mutation committed to Axiom product knowledge graph. Atomically: data + audit + signature stored as single transaction
The audit trail is the most scrutinized component in any FDA inspection. Disabled audit trails, shared user credentials, and unreviewed logs appear in Warning Letters with alarming regularity. Sentinel's audit trail is not a feature — it is a structural property of the database architecture.
The audit trail is embedded in the database write layer. It cannot be disabled, paused, or configured to skip certain record types. Every governed write operation passes through the Sentinel interceptor, which computes a field-level delta (previous value → new value), generates a cryptographic timestamp from a validated NTP source (not the user's local clock), captures the authenticated user identity and reason-for-change code, and appends the entry to write-once-read-many (WORM) storage. The WORM architecture means entries are append-only: no user — including system administrators — can modify, delete, or overwrite any historical audit record. Even the system itself cannot alter committed entries; it can only append new ones.
ALCOA+ Principle
Sentinel Implementation
Enforcement Method
Attributable
Every action tied to unique user via MFA-verified credential
No shared accounts. MFA enforced on all signature actions. User provisioning requires identity verification
Legible
Human-readable with full context: user, record, field, old value, new value, reason
Structured audit entry schema. No binary-only logs. Exportable to PDF/CSV for inspection
Contemporaneous
Captured at the moment of action via cryptographic system timestamp
NTP-synchronized system clock. User cannot modify time. Timestamp embedded in write transaction
Original
System-generated entries — never user-entered or transcribed
Audit entries created by interceptor code, not by user interface. No manual audit log entry possible
Accurate
SHA-256 document hash verifies entry integrity. Tamper-evident checksums on every record
Hash chain linking entries. Any modification to a committed entry invalidates the chain and triggers alert
Complete
Every governed field change captured. No opt-out. No exceptions
Interceptor is in the write path — data cannot reach the database without passing through audit capture
Consistent
Uniform audit entry schema across all record types, all frameworks, all modules
Single AuditEntry struct. Framework-specific metadata added as typed extensions, not ad-hoc fields
Enduring
WORM storage with configurable retention (7yr default, 30yr for ITAR). Integrity-verified backups
Append-only storage medium. Backup integrity verified via hash chain validation on restore
Available
Instantly queryable by auditors. Inspector data room provides read-only access to full audit history
Indexed by record, user, date range, action type. Sub-second query response across millions of entries
WORM storage architecture: Audit entries written to append-only storage (WORM — Write Once Read Many). Database permissions prevent any user, including DBA, from executing UPDATE or DELETE on audit tables. Storage medium verified via integrity checksums on scheduled cadence
Hash chain integrity: Each audit entry includes a SHA-256 hash of the previous entry, creating a blockchain-like chain. Any tampering with a historical entry breaks the chain, immediately detectable by automated integrity verification
Storage capacity management: Automatic tiering moves aged audit entries from hot storage (SSD, sub-millisecond query) to warm archive (compressed, indexed, queryable within 2 seconds) without breaking the hash chain or losing accessibility
Always-on
Cannot be disabled or paused
Field
Level delta capture (prev → new)
SHA-256
Hash chain tamper detection
WORM
Append-only storage enforcement
03 — ELECTRONIC SIGNATURE & 21 CFR PART 11
Every signature captures who signed, what they signed, why they signed, and the exact version they reviewed.
Electronic signatures are the most frequently cited data integrity violation in FDA Warning Letters. Shared passwords, generic user accounts, and missing intent capture are systemic failures that Sentinel prevents by architecture.
Sentinel implements the full 21 CFR Part 11 Subpart C electronic signature specification. Every signature is a composite cryptographic object containing: (1) unique signer identity verified through multi-factor authentication (knowledge factor + possession or biometric factor), (2) explicit signing intent selected at signature time (authored, reviewed, approved, verified, witnessed), (3) cryptographic timestamp from NTP-synchronized system clock, (4) document hash (SHA-256 of the exact record version being signed), and (5) signature manifest ID linking to the immutable audit trail entry. The signature is atomically bound to the record version — if the record changes after signing, the signature status changes to "suspect" and the record cannot proceed through workflow until re-signed against the current version.
E-SIGNATURE CAPTURE FLOW
01
Signing Action Triggered
User initiates sign action on a record. System presents the exact record version with computed SHA-256 hash displayed
↓
02
Identity Verification (MFA)
User re-authenticates with MFA: password + TOTP token, hardware key (FIDO2), or biometric. Session token insufficient — active verification required
↓
03
Intent Selection
User selects signing intent from framework-defined options: "I authored this record" / "I reviewed and approve" / "I verified the accuracy" / "I witnessed this action"
↓
04
Reason & Comment
Optional reason-for-signing captured (required for certain framework actions). Free-text comment field for additional context
↓
05
Cryptographic Binding
Signature object created: user_id + MFA_method + intent + timestamp + document_hash + reason. Atomically committed to WORM audit store
MFA: TOTP (Software Token)
Time-based one-time password via authenticator app. 30-second rotation. HMAC-SHA1/SHA256
NATIVE
MFA: FIDO2 / WebAuthn
Hardware security key (YubiKey, Titan). Phishing-resistant. Public key cryptography
NATIVE
MFA: Biometric (Touch ID / Face ID)
Platform biometric via WebAuthn API. Private key never leaves device secure enclave
NATIVE
MFA: Badge / NFC Tap
Proximity card for shop floor signing. Combined with PIN for two-factor. Industrial-grade readers
INTEGRATION
04 — ENGINE ARCHITECTURE DEEP DIVES
Eight compliance engines. Full architecture documentation.
01
Design History File Generator
Graph-query rendering · ISO 13485 §7.3 structure · ISO 14971 risk integration · Incremental milestone snapshots
▼
The Design History File is the FDA's master record of how a medical device was designed. Sentinel generates it by executing a structured query against the Axiom product knowledge graph — not by assembling documents. The query traverses: (1) design inputs (requirements from Meridian), (2) design outputs (specifications, drawings, BOMs from Lattice), (3) design verification (simulation results from Nexus, test reports), (4) design validation (clinical/field data from Echo), (5) design reviews (approval signatures from Cascade), and (6) design changes (ECO history from Cascade). Each section maps directly to ISO 13485:2016 §7.3 clauses. Risk management artifacts per ISO 14971 (hazard analysis, risk evaluation, risk control, residual risk assessment) are integrated through the same graph traversal — because risk controls trace to design features, and design features trace to requirements.
DHF RENDERING PIPELINE
01
Graph Query Dispatch
Product ID + revision → traverses requirement→design→verification→validation→change subgraphs
↓
02
Section Assembly
Query results mapped to ISO 13485 §7.3 section structure: 7.3.1 planning → 7.3.7 changes
↓
03
Risk File Integration
ISO 14971 hazard analysis, FMEA, risk controls linked to design elements via trace relationships
↓
04
Evidence Attachment
Test reports, simulation results, approval signatures rendered as embedded evidence artifacts
↓
05
Submission Rendering
Output: paginated PDF/eCTD with TOC, cross-references, and regulatory-required formatting
3 days
Full DHF render (vs. 6 weeks manual)
§7.3
ISO 13485 section mapping
14971
Risk file integrated
Query
Graph-based (not document assembly)
02
First Article Inspection Packaging
AS9102 Forms 1/2/3 · Balloon-to-CMM linkage · Material cert integration · Supplier FAI coordination
▼
The FAI package is the most labor-intensive compliance deliverable in AS9100D. Sentinel automates it by linking three data streams: (1) drawing characteristics from Axiom CAD management (each ballooned dimension is a queryable node in the knowledge graph), (2) dimensional measurement data from coordinate measuring machines (CMM) or optical inspection systems via direct integration, and (3) material certifications and special process approvals from the supplier quality system. The AS9102 Form 3 (Characteristic Accountability) is populated automatically: each balloon number links to its nominal dimension, tolerance, actual measurement, and pass/fail evaluation — no manual transcription from inspection reports to spreadsheets.
CMM data integration: Direct connection to Zeiss Calypso, Hexagon PC-DMIS, Mitutoyo MiCAT, and Renishaw MODUS. Measurement results mapped to drawing characteristic IDs automatically. Supports multi-part FAI with statistical sampling
Material certification linkage: Supplier-provided mill test reports and material certifications linked to BOM components via Lattice. Sentinel validates that material properties meet specification requirements (tensile strength, hardness, composition) and flags non-conformances
Special process qualification: Nadcap and customer-approved special process records (heat treatment, welding, NDT, surface finishing) linked to the FAI package through the manufacturing process model
Export control enforcement in traditional PLM systems operates at the folder or project level — permissions set once, audited annually, and frequently outdated. Sentinel enforces export control at the data layer: every individual access request is evaluated in real time against the user's citizenship status, security clearance, program authorization, active TAAs, and applicable export licenses. The evaluation happens in the Sentinel interceptor — the same write-path gate that captures audit trails and electronic signatures. This means that even if a user has valid PLM credentials, their request to view or download a controlled technical data package is denied if their export authorization does not cover that specific classification.
// Export control access evaluation — per-request enforcementpub fnevaluate_export_access(
user: &AuthenticatedUser,
record: &TechnicalDataPackage,
) -> AccessDecision {
let classification = record.export_classification(); // USML cat or ECCNmatch classification {
ExportClass::ITAR(category) => {
if !user.is_us_person() {
// Check for active TAA covering this categorylet taa = find_active_taa(user, category);
match taa {
None => AccessDecision::Deny {
reason: "No active TAA for USML category",
escalate_to: EmpoweredOfficial,
},
Some(agreement) => {
if agreement.is_expired() {
AccessDecision::Deny { reason: "TAA expired", .. }
} else {
AccessDecision::Allow { via: agreement.id() }
}
}
}
} else {
AccessDecision::Allow { via: "US Person" }
}
}
ExportClass::EAR(eccn) => evaluate_ear_license(user, eccn),
ExportClass::Unrestricted => AccessDecision::Allow { via: "No restriction" },
}
}
Substance compliance flows upward through the BOM. Every component in the Lattice BOM carries material declaration data (IPC 1752A format) from its supplier. Sentinel's substance engine screens each component's declared materials against every applicable restricted substance list simultaneously: EU RoHS (10 restricted substances), REACH SVHC candidate list (updated semi-annually), TSCA (EPA chemical inventory), California Proposition 65, and conflict mineral regulations (3TG: tin, tungsten, tantalum, gold). Screening results aggregate upward through multi-level BOM roll-ups: if any leaf-level component contains a restricted substance, the flag propagates to every parent assembly and finished product that contains it. Product-level compliance declarations are generated per target market and regulation — one BOM, multiple compliance declarations.
Automatic substance list updates: Sentinel subscribes to regulatory update feeds from ECHA (REACH SVHC), EU Commission (RoHS exemptions), EPA (TSCA), and OEHHA (Prop 65). When a new substance is added to a restricted list, all BOM components containing that substance are immediately flagged
Supplier declaration workflow: Material declaration requests sent through the Forge supplier portal with IPC 1752A/1754 structured response templates. Delinquent suppliers tracked with escalation workflows. Declaration data validated against known material compositions (e.g., a declaration claiming lead-free solder but specifying SnPb alloy is flagged as inconsistent)
Exemption management: RoHS and REACH exemptions are tracked per component with expiration dates. When an exemption expires, all products relying on that exemption are flagged for redesign or re-sourcing — before the expiration takes effect
The worst time to discover a compliance gap is during an audit. The best time is three months before, when there is still time to close it. Sentinel's readiness engine continuously monitors every compliance dimension: e-signature completeness (are all required signatures captured?), audit trail integrity (is the hash chain valid?), traceability coverage (do all requirements have verification evidence?), export control compliance (are all TAAs current?), substance compliance (are all supplier declarations received?), and documentation currency (are all controlled documents within review cycle?). These dimensions aggregate into a composite readiness score (0-100%) with sub-scores per framework. The mock audit simulation engine runs the exact queries an FDA, AS9100D, or IATF auditor would execute and reports gaps in the response.
Mock audit queries: "Show me the design history for product X" → tests DHF completeness. "Trace requirement Y to its verification evidence" → tests Meridian traceability. "Show me the audit trail for change Z" → tests Cascade audit integrity. Each query executed programmatically, results compared against compliance template, gaps reported
Inspector data room: When an auditor arrives, Sentinel provisions a secure, read-only environment with pre-configured compliance views. The auditor navigates the product knowledge graph directly — querying requirements, tracing changes, reviewing signatures, and examining audit trails — without requiring an intermediary to "find documents" or "pull files"
Trend analysis: Readiness score tracked over time. Identifies whether compliance posture is improving or deteriorating. Alerts triggered when readiness score drops below configurable thresholds (e.g., alert at 95%, escalate at 90%)
0-100%
Continuous readiness scoring
Mock
Audit simulation with gap detection
Portal
Inspector data room (read-only)
Trend
Readiness trajectory analysis
05 — CROSS-ENGINE INTEGRATION MAP
Sentinel is not a standalone module. It is the governance layer that every other Axiom engine passes through.
Every action in Cascade (change management), Nexus (simulation), Echo (field feedback), Lattice (BOM), and Meridian (requirements) passes through the Sentinel interceptor. Compliance is not a separate workflow — it is an architectural property of the entire Axiom platform.
Cascade → Sentinel
Every ECR/ECO/ECN action passes through e-signature capture and audit trail. Regulatory change classification triggers framework-specific approval workflows
NATIVE INTEGRATION
Nexus → Sentinel
Simulation results that verify regulatory requirements auto-populate compliance evidence packages. ITAR-controlled simulation data enforced at access layer
NATIVE INTEGRATION
Echo → Sentinel
Field failures triggering regulatory reporting obligations (MDR, MedWatch, RAPEX) auto-generate the required notification packages from the digital thread
NATIVE INTEGRATION
Lattice → Sentinel
BOM components carry substance declarations screened by Sentinel. As-built serialized records provide the traceability evidence required by AS9100D and FDA QSR
NATIVE INTEGRATION
Meridian → Sentinel
Requirements verification status feeds directly into DHF generation and AS9100D qualification evidence. V-model coverage data drives audit readiness scoring
NATIVE INTEGRATION
External: CMM / LIMS
Coordinate measuring machines and laboratory information systems provide dimensional and material test data for FAI packages and design verification evidence
API INTEGRATION
06 — DEPLOYMENT & SYSTEM VALIDATION
Risk-based validation per FDA CSA guidance (September 2025).
Sentinel follows the FDA's finalized Computer Software Assurance (CSA) guidance from September 2025, which establishes a risk-based approach to validation that replaces exhaustive IQ/OQ/PQ protocols with focused testing on functions that impact product quality and patient safety.
The CSA framework concentrates validation effort where risk is highest. For Sentinel, the highest-risk functions are: (1) audit trail integrity (can an entry be modified after commit? — test with attempted SQL injection, direct database UPDATE, and storage-level manipulation), (2) e-signature binding (does a signature remain valid only for the exact record version signed? — test with post-signature record modification), (3) export control enforcement (does the system correctly deny access to unauthorized users? — test with exhaustive citizenship/clearance/TAA combinations), and (4) compliance package accuracy (does the rendered DHF/FAI match the source data? — test with known-answer validation sets). Lower-risk functions (UI formatting, report pagination, notification delivery) receive proportionally less validation effort.
Validation documentation package: Sentinel ships with a pre-built validation master plan (VMP), validation protocol templates, traceability matrix (system requirement → test case → test result), and summary report template. Customers customize; Sentinel provides the framework
Continuous validation: Automated regression tests execute on every Sentinel release. Test results are captured in the same audit trail system that Sentinel governs — meaning the validation evidence for the compliance system is itself compliant
Change control: Any update to Sentinel configuration (framework rules, signature workflows, access policies) passes through formal change management via Cascade — with full impact analysis, approval routing, and audit trail