How to Write AI Prompts That Produce Evidence, Not Confidence

An evidence-producing prompt contains eight parts: the decision or claim, the scope and authority, the source hierarchy, the required investigative actions, the invariants and adversarial cases, the evidence labels, the structured output, and the stop and uncertainty conditions. Everything else in this guide is detail on those eight.

The quality of an AI audit depends far less on how forcefully you ask for expertise than on what evidence you require. "Act as the world's best engineer and perform an exhaustive review" will produce a long, confident answer. It does not guarantee that the agent inspected the runtime, traced every write path, executed a test, verified a real-world constant, or distinguished an inference from an observation.

If you keep one sentence from this post, keep this one, and put it near the top of every review prompt you write:

That sentence is worth more than a dozen inflated expert roles. It converts the agent's job from producing a judgement into producing a record — and a record can be checked, argued with and reused. A judgement cannot.

We arrived at this method the slow way, while repeatedly auditing a real iOS and Android child-growth product. Early broad prompts generated genuinely useful ideas, but they kept declaring areas finished after inspecting the most visible representation of those areas. The screen existed, therefore the feature looked complete. A reference table looked plausible, therefore it was treated as correct. A bug pattern stopped appearing, therefore the class of bug was considered fixed. Every one of those inferences was reasonable, and several were wrong.

The prompts improved the moment we stopped asking for conclusions and started requiring proof. This post is part 08 of our AI product development methodology series; part 07 covered how to split the design work between ChatGPT and Claude Code, and this part covers the instruction layer that sits underneath all of it.

None of this is exotic. Anthropic's own prompt engineering guidance makes the same structural point in a different register: specificity, examples and explicit success criteria beat adjectives. What the eight-part contract adds is a discipline borrowed from audit work rather than from writing — the assumption that an unverified claim is a liability, not a draft.

Because a language model is optimised to give a useful answer, and when a prompt asks whether something is "production ready" it will construct a coherent judgement — bridging any gaps in the evidence with inference unless the task explicitly forbids it. The confidence is not deception; it is the shape of the request coming back at you.

Five prompt patterns make this reliably worse, and you will recognise all of them.

Status questions without proof rules. "Is the subscription system fully working?" The answer will summarise visible code and documentation. It does not define working, does not say which purchase and restore states matter, and does not say what evidence would settle it. The agent has to invent the acceptance criteria, and it will invent generous ones.

Exhaustive language without a finite inventory. "Check every screen and every function." The word every is not operational until the prompt first requires a screen, route, state and capability inventory and then reconciles coverage against it. Without the inventory, every means whatever the agent happened to open.

Role inflation. "Act as an elite CTO, designer, security researcher, growth expert and medical specialist." Roles can be useful for establishing which perspectives to apply, but they grant no data, no tools and no authority. What they reliably increase is rhetorical confidence, which is the opposite of what an audit needs.

Output-first prompting. "Give me a detailed report with 20 sections." The agent will optimise for the document shape you asked for. It will fill all 20 sections, including the ones where it found nothing, because an empty section reads as a failure to comply.

Fix requests without reproduction. "Find and fix all bugs." With no failing case, no invariant and no regression requirement, the changes that come back may only silence symptoms — and silencing a symptom is indistinguishable from fixing a defect if nobody ever wrote down what the defect was.

The pattern underneath all five is the same: the prompt specifies an output but not an epistemology. Frameworks such as the NIST AI Risk Management Framework keep arriving at the same conclusion from the governance side — trustworthiness has to be measurable, documented and traceable, or it is just a claim about a claim. A prompt is where that gets decided in practice.

Start with what must be decided, not with the activity you want performed — because a decision is finite enough to challenge and an activity is not. This is the single highest-yield edit you can make to an existing prompt.

Weak: "Review the measurement feature."

Strong: "Determine whether every path that creates, edits, imports, restores, synchronises, undoes or deletes a measurement enforces the same unit, date, identity and range invariants, and whether dependent charts and reports refresh after success."

