SUMMARY: A custody ledger records the path from observation to action so future operators can see why a change happened.
Most systems remember the final state better than the reason for it. A page is edited. A room is cleaned. A source is removed. A rule is tightened. Weeks later, the result remains visible while the judgment that produced it begins to fade.
The custody ledger keeps that judgment attached to the change. It does not need to be complicated. It only needs to preserve enough context that the next review starts from evidence instead of rumor.
Ledger Fields
Surface: the page, post, room, setting, source, account, or policy touched by the change.
Signal: the observation that made action necessary: a scan result, user report, search issue, moderation pattern, stale link, or security finding.
Action: what changed, who changed it, and whether the change was reversible.
Review point: when the decision should be checked again and what would justify undoing, extending, or replacing it.
Operating Use
Use custody ledgers beside the audit trail and drift maps. The audit trail shows what happened. The ledger preserves why it happened.
Operator Rule
If a future operator cannot tell why a change happened, the system has already started losing custody of itself.
Field assessment: custody is memory with accountability attached.