Keeping software documentation connected to the checks behind it.
01 · Context
Keeping software documentation connected to the checks behind it.
The problem
Documentation can still say a feature works after the code or its tests have changed. Cartographer tracks whether a statement is verified, stale, asserted, unknown, or failing.
My role
My independent TypeScript project for tracking evidence behind software documentation, with explicit state rules and explanations tied to their sources.
02 · Engineering decisions
How it works.
- 01Represent evidence states explicitly in a local ledger.
- 02Calculate freshness from age, change, and evidence links.
- 03Inject time to keep freshness rules testable.
- 04Keep explanatory prose separate from the deterministic state model.
- Behavior + evidence
- SQLite ledger
- Freshness rules
- Cited explanation
03 · Quality strategy
How I tested it.
Unit and integration tests exercise evidence states, freshness, CLI behavior, redaction, quarantine, and checks on explanatory claims.
04 · Result & reflection
Results so far.
A local system that records supporting evidence and uses explicit rules to flag when it becomes outdated.
Scope & limitations
Checks on citations and state contradictions are bounded safeguards, not a general guarantee against hallucination.
What I learned
The age of a check is only part of the picture. Changes to the behavior it covers also affect whether it still supports the documentation.