The second version is longer, but length is not what makes it better. What makes it better is that somebody can now disagree with the answer. If the agent reports that all paths enforce the invariants, you can name a path and ask where. Against "review the measurement feature," there is nothing to push on.

Useful claim shapes, in rough order of how often we reach for them:

• Determine whether… — the default. Bounded, answerable, falsifiable.
• Prove or disprove… — when you have a specific suspicion.
• Identify every path that… — when coverage is the risk rather than depth.
• Compare the implementation against… — when an authoritative reference exists.
• Reproduce and isolate… — for a reported defect with no known cause.
• Verify across the full input range… — for anything with a bounded domain.
• Show which acceptance condition remains unmet… — for a re-review after a fix.

The output should land on a specific decision: ship, reject, fix, investigate further, or approve with named limitations. If the answer cannot be one of those, the prompt was still describing an activity.

There is a second benefit that only shows up over weeks. A decision-shaped prompt is re-runnable. You can put the same question to a different agent, a different model or the same agent three sprints later and compare the answers, because the question did not move. Activity-shaped prompts produce answers that are not comparable to each other, which is how teams end up unable to tell whether the product improved or the prompt drifted.

Name what the agent may inspect and, separately, what it may change — because an agent that can edit while it is still trying to understand the system will erase the evidence it was sent to collect. Scope and authority are two different constraints and both belong in the prompt.

Scope:
- Repositories: iOS and Android application
- Surfaces: measurement entry, edit, history, chart and export
- Data objects: child profile and measurement
- Environments: local test build only
- Mutations allowed: none during discovery; tests and scripts may be
  created in a temporary location
- Out of scope: billing redesign and new features

The "out of scope" line does more work than it looks like it does. Agents expand helpfully. Asked to audit a data layer, an agent will frequently return with opinions on your navigation architecture, an unrequested refactor of a view model, and a suggestion that you adopt a different dependency injection approach. All three might be correct. None of them is what you asked, and each one dilutes the finding list you actually have to triage.

Separate read from write explicitly. For any audit worth running, make discovery read-only and require findings plus a plan before a single line changes. The same agent can implement afterwards; the point is that the phases are declared rather than blurred. We write this as a literal first line — "PHASE 1 IS READ-ONLY DISCOVERY" — because a rule stated once at the top survives context pressure better than a rule buried in paragraph nine.

Authority also covers the decisions the agent is not allowed to make. Anything touching privacy, entitlements, health guidance, pricing or irreversible user actions is a product decision, not an implementation detail. An agent asked to fix a data-retention bug will happily pick a retention period. Put those in an explicit escalation list so the agent stops and asks rather than choosing on your behalf. On a health product, that list is long, and on the Play developer policy side it is exactly the set of decisions that get an app pulled if someone guesses wrong.

One more constraint worth stating: preserve unrelated work. An agent operating in a repository with uncommitted changes, or with another agent's branch in flight, can quietly revert or reformat work it was never asked to touch. Say so.

Tell the agent the ranking in advance, because evidence conflicts constantly and an agent without a hierarchy will tend to favour whichever source is most articulate — often the documentation, even when the question is about current runtime behaviour. Documentation may be authoritative for intended requirements and still be weak evidence of what the target build does today. A source hierarchy is three lines of prompt that prevent an entire category of wrong answer.

For a UI or UX claim:

1. Running product in the target build
2. Validated product and data requirements
3. Current source implementation
4. Approved design decisions
5. Concept boards
6. General conventions

For a real-world constant — a formula, a threshold, a price band, a lookup table:

1. Authoritative primary reference and its version
2. Verified local dataset derived from that reference
3. Executable comparison output
4. Application constants
5. Documentation and code comments
6. AI explanation

For a bug fix:

1. Reproducible failing case
2. Test or guard that detects it
3. Implementation change
4. Passing protection after the change
5. Mutation proving the protection fails when the defect returns
6. Written explanation

