Also called: transparency log, tamper-evident log
In plain words
An ordinary database lets whoever runs it change history quietly. An append-only log gives that up on purpose: new entries go on the end, and old ones stay exactly as they were. Built on a Merkle tree, it becomes tamper-evident. Editing or deleting any entry changes every root after it, so the change can be detected. It doesn't have to be trusted to be honest.
This is the design Certificate Transparency made standard for web certificates: the operator can't rewrite the log without everyone who has seen a root finding out.
How QED Proof uses it
Every receipt QED Proof issues becomes a leaf in its log, including Failed and Couldn't check ones. There's no path to remove a receipt that turned out to be inconvenient. The log's roots are anchored on-chain, which fixes each one in time.
When a checker holds an anchor for a smaller tree than the receipt's, the issuer must supply an RFC 6962 consistency proof showing the older tree is a prefix of the newer one. That's how "append-only" is proven rather than promised.
Example
A receipt shows "In the log · leaf 8 of 9". If anyone later edited leaf 3, the root the receipt was anchored against would no longer be reproducible from the log, and the checker's inclusion step would fail.