# 0003 — The witness policy belongs to the reader **Status:** Accepted **Resolves:** the witness-selection question left open by [0001](0001-anchor-substrate.md) — *"who cosigns checkpoints, and how a party outside that set gains confidence in them"*. ## Decision A log does not declare its witnesses. **A reader declares whose cosignature it requires**, as a set of named parties plus a quorum, and accepts a checkpoint only if that policy is satisfied. A reader also demands a **consistency proof** against a checkpoint it already holds before treating a new one as proven, and distinguishes *proven*, *retained but unproven*, and *rejected* in what it reports. Implemented in `monitor.py`. ## What prompted this Decision 0001 chose a witnessed transparency log over a chain and recorded two costs honestly rather than arguing them away: a log detects tampering but does not prevent it, so somebody has to audit it; and who cosigns is a trust question a chain would have answered by not having to ask. Both reduce to one question. If the log names its own witnesses, what has a reader gained? ## The reasoning **A log that announces its own witness set is a log vouching for itself.** The operator picked those parties, the operator publishes their signatures, and a reader accepting the arrangement has moved its trust from the operator to a set the operator chose. That is not a smaller trust assumption; it is the same one wearing more signatures. **A quorum alone does not fix it.** *n* signatures is satisfiable by any *n* parties the operator can produce, and an operator running its own witnesses can always produce them. The number is not the security property. **Naming particular witnesses is.** When a reader says *"I accept a checkpoint only if these three specific parties, chosen for my own reasons, have signed it"*, the operator cannot manufacture compliance. The reader's assurance is now bounded by parties it selected rather than by parties it was handed. This is the same move `read.py` makes with staleness — the tolerance belongs to the consumer because only the consumer knows what it protects — and it lands in the same place for the same reason. **Consistency proofs are what turn holding checkpoints into auditing.** A reader that accumulates checkpoints without linking them has a collection, not a history. So a new checkpoint at a larger size is *proven* only when a consistency proof against something already held verifies. A reader unable to obtain a proof should still retain the checkpoint — discarding information helps nobody — but the two cases must never be conflated, which is why they are separate outcomes rather than one boolean. ## What was rejected **A protocol-level witness registry.** Rejected. It would centralise the decision the argument above says has to be distributed, and it would make the set an operator or a governance body could change without any reader noticing. **Rejecting checkpoints that arrive without a consistency proof.** Rejected. Proof availability is an operational property, and a reader that discarded everything unproven would end up with less to reconcile against later, not more. Reporting the gap is strictly better than refusing the data. **A `healthy` summary on the report.** Rejected, and worth stating because it is the thing most likely to be added later for convenience. A monitor can say what it checked. It cannot say the log is sound, because it has only ever seen what the log chose to show it, and a green light would convert an absence of evidence into a claim. ## What this costs us **Readers have to choose.** The policy being the reader's means a reader with no opinion gets no assurance. There is no safe default we can ship, because a default we chose would be the same self-vouching arrangement one level up. **A reader alone can still be fooled.** A log serving one history to this reader and another elsewhere satisfies both readers' policies and is invisible to each. Only comparison catches it, which is what `reconcile` is for — and it means a reader that never gossips has weaker assurance than it believes. **Nothing here proves a negative.** Never having seen a bad checkpoint is not evidence none was issued. Coverage is reported as a range with its gaps visible, and that is the strongest honest statement available. ## What would reverse this 1. **A reader population that cannot make the choice.** If relying parties in practice accept whatever default is offered, per-reader policy is a fiction and the honest move is to name the assumption rather than distribute it decoratively. 2. **A gossip layer that does not materialise.** Split-view detection depends on readers comparing notes. If they do not, a chain's single global view is genuinely stronger than *n* private ones, and reversal condition 4 of [0001](0001-anchor-substrate.md) applies. ## Consequences for the work - Who *runs* monitors, and under what obligation, is still open. The mechanism exists; the operational commitment does not, and it is the same commitment as evidence availability seen from the other side. - Gossip is a function over two monitors here, not a protocol. How readers find each other and exchange checkpoints is unspecified and belongs with the availability work. - The witness set is now a deployment question rather than a protocol one, which is where this decision means it to sit.