Signature manifestation

In one sentence

When you export an approved document to Word, or open its print preview to save a PDF, QFormance appends a §11.50 manifest block that identifies the signer, the meaning of the signature, the version, the file hash, and who printed the copy — so the exported file is self-identifying when it travels outside the system.

Three things to remember

This is a manifestation, not a cryptographic signature. §11.50 requires that the meaning of an electronic signature appear on any human-readable form of the record. The manifest block is that printed identification — it's not a PKI signature on the file's bytes.
It appears on approved records only. Exporting a draft or unapproved revision skips the block. The manifest is a record of a real signing event; it doesn't appear for a record that hasn't been signed.
Word and PDF carry the same fields. Word exports include the block in the file itself; PDF (via the browser's print dialog) reveals a print-only block at the end of the printout.

What's in the block

The block carries these fields, in this order:

Field	What it identifies
Meaning	What the signature means in your QMS — typically Approved for documents, Reviewed / Acknowledged for other workflows
Signed by	The signer's printed full name, with their role at the time of signing in parentheses
Signed at	UTC timestamp of the approval, formatted human-readably
Document	Document number and title
Version	The approved version (e.g. 2.3) — matches the snapshot the export was generated from
Status	Approved (or whatever the workflow's signed-state label is)
File SHA256	For external documents only — the SHA256 of the approved file's bytes. Lets a recipient verify the file they received matches the version of record
Printed by	The user who initiated the export, with their role
Printed at	The export's render time, in UTC

Together those fields satisfy the §11.50 requirement to print the meaning, the signer, the datetime, and (under most interpretations) enough context to authenticate the printout against the source system.

Where it appears

Word export. The manifest block lands at the end of the Word file, after the document body, whenever an approved version exists. Drafts omit the block — there's no signature yet.
PDF / print preview. The document detail page hides the manifest block on screen and reveals it only when you print. Use the browser's Print → Save as PDF (or print to a physical printer) and the block appears at the end of the printout.

In both cases, the surrounding output also gets a print footer reading "Uncontrolled When Printed" (or "OBSOLETE — Do Not Use" if the document has been retired), so a stale paper copy is identifiable as such.

What this is not

It is not a cryptographic signature. The manifest is a printed identification block — it tells a human reader who signed and when, satisfying §11.50's "each electronic signature shall be linked to its respective electronic record" manifestation requirement. It does not cryptographically sign the file's bytes; nothing about the printout uses PKI / public-key / detached digital signatures.

Cryptographic signing is not currently available in QFormance. If your customer or inspector wants detached PKI signatures over exports — for example, a PAdES-signed PDF that a third-party verifier can validate without contacting QFormance — that's a separate workflow you'd handle outside the system today. If you need it as a feature, raise it with your account contact; it's a known request, not a shipping product.

The File SHA256 field gives you most of what PKI gives you. For external documents, the manifest carries the SHA256 of the approved file's bytes. A recipient who has the file and the manifest can re-hash the file and confirm it matches — proving the bytes on the page are the bytes that were approved. That's content integrity without PKI infrastructure; an inspector typically accepts it.

When the block is omitted

The manifest only appears when there's a real signature to manifest. It's skipped when:

The document is still in Draft — no approval has happened yet.
The document is in Under Review and has never had a prior approved version — same reason.
An admin or owner generated an export of a not-yet-approved revision while a previous approved version exists — in this case the export carries the previous approved revision's manifest, with the version-of-record clearly labelled, so the printout still identifies a signed state.

Why this matters — 21 CFR §11 framing

§11.50 — Signature manifestations — requires that any signed electronic record, when displayed or printed in human-readable form, includes the printed name of the signer, the date and time the signature was executed, and the meaning of the signature. The manifest block satisfies all three.

§11.10(e) — Audit trail — separately covers operations on the record over time. Read the manifest together with the record's History tab (and its print history view) to get both a snapshot of the signed state and the chain of changes that led to it.