Notice that in all three, the written explanation is last. That ordering is deliberate and it is the whole point of the exercise. A polished concept board, a confident comment or a well-written summary should never outrank what the running product actually does.

The real-world constants hierarchy is the one teams skip, and it is the one that bites hardest. In the product this method came from, the constants were paediatric growth references published as the WHO Child Growth Standards — a bounded, published dataset with a version number. That is the ideal case: there is an oracle, so a throwaway script can compare every value the app ships against every value the reference publishes, and the comparison either matches or it does not. Most products have some version of this. Tax bands, shipping thresholds, currency rounding, credit-score ranges, GST slabs, unit conversions, delivery-fee tiers — all of them are lookup tables that somebody typed in once, and all of them are invisible to a code reviewer because a plausible number looks exactly like a correct one.

Never write "inspect thoroughly" — name the actions, because an action verb produces reproducible evidence and an adverb produces a feeling. This is the part of the prompt that turns a review into something a second person could repeat.

Actions worth naming, depending on the claim:

• Enumerate routes from the navigation definitions, not from the file listing.
• Search for every constructor, update and delete call for the data object.
• Trace calls through the repository and service layers to the persistence boundary.
• Run the relevant test suites and record the exact command and the exit status.
• Capture the default, empty, loading, error and permission-denied states.
• Compare the result against the accepted screenshot under identical conditions.
• Create a throwaway verification script for every real-world lookup table.
• Evaluate the full supported input domain rather than representative samples.
• Deliberately reintroduce the bug pattern and show the protection failing.

The distinction between the first item and its lazy sibling is instructive. "List the screens" gets you a directory listing. "Enumerate routes from the navigation definitions" gets you the screens that are actually reachable, which is a different and smaller set — and the gap between the two is where dead code and orphaned surfaces live.

Then require coverage reconciliation. After discovery, the agent must account for the inventory it built:

Inventory total:
Reviewed with evidence:
Partially reviewed:
Unreachable or unavailable:
Not reviewed:
Coverage gaps and reason:

Match the action to the claim type as well. Platform test tooling exists for behavioural claims — the Android testing fundamentals guidance is explicit that unit, integration and instrumented tests answer different questions — while a visual claim needs a rendered capture and a data claim needs an executed comparison. A file path proves where code lives. It proves nothing about what happens when the code runs.

An invariant is a condition that must hold true on every path, and naming them in the prompt is what stops an agent from reviewing the happy path and calling it coverage. Without them, an agent reviews the flow a user follows in a demo.

For a single measurement record in the product this came from, the invariants were:

• It belongs to the correct child profile.
• It uses normalised units regardless of what the user typed.
• It carries a date that is valid relative to the birth date and to the present.
• It falls within the supported domain, or receives explicit out-of-range handling.
• It produces deterministic derived values — the same input yields the same percentile.
• It updates every dependent surface after it persists, not before.
• It survives offline and retry behaviour without duplicating itself.

Then name the adversarial paths, because these are the ones nobody demos: edit, import, sync conflict, restore from backup, undo, cancel mid-write, retry after timeout, partial failure, duplicate submission, background interruption and account switch.

That list is the most portable thing in this post. It applies to an order, a transaction, a saved address, a cart, a document or a health record just as well as to a measurement. And it is the list that finds real defects, because the shared validator everyone points at almost always sits on the create path. The import path, the restore path and the sync path frequently construct the stored object directly and bypass it entirely.

A practical constraint that keeps this from becoming a project of its own: pick three data objects. The three that would cause the most user harm if corrupted. Enumerate every mutation path for those three, including the failure branches, and leave the rest for a later pass. Three objects done properly beats twenty objects listed.

Requiring one label on every material claim converts a vague answer into a work list, because the label tells you exactly which claims are finished and which still need a check. Uncertainty stops being a weakness in the report and becomes the most actionable part of it.

