Trust Layer
Markovian Protocol / FDA 21 CFR Part 11

Audit trails the FDA can check without trusting your system

21 CFR Part 11 requires secure, computer-generated, time-stamped audit trails for electronic records in FDA-regulated work. The audit trail lives inside the operator's validated system, and its assurance rests on that system, and on the operator. Anchoring the audit trail to an independent public log, one whose checkpoints are timestamped onto Bitcoin, lets an investigator confirm nothing has been altered since it was written, without trusting that system.

Section 11.10(e): secure, time-stamped, and not obscured

21 CFR Part 11 governs electronic records and signatures in FDA-regulated industries. Section 11.10(e) requires secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records, and adds that record changes shall not obscure previously recorded information. The audit trail must be retained at least as long as the record itself, and be available for agency review and copying.

Section 11.10(a) requires the system to be validated for, among other things, the ability to discern invalid or altered records. That is the property under scrutiny: can anyone tell whether the record was altered, and can they tell it without taking the operator's word for it.

A validated system is still the operator's system

In practice the audit trail lives inside the operator's validated system, an EDC, LIMS, or MES. Its integrity rests on that system being trusted, and on the operator not altering the store beneath it. FDA data-integrity enforcement, the warning letters and Form 483 observations, is largely about this exact failure: audit trails switched off, records backdated, results overwritten. Validation raises the bar inside the system. It does not give an outside investigator a way to check the record without trusting that system.

Anchor the audit trail to a log outside the operator's control

Each audit-trail entry is hash-chained, so every entry commits to the one before it, and the head of the chain is written as a leaf into a public transparency log at log.markovianprotocol.com, an append-only log outside the operator's control. Seven independent witnesses, including Geomys and Google's transparency.dev witnesses, cosign the log checkpoint hourly, and checkpoints are anchored to Bitcoin via OpenTimestamps. An investigator recomputes the chain from the records, which needs nobody, then checks inclusion of the head in the witnessed log from public endpoints. Once the checkpoint is anchored to Bitcoin, the head is checkable against the Bitcoin blockchain itself, independent of Markovian too.

An edit to any historical entry breaks the chain and no longer matches the anchored head. The regulation says record changes shall not obscure previously recorded information. This layer does not stop an operator editing their own database, it makes any such edit detectable by anyone, against a log the operator does not control and whose history is countersigned by independent witnesses. It maps to the ALCOA principles the FDA reads records by, strengthening the Original, Accurate, and Enduring properties in particular.

What the anchor provides, and what stays yours

21 CFR Part 11 controls
System validation, 11.10(a)Operator, your validated system
Access and e-signatures, 11.10(d), 11.100+Operator
Capturing entriesOperator's system
Retention duration, 11.10(e)Operator, you keep the records

Tamper-evidence, not obscuring prior recordsHash chain, head in the witnessed transparency log
Time-stampLog timestamp, anchored to Bitcoin via OpenTimestamps
Independent check for agency reviewRecompute locally, check inclusion in the public log

A Part 11 audit-trail entry, anchored

The same art12_audit_trail.py mechanism applies to a Part 11 audit trail. Each entry records the operator action, the record affected, the time, and a link to the entry before it. The chain head is anchored to Bitcoin and verified by recomputation.

One audit-trail entry
{ "seq": 5, "utc_time": "2026-07-01T14:22:07Z", "action": "modify", # create | modify | delete "record_id": "BATCH-2287/assay-11", "operator": "analyst-42", "reason": "recalculation per SOP-1140", "prev_hash": "7c2a...9f", "entry_hash": "b0e4...15" # any edit to a prior entry breaks this } # chain head logged, witnessed, anchored to Bitcoin, checkable at agency review

Markovian provides the tamper-evidence and verifiability layer on top of the audit trail your validated system already produces. Validation, capture, and retention stay yours, and it is not a Part 11 compliance solution or regulatory advice.