1. Identify the object of study.
Technical claims should name the source file, repository, release, commit, paper, patent, specification or archived document being examined. If a version cannot be established, that uncertainty should be reported rather than silently assumed.
2. Rank evidence by what it can actually prove.
Original code, contemporaneous documentation and reproducible demonstrations can be powerful evidence for particular claims. Interviews, secondary scholarship and later recollections can supply important context, but they are not interchangeable with surviving technical artifacts. The relevance of a source depends on the claim.
3. Keep four types of statement separate.
What an identifiable source explicitly records.
What a documented test actually produced.
What investigators infer from the available record.
What the evidence does not yet establish.
4. Show the recipe when testing.
Whenever we report that code runs, fails or behaves in a particular way, the account should specify the tested version, environment, input and expected output. Untested examples should be labeled illustrative. A reconstructed historical build is not an untouched original.
5. Cite at the claim level.
Articles should use numbered inline citations with a complete Works Cited list. Dates, source organizations, titles, archive identifiers and any relevant source limitations belong alongside the evidence. Dead links should be replaced with legitimate archived copies when available, not invented alternatives.
6. Treat attribution as contested when warranted.
The earliest surviving publication, first known implementation, independently invented idea and later popularization are different milestones. We avoid assigning sole credit where the documentary record does not support it, and seek missing contributors or conflicting accounts.
7. Never silently rewrite consequential claims.
Material factual corrections should update the article and its visible revision record. Cosmetic fixes need not generate a new historical edition. Readers should be able to identify what changed and why; sensitive personal submissions may be summarized without exposing private details.
8. Separate editorial work from advertising or promotion.
Products, companies, projects and communities should be evaluated against disclosed criteria. A source provided by a vendor is relevant evidence about its own product claims, not independent corroboration of performance.
EVIDENCE IS A PUBLIC PROCESS
Disagree with the record?
We welcome a precise challenge with original evidence and a clear explanation of the correction being requested.
Prepare an evidence submission ↗