Evidence and the audit trail

Who this is for: agents, and whoever has to answer an auditor.

Every governance action Concessa records is appended to a hash-linked chain, one per project. Entries are numbered from one, each sealed with a hash of the one before it. Nothing in the product edits or deletes an entry, and there is no path that could — which is what makes the export evidence rather than a report.

Where to see it

In the issue panel, under Audit trail — this change’s own history. Note the numbering skips: entries are numbered across the whole project, so the gaps are other changes’ entries, not missing ones. Approval requests and decisions are recorded against the approval rather than the change, so they appear in the export but not in this panel — the Approvals section above it is where you read those.

Everywhere else, the chain’s verdict appears as a lozenge — in the panel header, on the settings page and on every export. It is recomputed from the first entry every time, not cached, and it always covers the whole project: the count it gives is the project’s total, so in the issue panel it will normally be larger than the number of rows in the table above. It is not scoped to the change you are looking at, to what is on screen, or to any period of time.

Taking an export

Your project → Concessa → Evidence.

1. Scope — Whole project, or One change (which asks for an issue key).
2. Format — JSON is lossless and can be re-verified offline. CSV opens in a spreadsheet.
3. Take an export.

Select the text and copy it. There is no download button, and that is deliberate: producing a file would mean sending your governance record out of Atlassian to somewhere that could build one. Concessa makes no outbound call of any kind, so it hands you the text instead.

Taking an export is itself audited. Who exported what, and when, is part of the record. It is not the only read in the product that writes any more: opening the CAB workbench can also create meetings from the schedule your administrator set — see guide 7 for what that materialises and why.

Both formats now also carry a meetings section (date, status, attendance summary, changes reviewed) and an actions section (the commitment and its state). A project with no CAB meetings gets both sections empty rather than missing — “none” is a fact worth stating, not a gap.

Choosing Whole project also offers a metrics period — this month, last month, this quarter, last quarter, or a custom range — directly above Take an export. Every change record now also carries its recorded outcome and post-implementation review, and the audit section carries an applied column. See “Metrics” and “Reading the applied column” below for what these mean and how to read them.

The chain is always verified across the whole project, even for a single-change export — an entry tampered with elsewhere in the project invalidates the proof for everything.

If the chain is broken

Illustration — not a screenshot.

Do not use the export. The message names the entry that failed. There are three ways a chain fails verification:

Any of these is an incident, not a bug report: raise it through ../runbooks/incident.md before anybody relies on the governance record.

What the export proves, and what it does not

It proves that the entries it contains are internally consistent and unaltered since they were written, and that none is missing from the sequence.

It does not prove that what was recorded was true. Concessa records that Priya approved OPS-142 at 09:14; it cannot tell you whether Priya read it. Nor does it cover anything that happened only in Jira — the issue’s own history is mutable by administrators and carries no integrity proof, which is precisely why this chain exists alongside it.

What is in the trail

Every change created and updated, and every status change. Every approval requested, approved, rejected, withdrawn and rescinded — an approval is rescinded when a change’s dates move outside the window it was given for (guide 3). Every freeze window created, deleted and overridden. Every change of who has access, and every change to which issue types are governed.

On the CAB side: the schedule and the standing agenda whenever either is set, every meeting materialised, held or cancelled, every change of a meeting’s attendees, attendance or agenda, every change attached to or detached from a meeting, every change marked reviewed at CAB, and every action raised, updated, completed or reopened.

And every export.

Since the change-outcome release, four more actions: an outcome recorded, an outcome revised, a post-implementation review saved, and one corrected.

Reading the “applied” column

From the change-outcome release, every entry in the export’s audit section carries an applied value. This exists because of a rule that has been true of this product from the beginning, made visible for the first time: Concessa records before it mutates — the audit entry is written first, so that if the write that was meant to follow it is ever refused, the record still shows what was attempted rather than nothing at all. Until now, a refused write was rare enough that nobody needed a way to tell it apart from a successful one just by reading the export. It still is rare. It is no longer invisible.

Only applied and superseded entries are counted in the metrics below.

To reproduce the walk yourself: every change-record write shares one updatedAt. Each entry that writes the record carries the value it expected to find (expectedUpdatedAt) and the value it wrote (nextUpdatedAt). Starting from the row’s current updatedAt, find the entry whose nextUpdatedAt equals it — that entry is applied, and its own expectedUpdatedAt is where you look next. Repeat until you reach an entry with no expectedUpdatedAt (the record’s creation) or find nothing more that matches. Anything you find two of at the same step — two entries both claiming the same nextUpdatedAt, or the same action twice from the same starting point — is where the walk stops and everything from there on is unknown-tie, including entries you never got to. A double-click that fired a request twice is the ordinary way this happens; it is caution, not a sign of a conflict actually occurring.

An entry marked not-applied in the panel’s own audit trail reads: “— not saved: another update to this change was saved first, or the save failed.” Concessa does not assert which, because it cannot know from the chain alone.

Metrics

Only a whole-project export carries metrics. A single-change export has no population to compute a rate over. Choose the period you want on the Evidence tab before taking a project-scoped export — the export states the period and the time zone it was computed in, in words, alongside every figure.

The time zone is yours, not the project’s. There is no such thing as a project’s time zone in Concessa. Two people exporting the “same” quarter in different zones can get different figures for changes near a boundary — an export taken in Europe/London and one taken in America/Los_Angeles will not always agree on which quarter a change carried out at 23:30 UTC belongs to. If you need to check somebody else’s figure, reproduce their export in the zone it names, not your own.

What you see is what you were shown. Metrics are computed only over the changes your own visibility already includes — the same changes the rest of the export shows you. If your site restricts who can see certain issues, a metric can differ between two people exporting the same project on the same day, for the same reason two people’s exports can differ in visibility already. A whole-project export states, as a single unsplit number, how many change records it could not count at all — deleted, moved, or you were not entitled to see them — without naming which. That number is not folded into any rate; it exists so a rate is never silently improved by a record going missing.

Every metric in the export states its own numerator, denominator and attribution rule as text — this table is the same wording, for reference:

For a change management background: M2 and M3 are the “successful” and “unsuccessful” change rate most change-management tooling already reports. For an ISO/IEC 20000-1 audit: M1 through M6 are where clause 8.5.1’s “review changes for effectiveness” is evidenced; M11 is where “unsuccessful changes are reversed or remedied” is evidenced, and M10 is where unauthorised changes are evidenced. Sub-clause numbering is not stated here — check it against your own licensed copy of the standard before quoting it externally.

Translating a Concessa outcome for an auditor who knows a different vocabulary:

Routing a conclusion back into governance. The metrics answer “what happened”. What to do about it is a CAB decision, not something Concessa infers for you — record the conclusion as a CAB action (guide 7), so the decision itself is audited alongside the figures that prompted it.

Changes from before outcome recording existed. A visible cut-off date, recorded once at release, marks when outcome recording began. Changes approved before it carry no expectation that an outcome was ever going to be recorded — they are counted and listed under M7’s third part, separately from the ordinary backlog, and raise no warning in the panel. This is not a gap the export hides: it is stated as what it is, so nobody is tempted to invent history for a change that was approved before there was anywhere to record what happened to it.

What this guide does not cover

What to do once a chain has failed — that is ../runbooks/incident.md. Data subject requests are ../runbooks/dsar.md.