01
Illustration
Shows the intended shape or interaction. Useful for understanding, not proof that a live system passed.
Proof over posture.
A polished answer is not a receipt. We separate what is illustrated, what is tested, what is running, and what can be independently cited.
Four evidence levels. No quiet promotion.
Evidence becomes stronger only when the artifact and the scope become stronger. A browser animation does not become a production pass; a local test does not become an independent audit.
02
Test evidence
A repeatable check with a named target and result. Its value is bounded by what the test can observe.
03
Operating receipt
A dated, attributable record produced by the running system, with limitations and provenance intact.
04
Public record
A durable paper, benchmark artifact, filing receipt, or external review that another person can inspect.
See the shape of a receipt.
The interaction below is browser-side and illustrative. It creates no certificate, contacts no production seat, and proves no deployment claim.
Anchor
Record the ask, scope, source, and authority.
Assemble
Keep provenance and disagreement attached.
Cross-check
Run an independent, scope-aware check.
Preserve
Pass, fail, defer, or unknown—without repainting.
Ready. No production system is connected.
What we verify in the operating system
- Identity: the seat that answered matches the identity and substrate the system declares.
- Memory boundaries: lane-scoped histories do not silently become shared context.
- Provenance: chain and receipt metadata show what entered a decision path.
- Failure behavior: missing anchors, unavailable history, provider errors, and uncertainty remain visible.
- Independence: the builder is not the only verifier of public-facing work.
These are engineering verification targets. They are not a claim that every component has been independently certified.
If we cannot name the artifact, the scope, and the limitation, we do not call it proof.