The eight labels we use:

• Observed — directly seen in the runtime or in captured output.
• Measured — supported by a recorded metric or instrument reading.
• Confirmed in source — the exact implementation was located and read.
• Tested — exercised by a named test or command with a recorded result.
• Documented — present only in an approved document, nowhere else.
• Inferred — deduced from incomplete evidence.
• Proposed — a recommendation, not a description of current behaviour.
• Blocked — the evidence could not be obtained, with the reason.

A labelled claim looks like this:

Claim: Editing a measurement refreshes the chart.
Status: Confirmed in source, not runtime verified.
Evidence: Edit use case emits a repository update; the chart observes
          the repository stream.
Missing: Execute an edit with a controlled fixture and capture the
         updated chart.

Compare that against what the same agent would otherwise have written — "editing a measurement correctly refreshes the chart" — and note that both statements reflect the same underlying work. The unlabelled version is not more thorough. It is the same investigation with the uncertainty deleted.

Measured deserves a note of its own, because it is the label teams most often use loosely. A measurement needs an instrument. If the claim is about performance, retention, funnel behaviour or conversion, the evidence is a number from a tool that was actually running, not an estimate from reading the code — and that presumes the instrumentation exists in the first place, which is its own audit. We have written separately about choosing the analytics stack that makes those claims possible; without it, every behavioural claim in your report is capped at Inferred.

The discipline generalises beyond code. In our portfolio we now apply the same labels to store-listing and creative reviews, because "this screenshot underperforms" is an entirely different claim depending on whether it is Measured from a store experiment or Inferred from someone's taste.

Because narrative hides missing proof and a schema exposes it — an empty field is visible in a table and invisible in a paragraph. The finding schema is the cheapest quality control in the entire method.

Finding ID:
Claim:
Severity:
Evidence label:
Source location or runtime state:
Reproduction or inspection steps:
Observed result:
Expected invariant:
Impact:
Confidence and why:
Recommended next action:
Acceptance evidence:

Two fields carry most of the value. Expected invariant forces the agent to state what should have happened, which frequently reveals that it never had a clear standard in mind. Acceptance evidence forces it to state what would prove the fix worked, which is what you will hold the implementation phase against later.

Clean areas need a schema too, and this is the part most teams never add:

Area:
Inventory reviewed:
Commands and checks executed:
Evidence obtained:
Classes of issue this review could not detect:
Remaining uncertainty:

That fifth line is the one that matters. Every review method has blind spots even when every finding it produced is correct. A source-only review cannot see runtime state. A UI review cannot see data corruption. A test suite cannot see the input ranges it never exercises. An agent that reports "no issues found" without naming what it could not have found has told you almost nothing, and worse, it has told you something reassuring.

There is a practical reason to insist on the schema beyond honesty: structured findings are diffable. Two runs of the same contract produce two lists you can compare finding-by-finding, so you can see what closed, what reopened and what is new. Narrative reports cannot be compared at all, which means a re-audit gives you a fresh opinion rather than a delta — and a fresh opinion is exactly what you did not need.

Keep severity honest as well. Ask for severity to be justified by impact on a user or on data, not by how difficult the fix looks. Agents systematically over-rate cosmetic issues that are easy to describe and under-rate silent data problems that are hard to describe, and a schema field labelled Impact is what pulls that back into line.

Whenever the evidence required to answer honestly is unavailable — and the prompt has to say so explicitly, because everything else about the interaction implies that finishing is expected. Stopping has to be made honourable, or the agent will fill the gap.

Stop and report BLOCKED when:
- the authoritative source cannot be identified;
- the required runtime cannot be launched;
- the data fixture cannot be reproduced;
- credentials or permissions are missing;
- the requested change conflicts with a stated invariant;
- several plausible product decisions require owner approval;
- verification would require destructive or production actions.

