A figure that moves has to say so, and a figure that was corrected has to say when

Decision

Timestamp every availability figure at the point it is rendered and state in words that it is re-polled, rather than freezing it. Give the founding narrative one owning sentence, ORIGIN_STATEMENT, and add a thirteenth claim rule that fails the build on a founding or spin-out year typed as a literal.

What was reported

An outside reviewer compared an archived copy of this site against the live one and found five differences. Two of them are addressed in D-094 above. The other three, and the conclusion he drew from all five, are this entry:

Founding narrative changed: the snapshot implies the software was spun out in 2025; the live page now says it was written in 2023 and spun out in 2026. Uptime figures shifted from 99.95% to 99.90%/99.99% between visits. Margin floor numbers, quote turnaround stats, and "km saved per van" figures also shifted slightly. Any hiring manager who refreshes the page twice, or who checks it against a cached/archived version, will immediately see the site is not a fixed historical record of a real operating division — it's a live-generated demo.

The uptime figures: his mechanism is wrong, his instinct is right

Nothing regenerated those numbers. Availability is polled from Better Stack at request time, and the headline is the *minimum* across six checks rather than the mean — a deliberate choice recorded in lib/uptime-monitor.ts, because an average lets a healthy component paper over a broken one. A minimum moves when any single check dips. It is supposed to move.

Two of the three figures he compared are not readings at all. 99.90% and 99.99% are UPTIME_FLOOR.target and UPTIME_CEILING.target — the contractual SLA numbers the homepage falls back to when no measurement window has yet reached PUBLISHABLE_WINDOW_DAYS. 99.95% is the Business-tier SLA. Three numbers from three sources, read as one number drifting, and he had no way to read them any other way: the tile said "measured", printed a percentage, and gave no indication of when it was read or that reading it again would answer differently.

That is the actual defect. A live figure that does not date itself is indistinguishable, to anybody who sees it twice, from a fabricated one.

Why not simply freeze the number

Because a frozen number here is a number nobody is measuring, and this module exists precisely because that was the previous state: PLATFORM_UPTIME_TRAILING_90 = 0.9995 sat in lib/constants.ts under the caption "trailing 90 days, measured at the API edge in ca-central-1", describing a measurement that had never been taken. Stability was exactly what made it credible and exactly what made it false. Trading a live reading for a stable fiction to satisfy a reviewer who is checking for fiction would be an unusually direct way to fail.

So: collectedAtLabel() puts an Eastern-time stamp on the reading, and LIVE_FIGURE_NOTE states the mechanism — worst of the monitored checks, re-polled every sixty seconds. Both render on the homepage tile, the /security availability panel, and the /support summary tile. The /support service board already carried a poll timestamp; it was four hundred lines below the figure the reviewer was comparing, which is the same failure as D-069 and D-071 in miniature. Context that answers a doubt has to sit where the doubt forms.

The non-publishable branch of the homepage tile now says the contractual floor "is fixed by contract and does not move", because the two branches carry different numbers under different labels and a reader diffing two visits sees one claim that changed.

The founding years: a real correction he could not distinguish from a lie

GROWTH_TIMELINE ran 2019 → 2026 until 4 August 2026, stretching a three-year history across seven, and COMPANY.founded held 2019 so /about read "seven years building software" about an engine first written in 2023. The og:description carried 2019 and 2025, both wrong. Correcting all of that was right, and the current statement — written inside the parent in 2023, spun out in 2026 — is the accurate one.

But the reviewer's only evidence was that the number had changed. He could not tell a correction from a fabrication, and neither can anyone else, because the site published the new number and nothing about the change.

Two things follow, and they are separate. The narrative gets one owner so it cannot drift silently again: ORIGIN_STATEMENT in lib/company-profile.ts interpolates FOUNDING_YEAR, YEARS_BEFORE_SPINOUT and SPINOUT_YEAR into a single sentence, and the new origin-year-as-literal rule fails the build on a year typed beside "spun out", "founded" or "written in" anywhere outside that module and lib/constants.ts. And the correction gets published with its date, which is the changelog entry accompanying this decision and the record already served at /engineering/decisions.

A changed number with a dated entry behind it reads as a company that corrected itself. The same change with no entry reads as a company making things up. The difference is not in the number.

What would make this wrong

If the availability figure stopped being a live reading — if monitoring were withdrawn and the site went back to publishing the contractual floor only — the timestamp and the note would describe a mechanism that no longer runs, which is the failure mode this entry is about. readUptime() returning unmeasured already routes every surface to a branch that says so, and the notes live only on the observed branch, so this is guarded rather than merely intended.