Before Asking AI to Change Anything: An Evidence-first Inspect, Verify, and Audit Workflow

A practical guide for replacing reflexive ‘proceed’ instructions with a compact evidence-first sequence: inspect, define checks, make the minimum change, verify, and audit.

The recurring problem

A large share of AI-assisted work begins with a reasonable instruction:

“Looks good. Proceed.”

The risk is not the phrase itself. The risk is what may still be implicit when it is sent.

The AI may not have confirmed the current repository state, the latest document version, the actual production behavior, or the boundaries of the requested change. It may also be carrying assumptions from an earlier message that are no longer true.

When execution starts from an unverified baseline, speed compounds the mistake. A small misunderstanding can quickly become a code change, a rewritten policy, a deployment, or a confident report that is difficult to unwind.

국문 요약: AI에게 바로 “진행하세요”라고 보내기 전에 현재 상태를 확인하고, 요구사항을 검증 가능한 항목으로 바꾸고, 최소 변경만 수행한 뒤 실제 증거로 검증하는 워크플로입니다. 도구 접근이나 근거가 없으면 추측하지 않고 멈추는 것이 핵심입니다.

Why “proceed” alone can be unsafe

A complete execution instruction needs more than approval. It needs a verified starting point and a definition of done.

Before change begins, four questions should be answerable:

What is true now?
What exactly must become different?
What must remain untouched?
What evidence will prove the result?

Without those answers, the agent may optimize for momentum rather than correctness. It can make a broader change than necessary, verify the wrong surface, or report completion based on intention rather than observed output.

The five-step evidence-first workflow

Inspect current state
→ Turn requirements into checks
→ Make the smallest change
→ Run evidence-based verification
→ Final audit

1. Inspect the current state

Start by checking the actual source of truth. Depending on the task, that may mean reading the current file, checking the branch and exact commit, opening the live page, inspecting the issue, or retrieving the connected record.

The output of this step should separate:

confirmed facts,
assumptions,
unresolved mismatches,
and anything that cannot be checked with the available tools.

Open the Prompt Hotbar asset: Inspect the current state before acting

2. Turn requirements into observable checks

Rewrite the request as conditions that can be tested.

“Improve the mobile layout” is not yet a check. Better checks look like:

no horizontal overflow at 320–390px,
the primary action remains visible,
long links wrap within the viewport,
and the desktop layout is unchanged.

For code or configuration work, include the exact commands, routes, files, or UI states that provide evidence. For planning and document work, define which source fields and policy statements must be preserved.

3. Make the smallest justified change

Do not solve adjacent problems merely because they are visible.

The minimum-change rule reduces regression risk and makes the evidence easier to interpret. It also keeps review focused: the reviewer can compare the requested behavior with a narrow change instead of reconstructing a broad redesign.

Open the Prompt Hotbar asset: Keep the work within the minimum required scope

4. Run evidence-based verification

Verification is not a sentence saying that the work “looks correct.” It is the collection of observable results that correspond to the checks defined in step two.

Evidence may include:

test output,
an exact commit or deployment identifier,
screenshots of the required UI states,
HTTP status and rendered metadata,
before-and-after source values,
or a list of checks with pass, fail, and not-tested states.

A failed or unavailable check should remain visible. Do not convert “not verified” into “probably fine.”

For implementation work, open: Safe implementation workflow for a coding agent

5. Run a final audit

The final audit asks whether the evidence supports the claim being made.

Check that:

the exact requested scope is complete,
protected areas were not changed,
the evidence comes from the final state rather than an earlier commit or Preview,
unresolved risks are named,
and Production, repository, and documentation claims are not being mixed together.

The final report should distinguish done, verified, not verified, and not in scope.

How to shorten the workflow for small tasks

Not every task needs five separate messages. The sequence can be compressed, but its logic should remain.

For a low-risk text edit:

Confirm the current sentence and the requested replacement.
Change only that sentence.
Show the final diff and confirm no other file changed.

For a small UI fix:

Reproduce the issue at the affected viewport.
Define the overflow or alignment check.
Apply the smallest CSS change.
Re-run the same viewport check and one desktop regression check.

The workflow becomes shorter by combining steps, not by dropping the evidence requirement.

No tool access is a stop condition

An AI should not claim that a repository is clean, a deployment is live, a spreadsheet value is current, or a page renders correctly without access to the relevant source.

When the required tool or source is unavailable, the correct response is to:

state what could not be accessed,
identify the evidence that is missing,
avoid irreversible action based on the assumption,
and request the smallest missing input or defer the affected claim.

This is especially important when the instruction includes deployment, deletion, financial or legal interpretation, or changes to shared systems.

Public and private safety

Evidence-first work also needs a publication boundary.

Before sharing a log, screenshot, prompt, issue, or document excerpt, check whether it contains:

personal information,
customer or company-confidential data,
private repository paths or access tokens,
unpublished business decisions,
or prompt bodies and local configuration that were never intended to be public.

Use generalized evidence when the exact private value is unnecessary. Preserve the conclusion and verification method without exposing the sensitive payload.

Open the Prompt Hotbar asset: Run a public/private safety check

The prompts are parts of one workflow

The value is not in collecting three isolated prompt snippets. Their value comes from sequence and timing:

inspect before assumptions become actions,
constrain scope before implementation expands,
verify before completion is claimed,
and check the publication boundary before evidence is shared.

That is why this Guide belongs next to A Prompt Library Is Not Enough and the Prompt Hotbar project page. The prompts are retrieval points; the workflow explains when and why to use them.