Would a freshness check have caught this?

Not one reading the export's run stamp. A stale re-export refreshes exactly that date while the figures beneath it stay old, which is why a labelled run stamp is dropped before period is measured at all.

Where should the window live?

In configuration, in one place, with a role attached: a coverage start and end, or an as-of instant. Never a bare date that five files in the build are free to interpret their own way.

What happens if the setting is empty?

The run fails loudly. A check that silently passes because nobody configured it is worse than no check at all, because it reports a safety it never actually provided.

Failure catalogue · The wrapper betrays the numbers · 48 of 51

OBSERVED FAILURE MODE

The refresh time bomb.

A reporting window's end date, written into five places in the build, works perfectly on the run it was written for. Next month's refresh then republishes last month's window under this month's heading, at a green exit code, because every place that knows the date agrees with every other place that knows it.

What we saw

In a Meridian Journal Group build, the reporting window's end date was hardcoded in five places. The first run was correct in all five. The following month's refresh recomputed everything against the same closed window, produced a full pack, tied every anchor, and published under a heading naming the new period. No check could fire, because nothing in the build disagreed with anything else in it. The failure was scheduled from the day it was written, and it arrived looking like an ordinary refresh.

Why it passes a glance

A date in code is consistent with itself, so every tie holds and every gate passes. Freshness checks reading the export's run stamp are no help either: a re-export refreshes precisely that date while the figures beneath it stay old. And the pack ships on a cadence, so the reader is watching for a change in the numbers, not a change in the window.

What addresses it

The period-freshness skill separates the coverage window, the as-of instant and the run stamp, treats the reporting period as a declared role rather than the extent of the dates present, and drops a labelled run stamp before measuring period at all. Doctrine principle 8, Thresholds are configuration, not code, puts the window in one place a person can read, where an empty setting fails loudly instead of quietly defaulting.

Check your own file in two minutes

Grep the build for date literals and count how many places know the window.
Move the window into configuration and confirm an empty value blocks the run.
Rerun last month's build unchanged and confirm it refuses rather than republishing.

What this does not catch

Configuring the window addresses drift between code paths, not a wrong window somebody configured. A file can also carry a comparison window and a run stamp that both look like the period. Prove coverage from the file's own declared dates before trusting the setting.

Quick answers

Would a freshness check have caught this?: Not one reading the export's run stamp. A stale re-export refreshes exactly that date while the figures beneath it stay old, which is why a labelled run stamp is dropped before period is measured at all.
Where should the window live?: In configuration, in one place, with a role attached: a coverage start and end, or an as-of instant. Never a bare date that five files in the build are free to interpret their own way.
What happens if the setting is empty?: The run fails loudly. A check that silently passes because nobody configured it is worse than no check at all, because it reports a safety it never actually provided.

Nearby failures

The filename that lies about the periodThe file lies The step nobody can run againThe wrapper betrays the numbers The calendar forkThe metric means something else

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