A certificate cannot authenticate a quantisation step by repeating its own claim
A certificate that reports its own quantisation step can simply declare it to be zero. Signed transparency leaves make later revision detectable when a verifier retains or independently obtains the required leaves and checkpoints.
An early form of the certificate carried its own per-input quantisation step and
validated it for internal consistency. That check passes on a forged
certificate, because the thing being checked and the thing doing the checking
have the same author. The concrete attack is to declare a step of exactly
0.0 — the width collapses, the arithmetic still reconciles, and every
structural test stays green.
Distinguishing unwritten from written is not a defence either. The adversary is the writer, so both states are inside their control.
The implemented fix commits per-input steps into signed RFC-6962 Merkle-tree
leaves, with inclusion and consistency proofs under a signed tree head. A
verifier can compare the certificate with a separately retained leaf or
checkpoint and detect a later revision or inconsistent view. A certificate whose
width derives from anchored steps reports width_trust: "transparency-anchored"; one that does not carries a different, weaker status.
That is revision evidence, not issuer independence. The current log, witness, and key are operated by Alelyon. Detection of a fork or rewrite depends on the comparison evidence being retained or obtained outside the issuer’s current response, and the mechanism does not establish that the original step was true.
The general rule this produced
Validate against separately retained signed evidence, not only against the shape of what the writer emitted. The same reasoning explains why the hash chain is described precisely: it protects the ledger, not the truth of the rows the ledger describes. A revision claim must name the retained evidence and comparison boundary that make the change detectable.