PDF Exports & the Audit Pack¶
Audience: quality managers, and anyone preparing copies for an audit or a notified body.
LQMS renders controlled documents to PDF server-side — the same for everyone, recorded as an
audit event, and stamped as an uncontrolled copy. The basics of a single document's PDF (the
Download PDF action, exportable states, the per-page uncontrolled copy band, the honest
degradations of Mermaid/math/doc: links) are covered in
Documents & the lifecycle §8. This chapter covers what comes after the
single document: the scope audit pack (a whole scope at once, in two shapes), how risk content
prints, and the derived-traceability annex.
Judgment note. This is a new chapter rather than an extension of documents-lifecycle §8: the single-document PDF is one action on one version, while the audit pack, the merged/zip choice, and the traceability annex are their own subject with their own audience (audit preparation). §1 below deliberately points back to §8 for the single-PDF fundamentals rather than repeating them.
1. The export menu — and which shape to pick¶
On the documents view, the actions menu (⋮) offers the scope-level pack in two shapes. The order is deliberate:
- Audit pack (single PDF) — leads the menu. One merged PDF: a cover, a clickable table of contents, then each document as a chapter with its own bookmark subtree and continuous page numbering. Its internal links work in every PDF viewer — that is why it leads. This is the reviewer's copy.
- Audit pack (zip) — a zip with one PDF per document, plus manifests (§3). It carries a caution line: "Cross-document links open only in Adobe Acrobat."
Both render every currently-effective released version the caller can see in the scope, through the same PDF path as a single document (same identity header, same per-page uncontrolled-copy band, same audit event). They are separate artifacts — you get the zip or the merged PDF, never both bundled together. A spinner shows while a pack is being prepared, and the download starts automatically when it is ready.
The pack's curated sibling. An audit pack answers "what is in this project right now?" — it is always the currently-effective set, and it is regenerated fresh on every export. It cannot answer "what is the technical file for device X?", which needs chosen versions, arranged under a regulatory skeleton, and frozen at a point in time. That is a technical dossier, and it is a separate object with its own surface, its own DRAFT → ISSUED lifecycle, and the same two export shapes as this pack. See How do I assemble a technical dossier?.
Citation closure. By default a pack also pulls in the documents your scope's documents cite — governing procedures in another scope, for instance — each at its effective released version, as long as you are allowed to see them. The claim of a pack is "what the auditor needs for this scope", and a cited document the auditor cannot open would be the surprising omission.
2. Why the zip warns about Acrobat¶
In the merged PDF, a link from one document to another is an internal jump within the single file, so it resolves in any viewer. In the zip, a link from one PDF to a sibling PDF is a cross-file ("remote go-to") link — and following those needs a viewer that supports them: Adobe Acrobat Reader and most full PDF viewers do; macOS Preview does not. (It was byte-verified that Preview simply ignores such links.) Keep the zip's files together in one folder so the links can resolve, or — for navigation that works anywhere — use the merged single PDF instead. The zip's own README.txt says exactly this.
3. What is inside the zip¶
The zip holds, at its root:
- One PDF per document — the currently-effective released version, named by human id and version.
- traceability-report.pdf — the scope's derived traceability report (§6), placed before the
manifests and listed + SHA-256-hashed in the manifest like every other entry. Present only when
you hold
VIEW_TRACEABILITYin the scope. - README.txt — a plain-language orientation: what the pack is, the cross-file-link viewer reality above, and the completeness rule below. It is written first so it stays useful even if a download is cut short.
- manifest.json and manifest.txt — describing the set and carrying a SHA-256 of each PDF, so the bundle is verifiable evidence-grade.
The completeness marker. manifest.txt is written last. So the rule is simple: if
manifest.txt is present and the archive opens as a valid zip, the pack is complete; if it is
missing, the download was truncated and you should re-export. A truncated pack is detectably
incomplete rather than silently short.
4. Risk content in the PDF¶
A risk-analysis document's :::risk and :::risk-control blocks render in the PDF as formatted
blocks — key, labelled attributes, and body — not as raw fence text. Scores print as the recorded
tokens (e.g. S3 · P1 · P2 — High), never as a computed equation, exactly as on screen (see
trace-items §4). This is the released risk table an auditor reads in the
controlled copy.
5. The derived-traceability annex¶
The frozen document content shows the risk/control content — but a control's implementation and verification are links, not document content, and so are honestly absent from the frozen record. To close that gap without blurring the boundary, a PDF export of any version that defines risk or risk-control items carries a clearly-bounded annex after the document content:
Derived traceability — as at export (not part of the controlled content)
The annex has, in content order:
- Risks — one row per risk defined in the document: Key | Mitigated by | Gaps. Mitigated by names the control keys (with the defining document's id when a control lives elsewhere); Gaps carries the derived risk-level flags — with the accepted-without-reduction semantics intact (an acceptable initial risk with no control and no residual is complete, so it shows no flag).
- Controls — one row per control defined in the document: Key | Mitigates | Implemented by | Verified by | Gaps.
When a document defines both, both sections appear (risks first). A document defining no risk items gets no annex — there is no empty scaffolding.
Three things make the annex honest:
- "As at export". Unlike the frozen content, the annex is derived live at the export moment. The same version exported on two days may carry a different annex if links changed between — that is by design, and the label says so. The annex is never part of the document's content hash.
- Visually separate and labelled, so an auditor can never mistake link-derived rows for reviewed content.
- Permission-conditional. The annex derives from the same data the traceability views show, so
it is included only when the exporter holds
VIEW_TRACEABILITYin the scope. Without that permission the PDF renders without the annex — no placeholder, no error. The annex must never become a backdoor around the per-view gating (see traceability-workspace §1). This is why an export may legitimately lack the annex: either the document defines no risk items, or the exporter lacksVIEW_TRACEABILITY.
The annex appears in all export shapes — the single-document PDF, each zip pack entry, and each merged chapter.
6. The scope traceability report¶
Distinct from the per-document annex above, the scope traceability report is a whole-scope
artifact: one derived PDF compiling the scope's entire traceability picture — a front-page gap
digest (unsatisfied/unverified requirements, the risk gap counts, coverage-rule gaps, suspect
links), then sectioned detail tables for the requirement chains, the requirement-verification status
of each software requirement (its evidence class — unverified / planned only / verified), the risk
chains, and the document-relation coverage. It is generated live from the same read models the traceability
workspace views show — nothing is stored — so it can never disagree with the on-screen views or the
requirement-chains CSV. You download it from the Traceability workspace hub (see
traceability-workspace §1) via its Traceability report (PDF) action;
it is VIEW_TRACEABILITY-gated and carries the same honesty chrome as every export — the "derived —
as at export" heading and the uncontrolled-copy band, with the explicit statement that it is not
controlled content.
In the audit pack. The report also rides in the scope audit pack: in the zip as
traceability-report.pdf (listed and hashed in the manifest like every other entry, §3), and in the
merged single PDF as a closing chapter. Its inclusion is permission-conditional — the pack
carries the report only when the exporter holds VIEW_TRACEABILITY in the scope, exactly the
rule the per-document annex follows (§5). The pack must never become a backdoor around the per-view
gating.
Milestone snapshots. To freeze the traceability state at a milestone — a design review, a release gate — export the report and attach it to the review record as a file attachment (the Attachments section, see documents-lifecycle §2). That gives you a reviewed, frozen snapshot as a record, without the tool pretending derived data is controlled content. There is deliberately no separate "snapshot" entity — the record + file-attachment machinery already does it.
Governing decisions: ADR-0074 (server-side PDF, uncontrolled-copy band, honest degradations, the merged-pack render path, and the 2026-07-20 derived-traceability-annex clarification — risk + control rows, "as at export" boundary, VIEW_TRACEABILITY condition), ADR-0083 (the audit pack — zip with hash manifest + the merged reviewer's copy, ADR-0060 §5 packaging — and the technical dossier, the curated deliverable this pack is the uncurated counterpart of), ADR-0087 (the scope traceability report — one derived PDF over the read models, the hub download + the permission-conditional audit-pack entry, milestone snapshots via attach-to-record), ADR-0079/0082 (the risk content the annex derives from), ADR-0069 (file attachments — the milestone-snapshot vehicle). Distribution control: ISO 13485 §4.2.4.