The transparency log: an RFC 6962 tree over the sealed record
A transparency log is an append-only record whose every entry recomputes to a published Merkle tree head, so anyone holding the entries can confirm the record they were shown matches the root. It catches an entry edited after the fact, a dropped record, and a served copy that has drifted from its source.
What a tree head proves, and what it does not
The tree is RFC 6962 verbatim; what a head adds is a single number anyone can recompute from the entries and compare. A match means the published record is internally consistent — nothing was quietly edited, dropped, or served differently from source. That is worth having and easy to over-read.
A single head does not prove the history was never rewritten. The publisher computes the root, publishes the root, and holds the data, so nothing in one head stops them recomputing after changing whatever they like. Two things fix that and neither is claimed yet: retained consistency proofs between successive heads, and witnesses who are not the publisher. Until then the head gives internal consistency, not append-only.
Unsigned on purpose
A signature over a root you computed, checked with a key you published, is ceremony with no property — what makes history provably append-only is a witness who is not you. The signature field exists in the schema and stays absent, and a partially filled signature is a validation error, because anything checking only for presence would read it as signed.
Only the past tense can be a leaf
A sealed shipping entry has a digest, so it can be a leaf. An intention decays and is never sealed, so it has no digest to commit to and cannot be one — the tree can only ever cover what already happened. This falls out of the two-tenses rule rather than being designed: the first real tree produced only shipped leaves.