When Reviewers Still Ask for Live Proof

The first two rules in this mini-series are intentionally conservative:

prove behavior without touching production by default; and
treat old proof as historical when the claim or target changes.

Those rules still leave a hard case. What happens when the agent provides staged proof, labels its limits honestly, refreshes the evidence, and a reviewer still asks for live proof?

The answer should not be “the agent now has permission to touch production.” A review request is a signal. It is not an authorization boundary.

A reviewer can ask for live proof. Only the operator can approve live risk.

Conceptual scope: this is a sanitized agent-operations write-up and part 2 of a proof-boundary mini-series. I am intentionally omitting exact PR numbers, branch names, commit hashes, check-run counts, bot labels, local worktree paths, session identifiers, channel identifiers, raw terminal transcripts, and live deployment details. The examples are generalized patterns, not transcripts from any single review thread. The public lesson is escalation discipline.

Maintainer Skepticism Is Valid

It is easy for agents to get defensive when a reviewer asks for more proof. That is the wrong posture.

Maintainers have context the agent may not have. They may know that a staged harness misses an integration seam. They may remember a previous false positive. They may be worried about timing, permissions, rollback behavior, or a real user-facing edge case that the proof packet did not cover.

So the first response should be respect, not resistance:

I hear the request for live proof.
Before touching any live system, I want to clarify the specific property that staged proof did not answer.

That one sentence keeps the review collaborative while preserving the safety boundary.

Three Different Cases Look Similar

“Please prove it live” can mean at least three different things. Agents need to separate them before acting.

Case	What it means	Right response
The proof packet is unclear	The reviewer cannot tell what was exercised, what environment was used, or what the limits were.	Rewrite the proof packet. Do not escalate to live systems yet.
There is a real live-only property	The disputed behavior depends on production-only state, permissions, scale, timing, routing, or side effects that staged proof cannot represent.	Document the live-only property and ask the operator whether to approve a scoped live proof plan.
The reviewer prefers live proof despite adequate staged evidence	The staged proof appears to answer the behavior claim, but the reviewer still wants a stronger confidence signal.	Offer safer alternatives first; if still blocked, escalate the decision to the human operator instead of improvising access.

Those cases have different blast radii. Treating all of them as “go run live” is how a proof discipline turns into production experimentation.

The Clarifying Question

The agent should ask one focused question before proposing any live action:

What live-only property remains unproven by the staged evidence?

That question is not a debate trick. It is a routing function.

If the answer is “I could not see what you tested,” the fix is better reporting.
If the answer is “the fake integration does not model this permission boundary,” the fix may be a better harness or a narrower live canary.
If the answer is “we need to see actual production traffic,” the operator must decide whether that risk is acceptable.

The agent should not guess which case applies. Guessing is how it over-tests, under-tests, or touches the wrong surface.

A Public-Safe Response Template

When the reviewer asks for live proof, I want the agent to respond with a compact, public-safe packet like this:

Claim under review:
  behavior this PR claims to fix or protect

Current proof supplied:
  proof surface, environment, target revision, and freshness boundary

Limits already stated:
  what the staged proof does not prove

Clarifying question:
  what live-only property remains unproven?

Safer alternatives:
  focused regression / fixture adjustment / fake integration improvement / staged runtime canary

If live proof is still required:
  authorized approver / operator
  target behavior
  live surface
  allowed side effects and concurrent-user impact
  credentials / secrets handling
  execution window / timeout
  rollback or cleanup plan
  public-safe evidence summary

This does two useful things. It gives the reviewer a better artifact to critique, and it gives the operator a clean decision packet if the request truly reaches live-risk territory.

Live Proof Requires a Scope, Not Just a Yes

Even when live proof is appropriate, “yes” is not enough. The approval has to specify scope.

Approval field	Why it matters
Target behavior	Prevents the proof from expanding into unrelated exploration.
Live surface	Names exactly which environment, account class, or channel type is in scope without exposing private identifiers publicly.
Allowed side effects	Separates read-only observation, synthetic traffic, real messages, config writes, user-visible actions, monitoring/audit effects, and acceptable impact on concurrent live users.
Execution window / time boundary	Sets the exact proof window, timeout, and expiration of the approval so live work cannot continue open-ended.
Secrets and credentials	Confirms whether production credentials are used and how evidence will avoid leaking them.
Rollback or cleanup	Defines how the system returns to normal after the proof.
Public evidence summary	Defines what can be posted back to the PR without exposing operational details.

Without that scope, the agent should not proceed. “The reviewer asked” is not a substitute for “the operator approved this exact live action.” If the reviewer and operator are the same person, the distinction still matters: the agent needs explicit production-approval language, not merely a review comment that asks for stronger evidence.

Offer Safer Alternatives First

Many live-proof requests are actually requests for higher confidence. Higher confidence does not always require production.

Before escalating to live systems, the agent can offer alternatives:

make the proof packet clearer and include the missing assertion;
add the reviewer’s concern as a focused regression test;
adjust the synthetic fixture to model the missing state shape;
improve the fake integration to cover the questioned contract;
run the staged runtime against a narrower target slice;
capture a read-only observation in a non-production surface, or use a live read-only observation only after the same scoped approval required for any live proof; or
ask the reviewer to accept a narrower claim if live proof is not approved.

The point is not to avoid proof. The point is to match the proof surface to the risk.

The useful invariant: escalate proof strength before escalating blast radius.

When the Answer Is “No”

Sometimes the operator should say no to live proof. That is not a failure. It is a decision.

The agent should then state the boundary plainly:

Live proof is not approved for this PR.
The available evidence is staged proof only.
The PR can proceed only if reviewers accept that evidence and its limits;
otherwise it should remain blocked rather than testing against production.

That is better than quietly stretching the proof scope, trying to infer permission from review pressure, or posting vague comments that imply stronger evidence than exists.

Stalemate Handling

The hardest case is a stalemate: the reviewer wants live proof, the operator does not approve live risk, and staged proof cannot satisfy the review gate.

The agent should not keep arguing. It should preserve the state:

summarize the claim and current staged evidence;
state what live-only property remains disputed;
state that live proof was not approved;
offer the safest remaining alternative, if one exists;
notify the human operator through the agent’s normal control surface that the PR is blocked on a proof-scope dispute; and
mark the PR blocked on proof scope rather than continuing to improvise.

That kind of block is honest. It gives maintainers and operators a concrete decision instead of turning the agent into a pressure valve.

Conclusion

Reviewer skepticism is part of healthy engineering. Live systems are also real systems with real blast radius. The agent’s job is to connect those facts without collapsing one into the other.

When a reviewer still asks for live proof, the agent should clarify the remaining live-only concern, offer safer alternatives, and route any live-risk decision to explicit operator approval with scope, side effects, rollback, and public-safe evidence boundaries.

Proof should increase trust. It should not quietly mint production permission.

About the Author

Jingxiao Cai works on distributed ML runtime systems and backend execution reliability, and writes about self-hosted agents, automation reliability, and the operational boundaries that keep small systems understandable.

A review request is a signal. Approval is a separate boundary.