Part 11 controls for GxP records: hash-chained audit trails, electronic signatures and access levels

What the module does

• An append-only audit trail: every create, change, decision, signature, failed signature, export, AI draft and AI final review is an entry with who, what, the old and new value and the reason, time-stamped by the database; entries cannot be updated or deleted, and nothing is deleted from a record.
• A hash chain per organization: each entry carries the SHA-256 hash of the one before it, every record page shows the integrity check, and administrators re-hash the chain end to end; a chain that does not verify is a security event.
• Reasons for change: required to change any existing value, link or unlink a record, withdraw a document, reopen, return, reject, reassign, cancel or reinstate; a change to a field someone else changed after you opened the record is refused with their name and the time.
• Electronic signatures: the sign-in email and password typed on every signature, checked with the identity provider and never stored, with a signature statement the signer confirms; each signature records the signer, the meaning (Authored, Reviewed, Approved, Read and understood, Executed, Verified), the time, the record version, the method and a SHA-256 of the content as signed.
• Signing lockout: five failed attempts in 15 minutes, counted across every workspace the person belongs to, lock signing for 15 minutes; the account holder is emailed, and every failed attempt is in the record's audit trail and the security log.
• Review and approval rules on every record: the author never reviews or approves their own record, content is frozen while routed, and whoever recorded a result, executed or verified a step or did the work cannot review or approve it; final approval signs and locks the record, and a revision under change control starts the next version while earlier signatures stay on the earlier one.
• Access levels (User, Manager, Administrator) stored per person per workspace and checked by the server on every request; connections and security are administrators' only, nobody changes their own level, and a QLogix super administrator working in a workspace is shown by a banner and recorded in its security log.
• Sessions and segregation: sign-out after 15 minutes without interaction, across every tab, and rate limits on requests and AI steps; the organization is taken from the verified sign-in token, never from the browser, and new client organizations get their own database for their records, audit trail, signatures, security log and files.
• Files and controlled copies: attachments fingerprinted with SHA-256 on arrival and checked again each time the AI reads them, opened only through short-lived links; every exported PDF is encrypted (AES-256) against editing, stamped by its state, carries the signature manifest and the document change history, and is an audit entry.

How it fits the platform

These controls are not a separate application: every product, from the Agentic QMS and the LIMS to the MES, calibration and environmental monitoring, writes to the same audit trail and signs through the same review and approval flow. Each module adds its own second-person rules on top, such as an analyst who recorded a result not reviewing the sample, or an operator who executed a batch step not verifying it. The audit trail of one record is on that record and in its PDF and CSV exports; the Audit trails page gathers every entry across every product for periodic review, filtered by product, period, person and action, and exports up to 50,000 entries as CSV with both chain hashes.

The REST API and the MCP server are read-only: nothing is created, changed, decided or signed through them. API keys are issued by QLogix, scoped, expiring and stored only as a fingerprint, and a key that is not valid is a security event. AI drafts, AI final reviews, Q Agent decisions and scheduled agent changes are audit entries like any other, and the AI never signs. The site validates QLogix for its intended use, as it would any GxP system.

Where people decide

The system enforces: it time-stamps, chains and verifies the audit trail, and refuses a change without a reason, a signature with a wrong password, an action above a person's level and a signature by someone a second-person rule excludes. People decide: administrators invite people and set their access levels, each change in the audit trail and the security log; authors, reviewers and approvers sign with their own credentials; managers and administrators review the audit trail periodically and raise a deviation for anything unexplained. The AI drafts and reviews but never signs, approves or decides.