This document describes the system boundary, compliance capabilities, and deployment assumptions of GIMS Compliance Relay for review by QA leads, validation engineers, regulatory affairs personnel, and technical buyers.
GIMS Compliance Relay is a provider-neutral compliance-logging relay for file-writing instruments. Its function is to convert regulated operational events, primarily the creation of raw instrument data files, into an append-only, tamper-evident record bound into an HMAC-keyed hash chain, attributed to a server-resolved user identity, and timestamped. It captures and records events; it does not read or interpret instrument data. Electronic signatures are now a core function. It is not a full LIMS, not a full electronic quality system, and not a standalone guarantee of 21 CFR Part 11 compliance.
In the motivating use case, the instrument is an NMR workstation. The instrument produces valuable primary data, but the native instrument environment may not provide the level of time-stamped audit capture, user attribution, and tamper-evident record handling required before that output enters production, QC, or other controlled workflows.
The relay's compliance claim is deliberately bounded: it provides a defensible, append-only record of who generated raw data, when, from which device, and whether that record shows evidence of tampering, and it can bind two-component electronic signatures to those records. Full scientific review, approval, interpretation, and disposition workflows remain the responsibility of downstream systems unless separately integrated.
System positioning: GIMS Compliance Relay is designed to support 21 CFR Part 11 data-integrity requirements when deployed within validated environments. It is 21 CFR Part 11-defensible, but it is not validated or certified: compliance is a property of the complete validated deployment, not of any single component. It is intended to function as a component of a broader quality infrastructure, not as a self-certifying compliance package.
Status: the Part 11 hardening work is complete, closing the lagging control points around an already-correct integrity core. As of 2026-06-27, 134 tests pass against a live Postgres (0 skipped), and 122 pass with 12 Postgres-conformance tests skipped on the zero-dependency SQLite-only stack.
The relay monitors configured folders on controlled instrument workstations, detects compliance-relevant file events, and records them into a project-scoped compliance database. It is designed to answer:
The creation or detection of a raw instrument data file in a watched folder.
A server-resolved actor identity, either OS-bound from the workstation session or authenticated from a signed token, never accepted from the network. Events with no resolvable actor are rejected. Also timestamp, project, path, method, status, and related audit metadata.
Append-only records bound into an HMAC-SHA256 keyed hash chain: each checksum covers the prior record's checksum and a monotonic sequence, so mutation, reorder, or insertion breaks recomputation. Trail heads are anchored to external notarization (object-lock WORM in the self-hosted or AWS stack; a filesystem notary locally).
| Capability | Relay role | Handled elsewhere |
|---|---|---|
| Instrument data origin logging | Core function | — |
| Electronic signatures (§11.50, §11.70, §11.200) | Core function | Full scientific review and batch disposition may still be downstream |
| Review, approval, and disposition workflow | Out of default scope | LIMS, ELN, QA systems, or broader GIMS modules |
| User provisioning, password policy, access control | Provided natively (authenticated accounts, lifecycle, and lockout) | Integrates with enterprise identity and workstation management |
| Backup, retention, disaster recovery | Relies on enterprise controls (object-lock WORM notarization available) | IT infrastructure and backup policies |
| Installed-system validation | Designed to support | Customer QA and validation team |
The relay natively provides authenticated identity, tamper-evident record integrity, and two-component electronic signatures. It deliberately does not duplicate enterprise backup and disaster recovery or full LIMS and ELN workflows. The premise is that a regulated environment already maintains controlled workstations, enterprise backup policies, and secure storage infrastructure, and that the analytical review and disposition lifecycle lives in dedicated downstream systems. The relay concentrates on the control points it can own end to end: server-resolved attribution, an HMAC-keyed append-only trail, external notarization, and record-bound signatures. Rebuilding backup or a full quality-management workflow inside the relay would enlarge validation scope and overlap existing IT controls without adding compliance value.
The table below maps Part 11 requirements to the relay's native capabilities and the controls that remain the deployment environment's responsibility. The mapping is deliberately conservative: the relay is represented as one component within a validated environment rather than as a system that closes all Part 11 requirements independently.
| Part 11 requirement | Relay support | Remaining dependencies |
|---|---|---|
| Validation to ensure accuracy, reliability, and intended performance (§11.10(a)) | Software is specified, installable, testable, and designed to support IQ/OQ/PQ qualification. | Customer must perform validation within its own environment and procedures. |
| Secure, computer-generated, time-stamped audit trails (§11.10(e)) | Core design. Append-only, computer-generated records with dual timestamps, server-resolved user, project, path, and status, bound into an HMAC-keyed hash chain. | Storage permissions, retention schedules, and review procedures remain part of the deployment. |
| Record integrity and tamper detection | HMAC-SHA256 keyed hash chain. Each record's checksum covers the prior record's checksum and a monotonic sequence, so any mutation, reorder, or insertion breaks recomputation. Trail heads are anchored to external notarization (object-lock WORM in the self-hosted or AWS stack; a filesystem notary locally). This is tamper evidence, not absolute immutability: the same symmetric key writes and verifies, so a key-holder could rewrite history and regenerate a valid chain. | Tamper-evidence rests on external anchoring plus the write-time key not leaking. Filesystem hardening and SOPs for storage and access remain necessary. |
| Attribution of actions to individuals (§11.10(d)) | Server-resolved actor, OS-bound from the session or authenticated from a signed token, never accepted from the network. Events with no resolvable actor are rejected rather than written as unknown. | Enterprise identity management for the underlying OS and SSO accounts must be in place and maintained. |
| Authority checks and access control (§11.10(d), §11.10(g)) | Authenticated application accounts with admin-gated registration, admin-only activate, deactivate, and reset, and per-account login and sign lockout. | Corporate identity, role management, OS access policy, and site procedures. |
| Electronic signatures: manifestations, record linking, two components (§11.50, §11.70, §11.200) | Core function. Two-component signature with password re-authentication even inside an active session, required non-empty meaning and reason, bound to target record checksums that must already exist in the trail. | Full scientific review, batch disposition, and release SOPs remain the customer's responsibility. |
| Unique ID and password controls with account lifecycle (§11.300) | Core function. Argon2 password hashing (PBKDF2-HMAC-SHA256 fallback), unique accounts, admin-gated provisioning, and the full activate, deactivate, and reset lifecycle with a last-active-admin guard. | Customer password and periodic-access-review SOPs, plus enterprise identity where deferred. |
The relay records the origin and integrity of raw data creation events. It does not constitute the complete analytical data lifecycle. Review, scientific interpretation, approval, and final disposition remain in downstream systems unless separately integrated with the relay or broader GIMS platform.
The relay is the system of record for raw data origin and integrity events. It is not the system of record for the full analytical lifecycle. When presenting the relay to an auditor or inspector, the correct characterization is:
In Part 11 terms, an electronic signature is not simply a username attached to an event. It is an explicit signing act tied to a defined business meaning, such as reviewed, approved, or rejected, coupled with credential re-entry. The relay now performs this act natively. POST /events/sign always re-verifies the signer's password against the auth store, even inside an active session, is throttled and locked out on repeated failure, requires a non-empty meaning and reason, and binds the signature to target record checksums that must already exist in the trail (§11.70). A signature record captures the signer, meaning, and reason, satisfying the two-component requirement of §11.200 and the manifestation requirement of §11.50. Full scientific review, batch disposition, and final release may still live in downstream systems unless separately integrated.
A defensible regulated deployment of the relay assumes the following conditions are in place in the customer environment:
The relay natively owns the controls closest to the record: server-resolved attribution, the HMAC-keyed trail, external notarization, application identity, and signatures. It does not rebuild enterprise backup and disaster recovery, which regulated customers already maintain. This keeps validation scope focused on what the relay itself must qualify.
The relay provides its own authenticated identity, account lifecycle, and electronic signatures rather than deferring them entirely to enterprise systems. It still depends on validated enterprise infrastructure for workstation security and for backup, retention, and disaster recovery, which are treated as deployment dependencies rather than optional integrations. Object-lock WORM notarization is available where stronger anchoring is required.
Customer validation of the installed system is expected and required in a regulated deployment. The product is structured to support clean qualification within an existing enterprise environment, not to eliminate the validation requirement.
| Responsibility | Owner | Notes |
|---|---|---|
| Software features, architecture, and intended use documentation | Vendor | Includes configuration guidance, release documentation, and technical specifications. |
| Installed-system validation (IQ/OQ/PQ or equivalent) | Customer QA and validation | Performed against the actual deployment environment and procedures. |
| SOPs and training | Customer | Defines who uses the relay, how exports are reviewed, and how deviations are handled. |
| Identity, access control, and workstation policy | Shared: vendor and customer | The relay provides application accounts, lifecycle, and lockout; the customer manages enterprise identity, SSO, workstation policy, and periodic access review. |
| Backup and retention | Customer IT and QA | Relay is intended to operate within existing enterprise backup and retention policies. |
In a correctly deployed and validated environment, if a data integrity finding were to arise, the likely root cause would be validation gaps, procedural deficiencies, or infrastructure failures, not the absence of raw data origin audit capture. The relay is designed to close that specific gap reliably.