Match the proof to the consequence
A low-risk brainstorm may need a quick review. Security, money, health, legal obligations, or personal data require stronger evidence and qualified human judgment.
Increase the proof when the consequence grows
The right verification effort depends on what happens if the answer is wrong.
- BrainstormQuick human review
- Business decisionPrimary source plus a small test
- Security or private dataReproducible test and access checks
- Health, legal, or financialQualified professional judgment
- Brainstormmore impact: Business decision
- Business decisionmore exposure: Security or private data
- Security or private datahuman accountability: Health, legal, or financial
- Choose the claim
Select the claim whose failure would matter most.
- Choose the evidence
Prefer official documentation, original data, or observed system behavior.
- Run the check
Use the smallest test that another person can repeat.
- Record limits
State what the test proved and what it did not prove.
Score the risk before choosing a test
Verification should be proportional, not maximal. Estimate how likely the result is to fail, how severe the consequence would be, and how many people or systems could be exposed. A spelling suggestion needs a glance. An access-control rule needs signed-out and cross-account tests because a single mistake can expose private records.
| Risk level | Typical example | Minimum useful proof |
|---|---|---|
| Low | Brainstorming names for a practice project | Human review for relevance and obvious harm |
| Moderate | Choosing a paid tool for a small team | Current primary sources and a limited trial |
| High | Changing production data or permissions | Reproducible tests, review, backup, and rollback |
| Specialist | Health, legal, or financial decision | Qualified professional judgment with appropriate evidence |
Turn a claim into a reproducible check
Anatomy of a small trustworthy test
A test is useful when another person can repeat it and understand both the result and its limits.
- ClaimState exactly what should be true
- Known setupRecord account, version, data, and starting state
- Repeatable actionWrite the smallest exact sequence of steps
- Expected resultDefine success before observing the output
- Observed evidenceCapture logs, response, screenshot, or measurement
- Known limitsState what the check did not cover
- Claimground: Known setup
- Known setupprepare: Repeatable action
- Repeatable actioncompare: Expected result
- Expected resultobserve: Observed evidence
- Observed evidencebound: Known limits
- Write the claim
Use one sentence that can be true or false.
- Freeze the starting state
Record the version, account role, input, and configuration that matter.
- Define expected behavior
Decide what you should observe before running the check.
- Run and capture
Perform the smallest repeatable action and save the evidence.
- Name the boundary
List scenarios the test did not exercise.
Test failure paths, not only the happy path
A system may behave correctly for the owner and still fail for everyone else. Negative tests ask what must not happen: a signed-out visitor must not see a private lesson, another account must not edit your record, a repeated payment request must not charge twice, and a failed deployment must not destroy the previous working version.
Four directions for a stronger check
After the normal case passes, change one boundary at a time.
- Expected user and inputConfirm the intended path first
- Wrong identitySigned out, different account, or lower role
- Bad or missing inputEmpty, oversized, malformed, or repeated data
- Dependency failureTimeout, unavailable provider, or partial response
- Recovery pathRetry, rollback, and safe error state
- Expected user and inputchange user: Wrong identity
- Expected user and inputchange data: Bad or missing input
- Expected user and inputbreak service: Dependency failure
- Dependency failurerecover: Recovery path
Keep an evidence record that stays honest
Tested it. Everything works.
On version 2.4, a signed-out request to the private route returned 302 to login. A second-account test also failed closed. Admin-role behavior and provider outage recovery were not tested.
| Field | What to record |
|---|---|
| Claim | The exact behavior or statement being checked |
| Setup | Version, role, environment, and relevant starting data |
| Action | Repeatable steps or command |
| Observation | Actual response, measurement, log, or screenshot |
| Limit | Cases not covered and questions still open |
Put Ask–Inspect–Prove together
The complete reusable AI workflow
Each stage produces the input for the next, and new evidence can send you back to improve the request.
- Ask clearlyGoal, context, constraints, format, and privacy
- Inspect the answerClaims, assumptions, sources, and uncertainty
- Choose the risky partPrioritize by consequence and exposure
- Run a small testKnown setup, expected result, and observed evidence
- Record and continueSave the proof, limits, and next decision
- Ask clearlyreceive: Inspect the answer
- Inspect the answerprioritize: Choose the risky part
- Choose the risky parttest: Run a small test
- Run a small testdocument: Record and continue
- Record and continuerefine: Ask clearly
Check your understanding
Three practice questions. They are not saved to an account or awarded points.