Campaign PDF: record, snapshot and verification
The PDF tab of a campaign’s drawer holds the campaign’s stored, authentic PDFs. A stored file does not change: a later setting or rename does not rewrite what was true when it was generated.
Before you start
Section titled “Before you start”- The Campaign add-in is on, and you can see the campaign (its site is one of yours).
- Permissions: viewing and downloading needs campaign:view. Snapshots can be made by those who decide on the campaign (plan, approve, any gate, or admin). A corrected final version needs campaign:gate_close or campaign:admin.
The final record
Section titled “The final record”- Generated automatically when the campaign enters the Closed phase — by button, by gate signature or by an automatic step.
- Generated once per campaign. If it could not be generated at closing, the background job catches up, or you can generate it on the PDF tab.
- The paper’s header names the generator as “system (automatic)”. On the PDF tab the triggered by name stands next to it: the colleague whose closing step started it (a record caught up by the background job has no trigger).
Snapshot
Section titled “Snapshot”- Can be requested at any time (e.g. for approval or an audit), in any phase.
- The paper’s title is “Campaign snapshot”, its state “Snapshot · v1”, with a framed line below: “Snapshot, not final”. Snapshots are numbered (v1, v2, …).
Correction: a new final version
Section titled “Correction: a new final version”- If the closed campaign’s record needs a correction (e.g. a name was wrong), Corrected final version generates a new version. A reason is required (5–500 characters) and is printed on the paper.
- The old version stays, marked “superseded” in the list. The new version states which version it supersedes.
- If nothing changed since the latest final version, no new version is generated.
What the PDF contains
Section titled “What the PDF contains”The campaign number and the product stand in the header (on further pages the running header shows the number); the tables do not repeat them.
| Section | Content |
|---|---|
| Plan | site and plant, planned window and quantity, status, phase, revision, approver |
| Progress | actual quantity (or “no data” with the reason), the number of closed logs |
| Plan revisions | the approved plan’s versions, who changed it and why |
| Phase timeline | per phase and per interruption: from when to when it ran |
| Gate signatures | the signed or invalidated gates: the signer, the time and the chain link’s hash |
| Start-up list | per item the result, the state, who completed it and when, and the photos’ SHA-256 hashes |
| Open items closable after start-up | what was still open at generation |
| Training status | the training items’ roster with exam or attendance state |
| Phase history | every link of the hash chain (event, time, actor, hash) |
| Hash chain | chain integrity, number of links, chain head |
On paper the gate, photo and phase-history hashes show their first 16 characters (enough to identify them); the chain head is printed in full. The check page shows the PDF file’s full SHA-256 hash.
The check page (QR code)
Section titled “The check page (QR code)”The QR code in the PDF header opens the check page on the company’s own address. It opens without signing in, but shows only the document’s data (kind, version, generation time, hash, file and chain state) and its validity — not the campaign’s content:
| Verdict | Meaning |
|---|---|
| Authentic | this is the latest final version |
| Authentic, but superseded | a corrected final version has been generated since |
| Authentic snapshot | not a final record |
| Cannot be checked right now | the stored file is temporarily unavailable; this does not mean the document is not authentic — try again later |
| Not authentic | the stored file or the hash chain actually does not match — do not accept it |
The SHA-256 hash on the page must match the hash of the PDF file in your hands. A signed-in colleague with access to the campaign also sees an “Open in the system” link.