A blocker is a valuable result. "I could not verify the restore path because I have no backup fixture, and here is the fixture I would need" is a better outcome than a paragraph asserting that the restore path looks correct. The first tells you what to build next. The second tells you nothing and costs you a false sense of coverage.

The reason this needs stating so bluntly is structural. A request creates an implicit contract to deliver something, and an agent with no permission to return empty-handed will reach for the most defensible thing it can produce, which is usually a plausible reading of the source. It is not being evasive. It is completing the task as specified, and the specification was wrong.

In our experience the ratio is the tell. A review that produces zero blockers on a system the agent could not run is not a thorough review; it is a review that quietly downgraded every runtime question into a source question. When we started counting blockers as a positive signal rather than a failure, the reports got shorter, slower to produce and considerably more useful — and the list of blockers became a genuinely good backlog of test infrastructure to build.

Give the stop conditions teeth by requiring the agent to name the unblocking action alongside each one. A blocker with no named remedy is a shrug; a blocker with "needs a seeded account with two children and 18 months of history" is a ticket.

It gives every claim a rung number, so the language has to match the work — and "located" stops being written as "verified". The ladder is seven rungs and it takes ten seconds to apply.

1. Mentioned — documentation, a ticket or the prompt itself says it exists.
2. Located — the relevant code, asset or configuration was found.
3. Reasoned — the mechanism appears coherent when read.
4. Executed — a command, test or user journey was actually run.
5. Observed — the output was captured and inspected.
6. Adversarially checked — failure and edge paths were exercised on purpose.
7. Protected — a regression guard demonstrably detects the defect returning.

Most reviews that feel thorough are sitting on rung three. Reading code carefully is real work and it produces real findings, but it cannot distinguish an implementation that is correct from one that is coherent, and a great deal of generated code is coherent. The jump from rung three to rung four is where the cost of an audit roughly doubles and where its value roughly changes category.

Rung seven is the one worth arguing about, and it is the reason the ladder does not end at six. A fix that passes a test proves the test passes. It does not prove the test would have failed before the fix, and a test that cannot fail is decoration. Deliberately reintroducing the original failure mode and watching the guard fire is a controlled negative test of that specific protection. Automated mutation testing generalises the same principle by seeding many small faults across a codebase; Google's engineering research shows why that stronger measure of test-suite sensitivity matters at scale. Part 13 of this series applies the narrower, manual version to consequential and recurring defects.

Use the ladder as a vocabulary control, not as a scoring system. You are not trying to get every claim to rung seven; most claims do not deserve that investment. You are trying to stop a rung-two claim being reported in rung-six language, which is the specific failure that makes AI review output feel authoritative and turn out to be thin.

It usually looks like replacing a request for a report with a request for an inventory — and the stronger prompt often produces a shorter first answer, because it discovers what has to be checked before pretending to finish. Here is the before and after.

The weak version, which almost everybody has written at some point:

Act as a senior Android expert. Audit the entire app for UI/UX,
architecture, security, performance and bugs. Fix everything and give
a detailed report.

Seven things are wrong with it:

• No inventory defines what "entire" means.
• Discovery and mutation are mixed into one instruction.
• No source hierarchy exists, so documentation can outrank runtime.
• No data invariants are named, so the happy path counts as coverage.
• No runtime requirement exists, so a source read can pass as verification.
• No evidence schema exists, so narrative can hide the gaps.
• "Fix everything" authorises unbounded scope and unbounded change.

The rewritten version:

PHASE 1 IS READ-ONLY DISCOVERY.

Decision: Determine whether the current Android application is ready for
a bounded release-candidate review, and produce an evidence-backed
remediation plan.

First build and reconcile:
1. Capability inventory
2. Routes, screens, sheets and dialogs inventory
3. State inventory
4. Critical journey inventory
5. Three critical data objects and every mutation path
6. Integrations, permissions, entitlements and configuration

For every claim:
- label it Observed, Measured, Confirmed in source, Tested, Documented,
  Inferred, Proposed or Blocked;
