Use case
An approval that says what it approved
In an audit, "this pull request was approved" is not an answer. The question is which code was approved, by whom, and whether it is the code that shipped.
Approvals are bound to a commit
Every review records the exact commit it was submitted against. When the branch moves, the forge knows the approval is stale, and a branch rule can dismiss it automatically rather than leaving a human to notice.
The conversation is part of the record
Review threads are never deleted. A thread whose line has since changed is marked outdated and stays readable with the code it was written about, because the discussion that produced a change is the evidence of why the change was made.
Gates that are enforced, not documented
- Required approvals, with stale ones dismissed when the branch rule says so
- All review conversations resolved before merge, when required
- Named checks passing on the exact head being merged
- A linear history, when a merge commit would obscure the sequence
Self-hosted, so the boundary is yours
Source code, review history, and identity all sit inside your own network boundary, which is usually simpler to argue about than a third party's compliance posture.
Make the audit trail a by-product of the workflow
Nothing here has to be reconstructed later, because it was recorded at the time.