Quality proof

Evidence is part of the deliverable.

A quality check is not a ritual. It is an answer to the question: “What could be wrong here, and what observation would reveal it?”

Evidence ladder

ClaimMinimum useful evidenceStronger evidence
“I understand the project.”Current docs, source path, consumers, status, and recent history.A compact evidence map with owners, invariants, boundaries, and non-goals.
“The code works.”Meaningful focused tests.Focused tests plus shared checks and counterexamples matched to the risk.
“The UI works.”Real interaction in the actual runtime.Interaction plus viewport, focus, loading, error, permission, and network state.
“The visual asset is right.”Open the actual delivered file.Compare style, composition, transparency, dimensions, anatomy, or project reference against the request.
“The answer is current.”Opened authoritative source.Multiple relevant sources, dates, direct links, and fact/inference/uncertainty labels.
“The system is safe.”Review obvious secrets and authorization paths.Threat-informed tests for untrusted input, data boundaries, permissions, retries, and failure handling.

Completion matrix

InvariantWhat must remain true after the change?
CounterexampleWhat valid-looking input, boundary, permission, or state transition could expose a defect?
AutomatedWhich test, type check, lint, build, migration, or script actually covers it?
RuntimeDoes the claim require a browser, server, deployment, rendered artifact, or real integration?
DiffDid the final changed-file list stay within scope, with no secrets, generated clutter, or unrelated edits?
ReportCan another person distinguish verified, inferred, blocked, and not-tested?

Do not over-test blindly

Use the narrowest relevant check first, then broaden when shared behavior, state, permissions, or unresolved failures justify it. More commands do not automatically mean more confidence.

Do not under-test politely

“The focused test passed” does not prove a browser flow, a migration, a privacy boundary, or a visual artifact. Match the proof to the claim.

Honest status language

Verified: the check ran and supports the claim. Observed: the behavior was seen but may not cover all paths. Inferred: a conclusion from evidence, not directly tested. Blocked: the intended check could not run for a named reason. Unknown: no reliable evidence yet.

For AI systems in general

NIST frames trustworthy AI risk management as continuous work across governing, mapping, measuring, and managing risks. You do not need a compliance program for every chat, but the mindset is useful: identify what matters, measure what can go wrong, and manage the risk in proportion to the consequences. See the plain-language concepts →