- cite the file location, runtime state, command or authoritative source;
- state what evidence would disprove it.

Do not call the app complete based on file names, previews or
documentation. Inspect the rendered product for visual claims. Run
executable checks for behavioural claims. Verify every real-world
constant across its full supported domain. Do not change code in Phase 1.

Finish with:
- coverage reconciliation;
- ranked findings;
- missing evidence;
- review blind spots;
- proposed Phase 2 tasks with acceptance tests.

Expect the first response to feel underwhelming. It will come back with an inventory, a handful of ranked hypotheses and a list of things it could not reach — instead of twenty confident sections. That is the improvement, even though it does not feel like one. The twenty-section version was never twenty sections of evidence; it was twenty sections of shape.

It looks like a contract with fixed rules and blank slots — the rules never change between audits, and only the slots do. Copy this, fill the brackets, and keep the rest verbatim.

EVIDENCE-FIRST REVIEW CONTRACT

OBJECTIVE
[One decision this review must support]

SCOPE
- Repositories and systems:
- Surfaces and journeys:
- Data objects:
- Platforms and builds:
- Allowed tools and actions:
- Explicit exclusions:

SOURCE HIERARCHY
1.
2.
3.
4.
5. Documentation and code comments
6. Written or AI explanation

PHASES
1. Inventory
2. Hypotheses and risk ranking
3. Source and data tracing
4. Runtime and executable verification
5. Findings and acceptance plan
6. Implementation only after approval

MANDATORY RULES
- Evidence decides truth; confident wording does not.
- Separate observed facts, source confirmation, inference and proposal.
- Never infer runtime quality from code alone.
- Never infer real-world correctness from plausible constants.
- Never call a bug class fixed without a regression protection.
- Preserve unrelated user work and repository changes.
- Stop when authority, permissions or product decisions are missing.

CRITICAL DATA RULE
Pick the three most important data objects. For each, enumerate every
create, edit, import, sync, restore, undo, cancel, retry and delete
path, including failure branches. Show where each invariant is enforced
and name the paths where it is not.

REAL-WORLD CLAIM RULE
For each formula, threshold, price, bound or lookup table, identify an
authoritative source, create an executable comparison, test the full
supported range and show the output.

REGRESSION RULE
For each claimed fix, require a test, lint rule, static check or guard.
Mutate the implementation to reintroduce the issue, confirm the mutation
is valid, and show the protection failing.

OUTPUT
- Executive decision
- Coverage table
- Findings using the required schema
- Evidence ledger
- Commands and checks with outcomes
- Unverified claims
- Blind spots
- Ranked next actions
- Approval decisions required

The three named rules at the bottom exist because each of them corresponds to a category of defect that ordinary review does not catch. The critical data rule catches invariants enforced on one path and skipped on four. The real-world claim rule catches a lookup table where somebody transposed two digits three years ago. The regression rule catches a fix that silenced a symptom. Part 11 of this series covers the first of those in depth: why you should audit data paths rather than screens.

Length warning: do not paste this into every session. Move the stable half into your project instructions file so it applies by default, and send only the objective, scope and hierarchy per task. A contract repeated in full every session drifts into inconsistent variants, and then you have several versions of your own standard without knowing which one produced which report.

An audit prompt is broad and read-only; an implementation prompt is narrow, write-enabled and explicit about what must not change. Once a finding is approved, throw the audit contract away and use a task contract instead.

Implement [DECISION ID].

Before editing, locate the owning code, the state flow, the shared
components and the tests. State your plan and any conflict with the
contract before you change anything.

Preserve:
- [capabilities]
- [data invariants]
- [analytics, accessibility and platform behaviour]

Change only:
- [files, surfaces, behaviour]

Verify with:
- [tests and commands]
- [runtime states]
- [comparison evidence]

Do not claim completion if runtime evidence is unavailable. Report the
exact remaining verification step.

