A ledger to watch
the sources over time
Two linked tables. One row per source, one row per use. A scheduled workflow would re-check every source on a cycle and raise a hand when something changes — never deciding what the change means. This page documents the design; the workflow does not exist yet.
§ 01The one rule that shapes everything
Every column belongs to exactly one of two classes. This is not a formatting choice — it is the human gate expressed as a schema. If a workflow could write to a tier, the gate would leak.
Facts a workflow can establish without judgment: does the link resolve, is there a retraction notice, has the version changed, when was it last looked at. Overwritten on every run.
Judgments a workflow must never touch: the tier, why that tier, whether the source still supports your claim, and whether it is cleared. Changed only by you.
§ 02Tab one — Sources
One row per source, forever. A source cited in six reports appears here once. This is what gets re-checked on a schedule, and what makes the checking compound instead of repeating.
| source_id | citation | type | doi / url | link status | retraction | version | last checked | tier | tier rationale | still useful |
|---|---|---|---|---|---|---|---|---|---|---|
| KC-01 | Institutional report, 2024 | institutional | 10.xxxx/kc.2024 | 200 OK | none | v1 · current | 2026-07-14 | T1 | Primary; figures in source PDF | yes |
| USAT-02 | Outlet salary database | journalism | https://…/db | 200 OK | n/a | updated 2026-06 | 2026-07-14 | T2 | Editorial standards; corroborated ×2 | yes |
| MTA-07 | Journal article, 2019 | peer-reviewed | 10.xxxx/j.2019 | 200 OK | RETRACTED | — | 2026-07-14 | T1 | Peer-reviewed at time of use | needs review |
| BLG-03 | Expert blog post | commentary | https://…/post | 404 | n/a | — | 2026-07-14 | T3 | Named expert; not independent | needs review |
§ 03Tab two — Usage
One row per use of a source. This is the tab that makes a retraction actionable: it knows every report and every claim a source is holding up.
| usage_id | source_id | report | claim supported | load-bearing | impact flag | status |
|---|---|---|---|---|---|---|
| U-014 | KC-01 | The Broken Bargain | Wealth share figures, §3 | yes | clear | cleared |
| U-031 | MTA-07 | The Manufactured Contest | Behavioral effect claim, §2 | yes | source retracted | review required |
| U-046 | MTA-07 | Before the Algorithm | Supporting context, §5 | no | source retracted | review required |
Why the split matters
A single source is checked once. The consequence lands everywhere it was used. Flatten this into one sheet and the same source gets duplicated per report — then updated in one place and not the others, which is exactly how a ledger rots.
§ 04What the workflow does on a cycle
Scheduled — weekly or monthly. It reads, checks, writes to machine columns only, and stops at the gate.
Read
Pull every row from Sources.
Check
Resolve the URL. Query Crossref/OpenAlex for retraction and version metadata.
Write
Update link status, retraction, version, last checked. Nothing else.
Propagate
Any change → flag every Usage row for that source and mark it for review.
Decide
You judge: re-tier, replace the source, soften the claim, or publish a correction.
§ 05What the workflow may never do
These are not preferences. Each one, if violated, converts the ledger from a record of verification into a source of false confidence.
- Assign or change a tier
- Mark a source "still useful" — only "needs review"
- Clear a usage row for publication
- Delete a row, ever — retired sources are marked, not removed
- Fail silently: a run that errors must notify, or you will assume it ran
Illustrative rows; no live data. Once built, the ledger becomes the enforcement mechanism for the four-pass method — an appendix entry with no ledger row behind it would not count as verified, however confident it reads. Until then, the four passes are applied by hand and recorded per report.