21 CFR Part 11 signature strategy

21 CFR Part 11 governs electronic records and electronic signatures for FDA-regulated software. TRACE ALM addresses Part 11 with two complementary layers of signing:

1. Auto-stamp — per-PR REVIEWED_HASH records the content approval that occurred during development
2. Signet — formal release-record / verification-record signatures that meet the legal definition of a 21 CFR Part 11 e-signature

Both are required. This page walks through the §11.10 sub-clauses and shows what each layer covers.

The two layers, side by side

	Auto-stamp REVIEWED_HASH	Signet signature
Captured event	A code-owner approved a PR that touched a regulated artefact	A designated signer formally approved a release / verification record
Frequency	Per regulated PR (often, during development)	Per release / per verification campaign (rare, formal events)
What’s signed	The content of one or more .sdoc requirements	The aggregate release evidence bundle (RTM + Allure + JUnit + index.json)
Storage	Inline REVIEWED_HASH + REVIEWED_BY fields on each .sdoc item	A separate signature manifest in signatures/
Captures signer intent?	No (implicit “I’m approving this PR”)	Yes (explicit signing prompt with stated meaning, per §11.50)
Independent of underlying tool?	Hashes survive but the chain to the approver requires GitHub’s audit log	Yes (Signet manifests are self-contained; verification doesn’t need GitHub)
Meets the legal definition of a Part 11 signature?	No (it’s a content fingerprint of an approval event, not a signature)	Yes

§11.10 controls — how TRACE ALM satisfies each

§11.10(a) — Validation of systems

Required: validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.

Coverage in TRACE ALM:

• Validation of the post-processor and auto-stamp tools is in scope of the tool-qualification work outlined in the skill file (CSA package)
• The hash chain detects altered records: any post-stamp change to .sdoc content surfaces as suspect-native in the next CI run
• The CI pipeline (CI on PR) is the operational evidence that the system performs consistently

§11.10(b) — Generate accurate and complete copies of records

Coverage:

• The release evidence bundle (RTM HTML + Allure HTML + JUnit XML + index.json) is the regulator-readable copy of every record contributing to a release
• git log is the immutable history of every regulated artefact change

§11.10(c) — Protection of records to enable accurate and ready retrieval

Coverage:

• Long-term archival of the release bundle to the Design History File system
• Branch protection on main prevents force-push and deletion of regulated history

§11.10(d) — Limiting system access to authorized individuals

Coverage:

• GitHub authentication on the repo
• CODEOWNERS-gated review on regulated paths
• Branch protection’s “Require review from Code Owners” toggle enforces it

§11.10(e) — Secure, computer-generated, time-stamped audit trails

Required: secure, computer-generated, time-stamped audit trails that record the date and time of operator entries and actions that create, modify, or delete electronic records.

Coverage:

• git log records every commit to a regulated artefact, with timestamp and author
• Auto-stamp commits are authored by bioflow-autostamp[bot] with the human approver’s identity in the Co-authored-by trailer — both pieces of attribution are preserved
• Each stamping event records a triple (content hash, approver, timestamp) derivable from the commit
• Application-level audit logs (operator authentication, recording session lifecycle, exports) will land as a dedicated SRS item in a subsequent PR; the audit-log content + scope is being authored separately

§11.10(f) — Use of operational system checks to enforce permitted sequencing of steps and events

Coverage:

• The PR pipeline’s --fail-on-suspect gate enforces that drift cannot be merged without an authorising change record
• Branch protection enforces that approval must precede merge
• Auto-stamp’s CODEOWNERS-validation step enforces that only qualified reviewers’ approvals count

§11.10(g) — Use of authority checks

Coverage:

• Auto-stamp validates that the PR’s approver matches .github/CODEOWNERS for the touched paths; otherwise stamps are refused
• The auto-stamp App is on the branch-protection bypass list — only that App can push directly to main, and its identity is auditable

§11.10(h) — Use of device checks where appropriate

Required only for systems where it’s appropriate to determine if a record-creating device is valid for the source.

Coverage: Out of scope for the regulated-artefact development flow (no measurement devices involved). For the BioFlow application’s runtime device checks (Deymed amplifier protocol, etc.), see the relevant SRS items.

§11.10(i) — Determination that persons who develop, maintain, or use electronic record/signature systems have the education, training, and experience to perform their assigned tasks

Coverage: Personnel training is recorded in the Quality Management System (QMS) and is outside the scope of TRACE ALM’s tooling. The CODEOWNERS file names the qualified reviewer, but their qualifications are documented in the QMS.

§11.10(j) — Establishment of, and adherence to, written policies that hold individuals accountable

Coverage:

• Written policies live in the QMS
• TRACE ALM enforces them operationally — every signed artefact ties to a specific identity (in the case of auto-stamp, the GitHub-authenticated reviewer; in the case of Signet, the enrolled signer)

§11.10(k) — Use of appropriate controls over systems documentation

Required: controls over systems documentation including (1) adequate controls over the distribution of, access to, and use of documentation; and (2) revision and change control procedures.

Coverage:

• This documentation site is itself version-controlled in trace-alm-docs/
• Updates to the playbooks go through the same gated PR process via CODEOWNERS
• Update-cadence notes (“last verified against UI as of YYYY-MM-DD”) on each playbook page allow auditors to assess freshness

§11.50 / §11.70 — Signature manifestations and meanings

These sub-parts require an electronic signature to:

• Capture the printed name of the signer, the date and time, and the meaning of the signature
• Be linked to its electronic record so the signature cannot be excised, copied, or otherwise transferred to falsify another record

Auto-stamp REVIEWED_HASH does NOT meet this — it has no captured “meaning” and no explicit signer intent. It’s a content fingerprint of an implicit approval event, useful as audit evidence but not legally a signature.

Signet IS designed for this:

• Signet’s signing UI prompts the signer for the explicit meaning of the signature
• Signature manifests carry the printed name + date + time + meaning
• Cryptographic linking to the bundle hash ensures the signature can’t be transferred to a different record

For the technical implementation, see <SIGNET_DOCS_URL>.

End-to-end audit trail

What an FDA inspector should be able to follow, from a deployed binary back through every approval:

1. Deployed binary → installer’s SHA256 in SHA256SUMS
2. Installer SHA256 → release evidence bundle’s index.json
3. Release evidence bundle → Signet signature manifest (in signatures/)
4. Signet signature → identity + timestamp + meaning of formal release approval
5. Bundle’s RTM → every requirement linked to its verifying tests, with stamped REVIEWED_HASH
6. Each REVIEWED_HASH → the auto-stamp commit on main (visible in git log)
7. Auto-stamp commit → the merged PR (linked from the commit message), authored by bioflow-autostamp[bot] with the human approver in Co-authored-by
8. Merged PR → CODEOWNERS file at the time of merge → identity of the qualified reviewer
9. GitHub’s audit log → confirmation that the approver actually clicked Approve at that commit

Every link in this chain is verifiable independently. That’s the regulatory property TRACE ALM provides.

What auditors should ask for

When preparing for a Part 11 audit, the team should be able to produce, for any released version:

• The signed release-record manifest (Signet’s output)
• The bundle that was signed (or its hash + a means to reconstruct)
• The git history of the requirements at the time of release
• The CODEOWNERS file at the time of release
• The CI run results for the release build
• Personnel training records for everyone whose identity appears in any approval (out of scope for TRACE ALM tooling — comes from the QMS)