An auditor picks one change and asks three things. Who approved it and when. Was the checklist done before it went live. Did the people who run the system read the runbook for that version. In most Jira and Confluence setups the first answer lives in an approval tool, the second in a checklist, and the third in a Confluence page where nobody can prove who read what.
I build three Atlassian Marketplace apps, Approval Flow, Checklist Flow and Attestation Flow, so I am biased. Each one keeps its own tamper-evident log and its own export. That is fine until someone asks about the whole change, and then you are stitching three files together by hand. In the current version of Approval Flow that stitching happens in one place.
You run the evidence pack in Approval Flow with a JQL search, for example every change of one type in a quarter. For each work item you get the approval decisions, and from Checklist Flow the state of the checklist. If the work item has Confluence pages linked to it (the normal "Link Confluence page" link), the pack lists those pages and shows what Attestation Flow reports for each: how many people had to acknowledge, how many did, how many are still outstanding, and the head of its audit log. No names come across from Attestation Flow, only counts and that chain head.
The pack is a PDF, a CSV and a JSON file, and all three carry the same pack hash.
It can also read Jira's changelog and check whether every required sign-off was given before the work item first entered a status you choose, say "In Progress". It lists exceptions: done without all required sign-offs, a sign-off removed after work started, an approver who also started the work when separation of duties is on. You have to tell it which status means "work started", because finding that out from the workflow needs admin rights I do not want the app to hold. When it cannot decide, it says "not determinable" instead of guessing.
The pack hash is a SHA-256 over every audit-chain head in the pack plus the time the pack finished. The JSON file contains the exact input, so an auditor can sort the keys, hash it again and compare. That shows which heads the pack listed, and that nobody edited the file afterwards.
It does not show that Checklist Flow or Attestation Flow are right. Those two apps hand their numbers over through properties on the work item and on the page, and anyone who may edit the work item or the page can also write a property through the REST API. So the pack labels that part "not verified", in words, in every format. The Jira changelog is labelled as Jira's own record and sits outside the hash. Only the Approval Flow part is the hash-chained one. I would rather say that in the file than have an auditor find it.
The part I am least sure people want is the next one. On an approval requirement you can pick people under "Ask for acknowledgement of the linked pages". When that requirement is fully approved, Approval Flow writes a request on each linked Confluence page. Attestation Flow, if it is installed, adds those people as required readers of that page version and labels them "requested via Approval Flow (not verified by Attestation Flow)". It only adds readers. It never removes anyone and never touches your own reading requirement. It asks once per requirement and page version, so approving again does not repeat it, and a new page version gets a new request. If Confluence refuses the write, the approval still stands and the audit trail records that the request failed, with the reason.
What it costs you: Approval Flow becomes an app that can also be installed in Confluence (Jira stays required, Confluence is optional). That is a major version and it needs new Confluence permissions, so a Jira admin has to accept them on upgrade. One of those permissions, the one for page properties, would technically also let an app edit a page. The app writes only one property of its own on a page, nothing else, but you should know the permission is wider than what it uses. If you never connect Confluence, the pack says "Confluence is not connected" and carries on.
What I have tested: one dev site, a handful of work items. There the whole chain worked. A linked page showed Attestation Flow's count in the pack, a fully approved requirement left its request on the page, and the pack hash covered five chain heads from the three apps. I moved a work item to In Progress and Done with no sign-offs, on a workflow with no validator, and the pack flagged it as started before approval and listed two exceptions. A work item whose requirement was not marked as required came out as "not determinable".
What I have not tested: a large site. I do not know how long a pack of many work items takes, because each one reads its own changelog. And nothing here touches JSM's native approval step. The gate runs beside it, not inside it.
If you hand an auditor one file per tool today, which do they ask for first, the approval, or proof that the people running the thing read the instructions?
