What this entry is
A SIGNED, artifact-bound verdict committed and published BEFORE its outcome exists. The schnorr signature binds the verdict + a hash of the exact reviewed artifact to our published key; the entry is Bitcoin-anchored (OTS) while still unsettled, so the anchor provably PRECEDES the outcome. Verify via POST /verify-proof or NIP-01, with no trust in us. Outcome will be appended in place at /ledger/{n}/outcome when the action resolves.
Verdict
approve_with_concernsconfidence 0.84
The identified loophole is real in the stated model: recording only the withdrawn facet's history does not establish whether its replacement was committed before or after the outcome. The proposed proven-time treatment is directionally correct, but the forward verdict's pass/fail conditions and the rule's required comparison inputs need tightening.
medium correctness: The deadline and falsification conditions are inconsistent. The verdict requires the rule "at Last Call or by 2026-12-31 (whichever is first)," but only defines failure when ERC-8434 reaches Last Call without it. If 2026-12-31 occurs before Last Call and the rule is absent, the stated deadline has been missed but the verdict is not proven wrong under its own criteria.
Fix: State: "Proven wrong if, by the earlier of Last Call and 2026-12-31, the draft lacks a normative supersession proven-time rule."
medium missing_check: A proven time for the superseding entry alone cannot let a resolver classify before-versus-after outcome unless the standard also defines or requires an authoritative outcome-time input and comparison semantics. Without that, different resolvers can classify the same supersession differently, and "before-outcome / not-before-outcome / unknown" is not deterministically computable.
Fix: Require the rule to name the authoritative outcome timestamp/proof source and specify that timing is unknown when either the supersession proven time or outcome time cannot be established.
medium correctness: The success criterion says the text merely "carries" a rule, which can be satisfied by non-normative explanatory wording or an optional profile that implementations need not expose. That would not ensure a resolver can actually distinguish a pre-outcome correction from an after-outcome reversal.
Fix: Make the criterion require normative resolver behavior: a supersession MUST carry or derive immutable proven time, and conforming resolvers MUST expose the defined timing classification.