Why this exists
Documentation, source code, a passing test, a deployment, a live interaction, and an observed outcome are different facts. This standard keeps those facts separate so an inspectable artifact is not presented as proof of adoption or impact.
Two dimensions, not one badge
Every selected-work record states its context, such as an open-source project, internal project, professional pattern, or research program, and its maturity, from concept through operational or archived. Those fields answer different questions and are shown separately.
Evidence levels
- Illustrative
- An explanatory model, target, or architecture with no claim of delivery.
- Private evidence
- Supporting material exists but cannot be publicly inspected.
- Public artifact
- A reader can inspect source, documentation, a case account, or another bounded artifact.
- Live
- A public experience is currently reachable; availability alone is not validation.
- Independently validated
- A qualified independent source supports the bounded claim.
Required claim boundaries
Each record says what its evidence supports and what it does not. Concepts and prototypes name remaining unknowns. Live records require a working public demonstration. Independent validation requires independent evidence. Featured work must expose public evidence.
Outcomes
An observed outcome needs a dated statement and a named basis. Reader benefits, architectural intentions, targets, and illustrative timings are not observed outcomes and are not placed in that field. When no defensible public outcome exists, the record says so.
Confidential work
Private-source work may inform generalized methods and sanitized summaries. Public records never expose local paths, private repository links, proprietary identifiers, schemas, screenshots, or confidential operational detail. Generalized professional patterns do not imply a named client relationship or endorsement.
Simulation boundary
A synthetic run remains a hypothesis until appropriate real-world validation changes its evidence state. Publishing a simulator can make an implementation live and inspectable; it cannot, by itself, make the model calibrated, predictive, or independently validated.