The Preserve block is what makes this work and it is the block people leave out. An agent given a narrow instruction will optimise the code it touches, and that optimisation regularly removes an analytics event, an accessibility label, a haptic, an empty state or a defensive branch that looked redundant. None of those show up in a functional test. All of them show up later as a metric that quietly stopped reporting or a screen reader that stopped announcing.

Name the preservation targets concretely rather than generically. "Preserve accessibility" is decoration. "Preserve the accessibility labels on the entry form and the Dynamic Type behaviour on the chart legend" is a checkable instruction, and it maps to specific success criteria in the W3C's WCAG 2.2 recommendation that a reviewer can actually test against.

"Do not claim completion if runtime evidence is unavailable" belongs in every implementation prompt without exception. The common failure mode is not broken code — it is code that compiles, passes the tests that exist, and was never once run by a human on a device. The honest report is "implemented, not verified," and the agent will only give you that if you tell it that answer is acceptable. Part 09 of this series covers the full implementation contract in depth: how to make an AI agent implement a design without damaging the product.

By requiring the strongest plausible counterexample and the check performed to find it — because a prompt that asks whether something works will always find reasons that it works. Confirmation is the default direction of every investigation unless the prompt reverses it.

Require this block for every material conclusion:

Claim:
Supporting evidence:
Strongest plausible counterexample:
Check performed to seek it:
Result:
Remaining condition that could still falsify the claim:

A worked example from the growth product. Source tracing suggested that every write of a measurement normalised its units, because every path the agent had followed went through a shared validator. The strongest plausible counterexample was an import or a restore path that constructed the stored object directly. That is what the agent should go looking for — not another reading of the validator's code, which will keep confirming what it already confirmed. The bypass path either exists or it does not, and thirty seconds of searching settles it.

Then add negative controls. A negative control is an input or a mutation you expect to fail. It proves the review mechanism is actually sensitive, which is a different question from whether the product is correct. Four we use routinely:

• Add a forbidden field to a privacy payload and expect the schema check to fail.
• Alter one lookup-table boundary value and expect the oracle comparison to report it.
• Remove one content token and expect lint to detect the raw text style.
• Reintroduce a duplicate retry identity and expect the integration test to fail.

Include a negative control in the prompt whenever the task claims that a bug class, a policy or an invariant is protected. The rule is simple: any claim of protection requires a demonstration that the protection can fail.

By defining the permitted verdicts in advance and banning the vague ones by name — because "looks good," "should work" and "production ready" are the three phrases that do the most damage in an AI review. Give the agent a closed vocabulary for finishing.

• Verified — the required evidence was executed and the acceptance condition was met.
• Partially verified — some required evidence exists; the named gaps remain.
• Implemented, not verified — the change exists but runtime or behavioural closure is missing.
• Failed — the evidence contradicts the acceptance condition.
• Blocked — a required source, environment, authority or permission is unavailable.
• Not applicable — the inventory shows the claim does not apply, with the rationale.

Prohibit anything outside that list unless the verdict carries its own scope and evidence. "Production ready" is not a verdict; it is a summary of somebody else's decision, and it is precisely the phrase that ends up in a status update and then in a release date.

A source-only review can miss runtime state. A UI review can miss data corruption. A test suite can miss unsupported input domains. A visual pass against Nielsen Norman Group's usability heuristics can miss the fact that the screen is showing stale data. Clean evidence should narrow uncertainty, not erase it, and a review that erases it has made the product feel safer without making it safer.

There is a store-submission angle here too. Review teams reject on concrete, testable grounds, so a verdict of "verified" on a release-readiness question needs to mean the specific conditions were checked — which is why we keep our breakdown of the actual App Store rejection reasons alongside the contract. It converts a vague readiness question into a list of acceptance conditions an agent can be held to.

Seven, and every one of them is a case of adding more instruction where the prompt needed more proof. These are the ones we have made and had to write rules against.

