Open source as evidence of work

An artifact, not a certificate

A public repository can expose code, change history, tests, and documented decisions. It does not prove on its own that a system ran in production, created business impact, or passed an independent audit.

Its evidential value depends on whether a reader can move from a claim to a specific file and from that file to a repeatable run.

The evidence chain

1. The claim states precisely what should be observable.
2. The README identifies version, scope, and run command.
3. A test checks the property named in the claim.
4. Change history shows how the result was produced.
5. Limitations state what the repository does not reveal.

What history reveals

Small, explained changes make decisions easier to reconstruct. A reader can see whether a bug received a regression test, whether the interface preceded the data contract, and where trade-offs entered the work.

Commit count is not a quality metric. What matters is the legibility of the relationship between problem, change, and verification.

The demonstration risk

A repository built for demonstration may omit private data, integrations, and operational failures. Readers should distinguish concept, prototype, pilot, and production.

Publication practice

A strong public artifact does not need an inflated description. It needs a version, instructions, tests, licence, data provenance, and an explicit limitations list.