Approval Record

Origin & evolution

The approval record descends from the audit trail, a discipline formalised in accounting and later written into law. After the corporate scandals of the early 2000s, regulations such as the Sarbanes-Oxley Act of 2002 made tamper-evident records of who authorised what a legal requirement for many organisations. Software systems absorbed the same demand: version-control history, signed commits, and change-management logs all exist to answer "who approved this, and can we prove it?".

Gene Kim, Kevin Behr, and George Spafford's *The Phoenix Project* dramatises this failure mode as part of its broader argument. The book's central frame is the "Three Ways" — flow, feedback, and continual learning🧠LearningValidationAn insight gained from an experimentView reference → — applied to IT work, but one of its recurring concrete examples is change that goes out unauthorised and unrecorded, leaving an incident🚨IncidentDevOps & PlatformA production incidentView reference → response unable to reconstruct what happened or who sanctioned it. By that reading a reliable account of approved changes is one of the preconditions for the feedback the book is arguing for, not bureaucratic overhead.

The thinking has sharpened around immutability and accountability. A useful approval record cannot be edited after the fact, because an editable record proves nothing. It also names a person rather than a role, so accountability lands on someone specific. The honest debate in practice is about depth: a bare timestamp satisfies the letter of an audit while a recorded rationale satisfies its purpose, since the reason is what lets a future reader understand why the call was made.

How it works in practice

A migration workflow halts at a review gate. The database lead approves, and the system writes a record: actor j.okafor, timestamp 2026-04-12T14:08Z, gate prod-migration, decision approved, reason "rollback script tested against staging snapshot, runtime under two minutes". Six weeks later the migration is blamed for an incident. The investigation🔍InvestigationEngineeringAn investigation into an issue or incidentView reference → reads the record, sees the rollback was tested, and redirects the inquiry toward the snapshot's staleness rather than the approval itself. The record did its job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference → by making the original judgement legible long after the moment passed.

Betsy Beyer et al.'s *Site Reliability Engineering* makes a related point from the release🚢ReleaseProduct SpecificationA shipped version of the productView reference → side rather than the postmortem🩻PostmortemDevOps & PlatformA post-incident reviewView reference → one. Its treatment of release engineering stresses reproducible, recorded rollouts — a durable account of what was released and by whom — so that a later investigation can establish exactly which change reached production. That is the same evidentiary discipline an approval record applies to the authorisation step: the SRE book is careful to keep its blameless postmortems focused on systemic causes rather than on whether a change was sanctioned, but it still depends on the underlying record being trustworthy enough to reconstruct the sequence of events.

Approval record vs. its neighbours

• Review gate is the checkpoint that asks the question; the approval record is the answer, written down and frozen. The gate can be crossed many times across many runs, and each crossing leaves its own record.
• Decision is a broader product or strategic choice, often with options weighed and reasoning developed over time. An approval record is narrower and procedural, the act of clearing a specific gate, though a weighty approval may itself reference a decision.
• Workflow run⏯️Workflow RunWorkflows & AgentsAn execution of a workflowView reference → is the execution the approval unblocks. The record belongs to a moment inside a run, marking the point where a human authorised the run to continue.

In the graph

In the Unified Product Graph, an approval record sits in the automation region as the evidence🔎EvidenceValidationData supporting or refuting a hypothesisView reference → layer beneath review gates. Its defining connection is review_gate_approved_via_approval_recordReview Gateapproved viaApproval Recordhierarchy, which binds each record to the gate it cleared. That single edge is what turns an approval from a transient click into a permanent, queryable fact: the graph can later trace any shipped change back through the gate that guarded it to the named person who signed it off and the reason they gave.