History and the audit trail
Where to find it
Every data product has a History tab beside Overview, Baseline estimation and Setup. It shows everything that has happened to that product, newest first, and it is visible to every member of the organization — not only admins.
Activity, under Govern in the sidebar, is the same record across the whole organization, filterable by who acted, what they did, whether it succeeded, and when.
What is recorded
Every action that changes something. Not reads — asking what happened does not itself become something that happened, or the log would grow faster than the activity it describes and bury what you were looking for.
| AREA | EXAMPLES |
|---|---|
| Products | created, renamed, edited, status moved, deleted |
| Budgets | set, changed with its reason, cleared, enforcement changed |
| Estimates | proposed, committed, superseded, discarded, linked to a product |
| Governance | policies and rules created, edited, assigned, severity changed |
| CI | runs reported, guardrails blocking a merge, projects registered or renamed |
| Access | members invited and joined, roles changed, members removed |
| Integrations | connected, disconnected, credentials rotated, verified |
| Account | organizations created and deleted, settings changed, identity provider configured |
A rejected change records nothing. If the request was refused, nothing happened, and a record of a change that did not happen is worse than no record at all.
An edit that changes nothing records nothing either. Saving a form without touching a field is not an edit, and treating it as one is the fastest way for a reviewer to stop trusting the feed.
integration.credentials_rotated — that it happened, by whom, and when. The credential itself never appears. A log that carries the secrets it describes is the thing an attacker wants most.Names are frozen at the moment of the action
Each entry stores the names as they were when it happened. Rename a product and its earlier history still says what the product was called at the time.
This is deliberate and it is the opposite of what most feeds do. If entries resolved names live, one tidy-up would silently rewrite eighteen months of history — nothing deleted, every hash still valid, and the log now reporting something that was never true.
Deleting something does not delete its history
Records outlive what they describe, including the record of the deletion. There is no foreign key that could take a product's history away with the product, and the name is captured before the row goes.
Routine CI runs are collapsed
A pipeline that runs nightly and changes nothing would push every human decision off the first page within a week. Those runs are hidden by default and revealed by Show routine CI runs. A run that was blocked by a guardrail is never collapsed — it is the one CI event nobody wants hidden.
Who can read what
| ROLE | SEES |
|---|---|
| Anyone in an organization | That organization's activity, including the History tab on every product in it |
| Account admins | Every organization in the account, plus account-level actions such as account policies and identity provider changes |
Account-level actions are visible to account admins only. An account policy belongs to no single organization, and showing it inside one would put a fact about all the others in front of its members.
Proving it has not been altered
Each event is hashed together with the hash of the one before it, forming a chain per account. Changing a stored value, deleting a row or reordering the sequence all break the chain, and the break is localised to the affected entries rather than smearing across everything after them.
- The trail lives in its own database, reached by a role that can append and read and holds no statement that could alter a row.
- Chain heads are copied hourly into a second database and into object storage under a compliance lock that the storage service itself enforces. Rewriting the audit database and recomputing every hash produces a chain that verifies against itself and disagrees with both copies.
- Verification runs nightly, and an account admin can run it on demand.
Erasure requests
An account admin can honour an Article 17 request for a person. Their name, the address they acted from and the browser they used are removed from every entry. The entries themselves remain, still counted, still attributable to one consistent pseudonym — so “everything this person did” keeps resolving after their name is gone.
Erasure breaks the hash chain over the affected entries. That is intended: a rewrite that left the hashes matching would be a rewrite nobody could detect. What separates it from tampering is the receipt, which names the request, the legal basis, the volume affected, when it ran and who ran it. Verification reports those entries as erased and links the receipt, never as altered.
How long records are kept
Thirteen months. Older records are removed monthly, and the removal leaves its own receipt stating the window and the volume. The cut is recorded per account so that verification reads it as the start of what remains rather than as missing history.
When the record starts
Recording began when the feature shipped, and there is no backfill. A product with no entries shows the date recording began rather than a blank panel — because “nothing has been recorded yet” and “nothing has ever happened” are different statements, and only one of them is true.