Why Isn't a Merged Pull Request the Same as an Approval?

Challenge: Can you prove that a merged change is authorized for the action that follows?

Pick one of the last five consequential changes we merged. If we cannot show who authorized the next action for those exact bytes, under which current policy, and with what current evidence, we are one deployment away from paying twice: once to ship the work and again to reconstruct whether we were allowed to use it.

A merge proves that code entered a branch. Approval to act requires current scoped authority and evidence that still matches the exact change. Without that distinction, the business can release a billing, security, or customer-facing change that nobody was authorized to put into use.

This does not mean every merge lacks authority. A current policy can grant a bounded actor authority for a defined action class, and an action-specific decision can cover an exception. The practical question is whether the authority actually covers this actor, action, scope, revision, and evidence now.

Have a workflow that is costing time, money, or customer confidence? Just In Time AI can help you find the smallest valuable improvement, implement it as a secure, compliant AI system, and prove the business result before expanding. Explore AI Systems Setup and Coaching.

What: What must a durable approval preserve?

A durable approval is a record that lets the next accountable person see the decision, its authority, and its limits. It joins two separate things: evidence that an action is eligible to be considered, and authority to take that action.

This applies before an externally visible, high-risk, or promotion action. An agent, person, CI job, or system can produce evidence. A current policy or authorized decision-maker supplies authority. The executor checks that the action still fits both records before proceeding.

Keep the decision work proportional to the stakes. Routine changes with no meaningful trade-off do not need a manual decision merely because a pull request exists. When a change affects production, authentication, billing, customer data, significant cost, or several teams, record the intended outcome and success conditions, compare credible options, and use a reversible test when available before committing to the action.

Evidence-Gated Action provides the evidence boundary. Fresh, inspectable, scope-bound evidence can satisfy a gate; it does not grant authority. Approval Workflow provides the authority boundary: unapproved work needs explicit approval before it continues.

The public Evidence-Gated Action record makes the minimum evidence visible:

Evidence-Gated Action:
- gate: staging-green-before-main-pr
- action: open staging -> main promotion PR
- scope: your-org/your-repo@staging commit <sha>
- evidence: ...
- method: ...
- timestamp: <ISO-8601>
- actor: qa-agent + reviewer
- result: pass

That record is evidence about a defined action. The authority record remains separate. When a merge itself carries authority under policy, that policy must name the exact class, actor, conditions, and scope. When any binding changes, the old authority stops applying.

The enforcement source matters too. Keep the policy, approval record, validator, and required workflow behind a boundary the candidate cannot rewrite. The candidate may supply the exact bytes being evaluated as data; it must not supply the code or authority record that decides whether those bytes are approved.

The companion technical guide, How to Record a Durable Approval a Merge Cannot Fake, provides a runnable example for a consequential but reversible release.

Artifacts

• Evidence-Gated Action -- current default branch defines the evidence boundary readers can inspect now.
• Approval Workflow -- current default branch defines the explicit authority boundary readers can inspect now.
• JitNeuro repository provides the public source context for both records.

Why: Why does current scoped authority matter to the business?

Missing approval context creates work twice. People re-read the change, reconstruct who decided what, and delay a customer-facing action while they establish whether they are allowed to proceed. If the uncertainty repeats, the business also spends staff time, AI calls, token charges, compute, and wall-clock time re-deriving a known decision.

Use your own figures rather than a borrowed savings claim:

reconstruction cost = reconstructions x [(people-hours x loaded hourly rate) + AI token cost + compute or wall-clock cost + delay cost]

This is an illustrative formula, not a measured result. It makes the trade-off visible: durable authority can protect time, reduce the chance that an unsupported change reaches a customer, and keep a governance rule credible enough to follow.

A related business question is what it costs to give systems a meaningful stop signal: I gave my agents a veto. Here is what it cost me.

Bottom Line: What decision should an accountable operator make before acting on a merge?

Use this three-part decision before relying on a merge:

1. Select one consequential action: Choose a merged change whose downstream use could affect customers, financial operations, security, or operations.
2. Ask for both records: Have the responsible operator show the current evidence and the current policy or decision that authorizes the exact actor, action, revision, scope, and criteria.
3. Stop on a gap: If either record is missing, stale, invalidated, or outside scope, keep the dependent action blocked until the gap is resolved.

That decision protects staff time for new work, reduces avoidable release delays, and lowers the chance that an unsupported change reaches customers.

When that uncertainty repeats, it frustrates the team and erodes compliance credibility because people stop trusting which decision governs. Each reconstruction also consumes staff time and can trigger more AI calls, token charges, compute, and delay cost to recover a decision the business already paid to settle.

Subscribe for the next practical AI operations lesson.

Frequently Asked Questions

How do I tell whether a merged pull request includes approval to act?

Read the current policy or standing grant for the actor and action class; do not infer authority from merged status alone. Confirm that the record binds the exact revision, scope, evidence, and criteria and that every condition passed. If anything is missing, stale, invalidated, or out of scope, keep the action blocked and use the action-specific approval path.

What must a standing approval record contain?

Name the bounded action class, authorized actors, scope, conditions, required gates and evidence, prohibited exceptions, and a review date or expiry condition. State what changes invalidate or reopen the grant. For each execution, bind fresh evidence to the exact revision, scope, criteria, method, actor, timestamp, and result.

What should happen when an approval request gets no response?

Put the request in an owner-visible decision queue with the action, evidence, scope, authorized decider, and response deadline. The response window is a local policy choice. Without an explicit decision when policy requires one, keep the action blocked because silence grants no authority.

When does a prior approval stop applying?

Invalidate an action-specific approval when the revision, action, scope, criteria, evidence, authorized actor, or policy changes. Re-review or expire a standing grant when its action class, actors, conditions, gates, evidence standard, or risk changes. Keep execution blocked until current evidence and authority bind the changed decision, and record the supersession.

Does an approving pull-request review count as authorization?

Only when the current authority policy explicitly grants that reviewer power over the exact downstream action and the approval still binds the current revision, scope, criteria, and evidence. A review may establish code quality while leaving deployment, publication, billing, or another action unauthorized. If the policy does not make that connection, preserve the review as workflow evidence and obtain the required action approval separately.

Update History

• 2026-09-14 - Strengthened the business decision and trust boundary: Before publication authorization, the draft was revised to open with a five-change audit and two-cost stake, make the recurring team, customer, compliance, staff-time, and AI-service consequences explicit, consolidate current public artifacts, and require approval controls to come from a protected source the candidate cannot rewrite. The change was necessary because missing consequence evidence weakens the business decision, while exact hashes do not help when proposed code can replace the validator that checks them.
• 2026-09-14 - Reader path and implementation help: Added the property-specific Just In Time AI service callout within the first third of the article and verified the planned paired reader path. The paired route is now bound for release; deployment and anonymous readback remain pending.