Adding expert roles instead of evidence rules. Perspective is genuinely useful — asking for a security reading and a data-integrity reading surfaces different things. But perspective without proof requirements just changes the vocabulary of the confident answer. Add the role and the rule, never the role alone.

Requiring a conclusion for every section. If the template has a section, the agent will fill it. Explicitly permit "unverified," "not applicable" and "blocked" as section contents, or you have built a machine for generating speculation in the areas you looked at least.

Asking for citations without asking for actions. A file path proves where code lives. It does not prove what happens at runtime. We have accepted whole reports full of precise line references that collectively verified nothing, because every claim was a source claim dressed as a behavioural one.

Accepting sampled validation for a bounded dataset. If the supported range is finite, test the range. Twelve spot checks against a published growth reference is not verification; it is an argument that the table is probably fine, and the two rows somebody transposed will not be among your twelve.

Letting the agent choose product policy while coding. Retention periods, consent copy, entitlement boundaries, health guidance, anything irreversible. These need an owner decision, and an agent that picks one in passing has made a policy decision inside a pull request.

Treating a passing test as universal proof. Tests prove their assertions under their setup and nothing else. Require each test to name the claim it covers, and you will find that several of your suites cover the same claim while nothing covers the one you were worried about.

Forgetting blind spots after a clean review. The question is always the same: what class of thing could this method not detect? Ask it every time, especially when the answer is inconvenient — after a clean run is exactly when nobody wants to hear it.

There is an emerging-market version of the sampled-validation mistake worth calling out separately, because we hit it constantly across the India-facing products in our portfolio. Bounded datasets that look safe to sample are everywhere in local products — GST slabs, PIN-code-to-region mappings, IFSC prefixes, state-level fee tiers, regional-language string tables. An agent will cheerfully verify a handful of Mumbai and Bengaluru cases and report the mapping correct. The failures live in the tier-3 rows nobody spot-checks, and they surface as a user in a smaller city being charged the wrong amount or shown the wrong language.

Treat prompt revisions like product revisions — when an audit misses a class of issue, do not tell the next agent to be more careful, add the missing inventory, invariant, action, negative control or output field to the reusable contract. Prompt quality improves when failures become durable rules rather than remembered lessons.

"Be more careful" is not a rule. It has no acceptance condition, it cannot be checked, and it does not survive into the next session. Every instruction in the master contract above exists because something specific went wrong first and the response was to add a checkable line rather than an adjective. The contract is a scar record, and it reads like one.

Three operational habits make the difference between a contract that improves and one that rots:

• Move stable rules into project instructions. Anything that is true for every session belongs in the repository's instructions file, not in the message you type. Repeating a large master prompt each session adds noise and produces inconsistent variants of the same standard.
• Version the contract when its evidence rules change. Record which audit ran under which version. Otherwise a difference in findings between two audits could reflect prompt drift rather than product change, and you will spend a day arguing about which one was right.
• Track findings to closure outside the conversation. This is the failure that cost us the most on our own build (the full account is here): an audit produced roughly 150 findings, a plan claimed to contain all of them, and about 70 were never scheduled — four rounds of review missed it, because reviewers check what was done rather than what was left out. A findings register in the repository closes that gap.

None of this is unique to AI. It is ordinary engineering governance, arriving at a team that may never have needed it before because the cost of rework used to enforce it by itself. When generating a change is nearly free, nothing pushes back on scope creep or on a spec that never settled, so the discipline has to be written down instead of felt. Part 01 of this series lays out the evidence-first method the whole sequence is built on, and part 09 picks up from here with the implementation contract.

Prompt engineering for serious product work is not the art of sounding demanding. It is the design of an investigation. Define the decision. Bound the authority. Rank the sources. Require the actions. Name the invariants and the adversarial paths. Label every claim. Structure the output. Make stopping honourable. When prompts demand evidence, AI stops being theatrical and starts being useful — and if you want a second pair of eyes on the contract you are running against your own product, talk to us.