Does a passing round-trip gate mean the pack is safe to forward?

It means the artifacts opened and the anchor figures were found. Whether a page carries a build path, a timestamp, or a header band the check never looked at is a separate assertion, and it needs its own measurement on the emitted bytes.

Why not just review the print settings?

Because a print rule that looks right in source has shipped invisible output more than once. Print behaviour is only observable after rendering, so the build renders the artifact and asserts on what came out.

What if the build environment has no browser?

The check reports unproven and never pass. A measurement that cannot run is a gap named on the page, not a green mark borrowed from a rule nobody measured.

Failure catalogue · The verification is theater · 36 of 51

OBSERVED FAILURE MODE

The gate that certified the leak.

A round-trip gate re-reads the artifacts a build emitted and re-runs the tie checks against them. A gate that reads the rule instead of the rendered bytes will bless a board pack carrying the build machine's temp path on every page. The verdict is green, the pack is unforwardable, and the two facts never meet.

What we saw

In our own audits a round-trip check passed a board PDF whose every page carried the build machine's temporary directory in the print chrome. The check confirmed the file existed, opened, and held the anchor figures it was told to look for. It never read the header band, because nothing in the check knew that band was there. The pack was certified, and the first person to forward it outside the building would have shipped a local file path along with the numbers.

Why it passes a glance

The gate does what it says: it opens the artifact and finds the numbers. Print chrome lives outside the content the check reads, added by the renderer after the page is written, so it appears in no source file a reviewer inspects. A check written from the build's intent passes because the intent was correct. Only the emitted bytes carry the leak.

What addresses it

The adversarial-review skill states the rule directly: any output whose correctness is not visible in the source must be rendered, run, or recomputed and compared, and when the measurement cannot run the result is unproven, never pass. Doctrine principle 6, Test that a check fires, not that it exists, adds the fire test: stamp a local path into the render, run the deployed gate through the production path, and watch this exact row turn red.

Check your own file in two minutes

Open the shipped PDF at a middle page and read the top and bottom bands, not the cover.
Extract the text of every page and search it for a path separator, a drive letter, and the build date.
Plant a local path in the render, rebuild, and confirm the round-trip gate blocks.

What this does not catch

The gate proves the build's own renderer and the bytes it produced. It cannot promise how a recipient's printer driver, a mail preview, or a converted copy will lay the pages out. Say which surface was measured, and measure again whenever the render step changes.

Quick answers

Does a passing round-trip gate mean the pack is safe to forward?: It means the artifacts opened and the anchor figures were found. Whether a page carries a build path, a timestamp, or a header band the check never looked at is a separate assertion, and it needs its own measurement on the emitted bytes.
Why not just review the print settings?: Because a print rule that looks right in source has shipped invisible output more than once. Print behaviour is only observable after rendering, so the build renders the artifact and asserts on what came out.
What if the build environment has no browser?: The check reports unproven and never pass. A measurement that cannot run is a gap named on the page, not a green mark borrowed from a rule nobody measured.

Nearby failures

The board pack that names your temp folderThe wrapper betrays the numbers The check that reads its own configurationThe verification is theater Fire-test theaterThe verification is theater

Last updated 2026-09-02 · Dylan, founder · one of 51 observed failure modes, every one seen in a real build or in our own audits, none invented.

Get the free skill → The doctrine All 51 failure modes