Publishing Claims That Survive Being Checked: 651 Assertions, Eleven That Could Not Fail

Quick answer

A published number is a promise, and promises decay. The discipline that keeps them honest has four moving parts and none of them are clever. Attach the evidence to the claim, structurally, so the two cannot drift apart — a footnote can fall out of step with its number, a disclosure element cannot, because they are the same element. Grade every figure by how it was established, because MEASURED, CALCULATED and ASSERTED fail in different ways and a reader deserves to know which one they are holding. Stamp live values with their age, since a number with no age is a rumour with a decimal point. Then attack your own checks — not your code, your checks — because the ones that never fire look exactly like the ones that pass. In the project this class is drawn from, eleven checks turned out to be incapable of refusing anything, and the two worst defects in the build were found by looking at a phone rather than by 651 assertions that all reported green.

Key takeaways

Put the evidence inside the claim. A disclosure element cannot drift from the number it explains. A footnote can and will.
Grade it or do not publish it. If you cannot say whether a figure was measured, calculated or asserted, you do not know what it is.
A number without an age is a rumour. Render when it was read, and refuse to render it at all once that gets old enough to mislead.
Count before you change. A figure you publish once you will eventually publish eleven times, including inside structured data where nobody will ever see it rot.
Attack your own checks. Break what each one watches and confirm it objects. The ones that cannot object are worse than nothing.
INDETERMINATE is a verdict. When the spread of the instrument exceeds the question, say so instead of rounding toward the answer you want.
Look at the thing. On any question of whether something looks broken, a photograph is the better instrument.

VERIFIABLE CLAIMS · MODULE 00

Every number opens its own receipt

The reference pages for this class are a portfolio and an investor brief, and they are useful teaching material for one reason: their whole argument is that you should check them. One of them says so in its opening paragraph — every number was written by the machine or counted from its logs, and every one of them opens its own receipt — and then backs it with 62 disclosure elements whose summaries read like console output.

That is the pattern, and it is almost embarrassingly simple. The number, its grade, and a caption sit in a <summary>. The method, the sample size, the date and the exclusions sit in the body. Here is one, live — open it:

142 Measured deployments in the last 90 days

Method: Counted from the deploy log, cross-checked against release tags in the repository. Two independent sources that agree.
Sample & window: n = 2 sources · 90 days to 2026-09-21
Excludes: Rollbacks, and re-deploys of an unchanged artifact. A count with no stated exclusions is not a count.

(That figure is invented, as is every DDS-specific number in this class. The pattern is the lesson; the numbers are yours to supply.)

Closed, then open. The reader sees a number and a grade. The evidence is one click away and it is inside the claim — which is what stops the two from ever disagreeing.

Why a disclosure beats a footnote

A footnote is a second object. It lives somewhere else in the document, it is maintained separately, and when you update the number in a hurry you update the number. Six weeks later the footnote describes a measurement that no longer matches the figure above it, and nothing in your tooling knows.

A disclosure element is one object. Changing the figure means opening the markup that also contains the method and the date. You can still lie to yourself, but you have to do it deliberately, with the evidence on screen. That is the entire mechanism, and it is worth more than any amount of good intention.

The honest cost

Sixty-two receipts is sixty-two things to keep true. This pattern does not reduce work, it relocates it — from "remember to update the footnote" to "the evidence is right there and visibly wrong." That is a good trade, but only if you accept that some receipts will say uncomfortable things. The ones reading NOT VERIFIED are the most valuable on the page.

Read one, field by field

Interactive · Anatomyregion

One receipt, taken apart

Every part of a receipt is doing a job. Click a line to see which one.

142   [MEASURED]   deployments in the last 90 days

Your answers stay in this browser. Nothing is sent anywhere. Reset clears them.

VERIFIABLE CLAIMS · MODULE 01

A number without an age is a rumour

The investor page carries a telemetry strip along its top: services up, threads scheduled, spend against cap, temperature. Live values, pulled from the running system. And at the end of that strip, in the same typeface as everything else:

READ-ONLY MIRROR  ·  READING TAKEN 27 MIN AGO

That clause is the most important thing on the strip, and it exists because of a failure documented in the previous class. A health endpoint there reported ok: true and an age of 3.5 hours — on the strength of a reading taken six days earlier. The endpoint refreshed only when somebody deployed, so it was a photograph of the last deploy presented as a live feed. Both of its statements were true when they were written. Neither was evidence by the time anybody read them.

The rule, and it generalises past dashboards

A monitor refreshed by the thing it monitors is not a monitor. And its corollary, which is what this module is for: the reading has to carry its own timestamp, and the consumer has to refuse a reading that is too old rather than render it. Displaying a stale number without its age is not a smaller version of displaying a fresh one. It is a different and worse act, because it looks identical to the reader.

Three states, not two

Most live-value code has two paths: got a value, or did not. That is one state short. The third is got a value and it is too old to trust, and it needs its own rendering — not a silent fallback to the last good number, which is the single most common way a dashboard starts lying.

State	What to render	What not to do
Fresh	The value, plus its age	Omit the age because it is small
Stale	The age, prominently, and the value greyed — or nothing at all	Render it identically to fresh
Absent	An explicit "could not read", never a zero	Fall back to the last known value

That last cell matters more than it looks. An unreadable source must never become a zero, because zero is a measurement and "I could not tell" is not. The reference system's control plane gets this right and says so in its own source: unreadable files return null, never 0. One line of policy, and every downstream chart stops inventing outages.

VERIFIABLE CLAIMS · MODULE 02

The day the page contradicted itself

The portfolio page had been rebuilt to pull several figures live from the running system. It worked perfectly. The metafield reader was fresh to the second. And it was printing those live values directly beside hard-coded prose that said something different — a different service count, a different job count, and an uptime streak that was no longer true.

The audit that found it put the problem better than I can:

Why this is the worst possible failure for this particular page

“Its entire thesis is ‘check my claims against the machine.’ A visitor who does exactly what the page invites them to do finds the page disagreeing with itself.”

A page that asks to be checked has a higher duty than a page that does not. If you build the receipt pattern from module 00 and then let the figures rot, you have not published a stronger claim — you have published a self-refuting one, and handed the reader the tool to refute it.

The census, and why one number becomes eleven

Nobody sets out to publish the same stale figure twelve times. It happens because a good number gets reused: it goes in the hero, then the summary, then a card, then the FAQ, then the meta description, then the structured data, then the image alt text. Each copy was correct on the day it was written.

When the audit counted occurrences on the live HTML, one superseded figure appeared twelve times. Another appeared eleven. A FAQ answer contradicted the body copy of its own page. And several retired values were still sitting inside the JSON-LD, where no human reader will ever see them rot but every machine reading the page will.

The cheapest habit in this entire class

Before you change a published figure, search for it. All of it — body copy, headings, alt text, meta description, structured data, sitemap, and any file that generates any of those. Then make the build fail when two surfaces disagree. That single check is perhaps thirty lines and it retires an entire category of embarrassment.

Six things it would be reasonable to assume

Interactive · Ledgerclaim 1 of 6

Six assumptions, six measurements

Each row pairs something a careful person would assume about a page of published claims with what was actually measured on it.

A figure I publish appears in one place

Your answers stay in this browser. Nothing is sent anywhere. Reset clears them.

VERIFIABLE CLAIMS · MODULE 03

Eleven checks that could not fail

The previous class ended on a sentence: a check that cannot fail is not a check. This is what happened when somebody took that seriously and went looking, in a project with eighteen families of assertions and a build gate that had been green for weeks.

Two adversarial batteries against the same checks. The first flagged seventeen of forty-five assertions as dead and was wrong. The second fired forty-four of forty-five. Same code, same checks, opposite conclusions — because the first instrument could not express the failure it was looking for.

The first battery was the wrong instrument, and nearly got published

The obvious way to test a check is to break the thing it watches. So: empty each source file and see which assertions still pass. Seventeen of forty-five kept passing against an empty file. Seventeen vacuous assertions would have been a spectacular finding.

It was wrong. Emptying a file cannot falsify an assertion that something is too big — an empty file certainly does not exceed a byte ceiling. It cannot falsify an assertion that a retired claim is absent, because emptying the file removes it. And it cannot touch an assertion that reads a directory the mutation never modified. Three entire families were structurally immune to the test being used on them.

A second battery that added rather than removed — inflate the file past its ceiling, inject the forbidden string, rename the thing being matched — fired forty-four of the forty-five.

Over-fitted is worse than vacuous

One check read, in plain English, as "this file contains no nested loop over the same collection". What it actually required was a specific variable name appearing in both loop headers with no closing brace between them. Rename the array, switch to a different loop construct, or put any brace in the middle, and the check goes silent — while still reporting a pass.

It was not vacuous: there existed exactly one spelling of the defect it could catch. That is worse. A vacuous check looks suspicious the moment anybody examines it. A narrow one looks rigorous and reports a guarantee it has not earned.

Guard the guard

The nastiest one found: a contrast check that parsed colours out of the stylesheet and did the arithmetic. Breaking the parser made the check pass, with an empty failure list — no colours parsed, no failures found, green.

The fix is a numbering convention worth stealing. Every family gets an assertion numbered .0 whose only job is to assert the parse succeeded and returned a plausible number of items. Nothing downstream is trusted until that one passes. An empty result set is a claim about your parser before it is a claim about your data.

A third kind, found while building this page

Eleven gates reported this page clean. The publishing platform then refused it outright with a syntax error, because two unescaped quote characters had closed a string about nine hundred characters early.

No gate caught it, and the reason is the lesson. The gate that reads those arguments used a pattern anchored at the end of the tag, so it skipped straight over the premature quote and recovered the value intact. It was more permissive than the parser it was standing in for. It saw a well-formed argument where the real consumer saw a broken one, and reported confidence.

So the taxonomy has a fourth entry. Vacuous cannot fail. Over-fitted fails on one spelling. And too lenient approves things the real consumer will reject — which is the most dangerous of the three, because it is the only one that produces a green build and a rejected deploy at the same time. A check that is more forgiving than the system it protects you from is not protecting you from anything. If you are standing in for a parser, parse the way it parses.

Six checks. Which of them can actually refuse?

Interactive · Decidercase 1 of 6

Gate, or decoration?

Six real checks from one build gate. For each: is it capable of refusing something, or does it only look like it is?

A check requiring a specific variable name in both headers of a nested loop, with no closing brace between them. — Can it refuse?

passed against an injected real nested loop

A check asserting a stylesheet stays under a byte ceiling. — Can it refuse?

fired at 34,061 B against a 34,000 B budget

A check asserting a retired claim no longer appears, verified by emptying the file. — Can it refuse?

subtractive testing cannot see absence assertions

An assertion that the parser succeeded, run before anything trusts what it parsed. — Can it refuse?

breaking the parser now fires .0

A regex requiring every template guard that emits markup to have a fallback branch. — Can it refuse?

shipped as a narrower claim plus a NOT VERIFIED marker

A check that fails if anyone re-applies one specific wrong fix that was shipped once. — Can it refuse?

stub-verified by re-adding the bad rule

Your answers stay in this browser. Nothing is sent anywhere. Reset clears them.

The test that finds them, and it is mechanical

Take the check. Construct an input that should be refused. If you cannot build one — not "did not", but cannot — the check is not protecting you, and every green run it has produced is not evidence of anything.

Do this the week you write the check, not later. A check written while the defect is fresh is the one most likely to test the exact shape of that single defect and nothing else, which is exactly how over-fitting happens.

VERIFIABLE CLAIMS · MODULE 04

INDETERMINATE is a verdict

An eight-agent audit ran five mobile performance passes against an accepted floor of 79. Here is the row it produced, copied out of its own verdict table:

| M6 | Lighthouse mobile | >= 79 | **PASS** | median 78 [spread 78-98] |

Read it twice. The measurement is correct. Five runs, median reported honestly, spread reported honestly, tool version stated. Nothing was fudged and nothing was hidden. And then the verdict column says PASS, on the grounds — the audit's own words — that 78 “aligns with” a floor of 79.

the floor79stated in advance

the median78below it

the spread20pts78 to 98

honest verdictINDETnot pass, not miss

This is a language failure sitting on top of a good number, and it is far more common than a fabricated measurement. Nobody lied. Somebody wrote a sentence that let a miss through, using a word vague enough to carry it.

But PASS was not the right answer either — and neither was FAIL

The correct verdict is that the run does not contain the information needed to say. A twenty-point spread cannot resolve a one-point question in either direction. Calling it a miss would be exactly as unsupported as calling it a pass; both would be inventing precision the instrument does not have.

Declare it, and declare the threshold in advance

The rule that would have caught this was already written in the work order that commissioned the audit: declare INDETERMINATE when the spread exceeds the difference under discussion. It was not applied. Having the rule is not the same as having a step that checks it, which is module 03 at a different scale.

Practically: every measurement that feeds a verdict should carry n and spread, not just a median. A single number with no spread invites exactly this failure, because there is nothing on the page to argue with.

The harder case: when the property is not decidable at all

A separate check tried to assert that every template guard which emits content has a fallback branch. Three attempts:

Require a fallback from every guard. Failed on a guard that only sets a flag and correctly has none.
Narrow to guards that emit markup. Failed on a guard rendering an optional detail, which correctly has none either.
Stop.

An optional-detail guard and a required-content guard are the same construct. Only intent separates them, and a regular expression cannot read intent. The author's own note on stopping is the best sentence in the archive:

On knowing when to stop tuning

“Three attempts produced three different wrong answers, each of which would have passed if I had stopped when it agreed with me.”

What shipped was a smaller, decidable claim — the file has at least one guard whose fallback renders something — plus a NOT VERIFIED marker emitted by the gate itself, stating the gap in the gate's own output where the next person cannot miss it.

Ship a check that says what it cannot prove, rather than a fourth heuristic tuned until it stops disagreeing with you.

This page's own build gate hit the identical wall

One of the checks that assembles this page exists because an earlier class lost a sticky sidebar to a stray overflow:hidden. So the gate banned that declaration. On this build it fired — correctly finding a real declaration, on a rule that clips a figure to its border radius and cannot sit above the sidebar in the document.

The property the gate actually wants is no ancestor of a sticky element creates a scroll container, and that depends on the DOM, not on the stylesheet. It is not decidable from CSS alone. Rather than tune it a fourth time, it now asserts the smaller decidable thing — which selectors carry the declaration, each needing a written justification — and emits its own NOT VERIFIED line saying that ancestry is unchecked and only a rendered measurement can close it.

Three classes, three versions of one gate: too broad, then matching its own documentation, then honest about its limit. That progression is normal and it is not failure. What would have been failure is the fourth heuristic.

Which instrument catches which defect?

Interactive · Gate Runnercandidate 1 of 6

Run the defect down the instrument chain

Five instruments, cheapest first. For each defect, pick the first one that actually catches it.

A check that requires one specific variable name in both loop headers

Your answers stay in this browser. Nothing is sent anywhere. Reset clears them.

VERIFIABLE CLAIMS · MODULE 05

Four clean results that proved nothing

All four of these happened in a single working session, to somebody who was being careful and writing everything down. That is the point of the module: this is not carelessness, it is the normal failure rate of measurement, and the only defence is a habit rather than more attention.

What was run	What it returned	What was actually happening
A staging preview, to compare against live	A clean pass, figures all present	One digit wrong in the theme id. The platform ignored the unknown id, dropped the preview and served live twice. Caught only because the byte count was identical to the control — which a changed page cannot be.
A baseline diff against live	A failure, apparently caused by the author's own edit	The live baseline had been overwritten with a staging copy. Both files were the same file. The real cause was a stale template that predated the figure being tested.
A check that every asset returns 200	Nothing printed — read as success	The pattern required `https://`; the URLs were protocol-relative. An empty grep looks exactly like a clean one.
Measuring a byte saving on staging	A perfect result	Staging had none of the image assets — only templates had ever been pushed there. Zero bytes load when zero files exist.

The rule that caught all four

An empty or control-matching result is evidence about the instrument before it is evidence about the page.

If your measurement agrees exactly with the control, the most likely explanation is that you are measuring the control. If your search returns nothing, the most likely explanation is that your pattern is wrong. Neither is a reason for despair — both are a reason to prove the instrument can produce a different answer before you trust the answer it gave you.

And the measurement trap that inflates a finding tenfold

A responsive sweep reported 210 clipped elements on one page. Catastrophic, if true. It was not: most of those elements were inside collapsed disclosure widgets, and collapsed content reports a client width of zero. Every measurement against zero looks like enormous overflow.

Re-running with all 62 receipts expanded first cut the finding to eleven, and the worst case from 212 pixels to 35. Collapsed content cannot be measured. Open it, then measure — which is an unusually literal cost of the receipt pattern from module 00.

Find the reason each clean result meant nothing

Interactive · Huntround 1 of 3

Three green results. None of them is evidence.

Each round reports a success. In each, exactly one line explains why the success is worthless.

Round 1 — the staging previewclean pass, all figures present, byte count 191,095

compare the staged page against live before promoting

Round 2 — the asset checkno output, no errors, exit 0

confirm all twelve images return 200

Round 3 — the byte saving0 bytes transferred — a perfect result

measure how much the texture images cost on mobile

Your answers stay in this browser. Nothing is sent anywhere. Reset clears them.

A related one, from the work-order archive

Two agent sessions were writing work orders into one shared directory, using one shared number sequence, and both signing their orders with the same name. Neither could see the other's numbering. Three consecutive numbers collided, and one report was found written over another and had to be recovered by hand.

Nothing failed loudly. Each session's own view was perfectly consistent. The fix was not a smarter agent — it was to namespace the lane, give it its own directory, and write down which agent owns which queue. There was no allocator, and nothing ever checked whether a number was free.

VERIFIABLE CLAIMS · MODULE 06

651 assertions said clean. The phone disagreed.

Eight audit agents. Six hundred and forty-nine assertions. Emulated runs at 375 pixels. Lighthouse across five passes per form factor. Every one of them reported the mobile page fine.

Then somebody photographed the page on an actual phone and the platform toggles were cut in half.

The sweep tested 375 and 412. The defect appears below roughly 400. 375 is the iOS default; the phone that found it reports 360 — the most common Android width in the world.

The emulation measured it correctly and read it as passing

This is the part worth sitting with. The 375-pixel run before the photograph returned a content box of 115 pixels holding 140 pixels of content. The defect was in the data. It was simply never turned into a question.

The missing question

Nobody asked “is twenty-five pixels of overflow inside a container that hides overflow actually visible to a person?” — and a picture answers that in one second.

A device photograph is not a lesser instrument than a headless run. For anything about whether something looks broken, it is the better one, and treating it as anecdotal because it is not automated is how this defect survived 649 assertions.

Then the fix was wrong, and the phone caught that too

The repair shipped for that defect addressed a container overflow with a container property — letting the flex items wrap. The pills inside carried white-space:nowrap, so text that cannot break still could not break. The element got taller and no less broken.

The author's own post-mortem: “I saw a container overflow and reached for a container property. The real cause was the one property I never looked at.” And the reason verification missed it a second time:

Why the re-check passed

Verification ran at 375 and 412. At 412 there was enough room; at 375 it just fit. The defect lives below about 400, and the device in question reports 360.

A sweep that skips the single most common phone width is not a sweep. The list that went into the runbook afterwards, and the one this class recommends: 320, 360, 375, 412, 768, 1440 — with every disclosure expanded before anything is measured.

Two defects. Both found on a phone. Both missed by an automated suite that was, in every other respect, genuinely good. The assertions are worth keeping — they caught a byte-budget overrun the same week, and they encode named mistakes so nobody repeats them. They are not a substitute for looking at the thing on the device people actually hold.

Postscript, from building this page

The figure above — the one arguing that a sweep which skips 360 pixels is not a sweep — was laid out on a proportional axis running from 300 to 1500. That gave the four phone widths sixty-six pixels to share between them while their labels needed about a hundred and sixty-seven. The geometry gate refused to write the file, with six real collisions.

The agent auditing it did the right thing twice: it stopped rather than nudging my coordinates, and then it proved the collisions were real by re-measuring with a tight metric instead of the deliberately generous one, so that a known-conservative instrument could not be blamed for a finding it did not produce. That is module 05 applied to this page's own build.

The figure arguing that a sweep skipping 360 pixels is not a sweep was itself broken at 360 pixels. The fix was not a coordinate nudge; it was admitting that a proportional axis is the wrong chart for a set of discrete test widths.

And then the page itself shipped broken at 360

This one is worse, and leaving it out would make the rest of the class dishonest. The first version of this page went live having passed twelve build gates, two byte-for-byte checksum comparisons against the deploy target, and a complete registration. Every figure was graded. Every receipt carried its evidence. The sticky check from module 04 had been closed by a real measurement.

It was 1,448 pixels wide at every viewport below 1440. A one-line CSS omission — grid items default to a minimum width of their own content rather than zero — meant the contents rail, which is explicitly built to scroll sideways, pushed the whole page wide instead of scrolling inside it. On a phone the content rendered correctly in the leftmost 360 pixels with roughly a thousand pixels of empty space beside it.

The auditor who found it put the problem in one sentence: “Twelve gates passed, two checksum matches, registration complete — and it's broken at 360, the width this class is about. No gate renders the page.”

That is the honest limit of everything in modules 00 to 05. Static analysis checks what you wrote. It cannot check what a browser does with it. A thirteenth gate now encodes this specific omission — and it ships with a NOT VERIFIED line of its own saying that passing it establishes nothing about how the page actually lays out. The render is the check. That is why project 6 exists, and it is why the last instruction in this class is to go and look at the thing on a phone.

VERIFIABLE CLAIMS · MODULE 07

Build it yourself — seven projects

Each one is a piece of the discipline above, reduced to something you can build alone against claims you already publish. Project 1 is an evening and needs nothing but HTML.

1 · The receipt

One published figure, wrapped in a disclosure that carries its method, sample size, date and exclusions. Do it for your worst-sourced number first.

difficulty 1/5~1 evening9 steps

2 · The age stamp

Render a live value with how old it is, and build the third state — too stale to show — so an unreadable source can never quietly become a zero.

difficulty 2/5~3 hours11 steps

3 · The census

Count every occurrence of a figure across copy, metadata and structured data, then fail the build when two surfaces disagree about the same number.

difficulty 2/5~3 hours12 steps

4 · The adversary

Break what each of your checks watches, additively and subtractively, and record which ones never objected. Expect to find some.

difficulty 3/5~4 hours14 steps

5 · The meta-gate

A .0 assertion per family that guards the parser everything downstream trusts, so an empty result can never read as a clean one.

difficulty 3/5~3 hours10 steps

6 · The width sweep

Six widths, every disclosure expanded first, and a report that separates real clipping from the phantom kind. Then look at it on a phone.

difficulty 3/5~4 hours13 steps

7 · The capstone

A claims page where every figure is graded, evidenced, aged and censused — and a gate that refuses to publish it when any of the four is missing.

difficulty 5/5~1 weekendassumes 1–6

Project 1, in full

1.  Pick the figure on your site you are least able to source. Not the
    one you are proudest of - the one you would least like to be asked
    about.

2.  Answer four questions in a text file, honestly:
      method     what command, file or request produces this number
      n / window sample size and the period it covers
      excludes   what is deliberately not counted
      grade      MEASURED, CALCULATED or ASSERTED

3.  If you cannot fill in "method", the grade is ASSERTED. Write that
    down rather than upgrading the number. This step is the whole
    project and most people fail it on their first figure.

4.  Prompt, verbatim:
    "Turn this into a details/summary element. The summary shows the
     figure, a grade chip, and a one-line caption. The body is a
     definition list with method, sample, exclusions. No JavaScript."

    - you should see:  a disclosure that works with JS disabled
    - if it produces a tooltip or a modal, say no - both hide the
      evidence from search engines and from anyone printing the page

5.  GATE: delete the figure from the summary, leaving the receipt.
    The page must now look obviously broken. If it still reads fine,
    your receipt is decorative and the claim is not actually attached
    to it.

Generate the spec for your own page

Interactive · Forgelive

Your verification spec

Five answers produce the standing rules for your own claims page. Nothing is sent anywhere — the file is built in this page.

What your page makes claims about

Where live numbers come from

Stale after how many minutes

Narrowest width you support

Build gate today

Your answers stay in this browser. Nothing is sent anywhere. Reset clears them.

Bottom line

Publishing a number about yourself is a promise that it is true, and promises decay silently. The four habits that keep them honest are all cheap: put the evidence inside the claim so the two cannot drift, grade every figure by how you got it, stamp live values with their age, and count every occurrence before you change one. None of that requires tooling. You can start this afternoon with HTML and a search box.

The expensive habit is the fifth one, and it is the only one that matters when everything is green: attack your own checks. Eleven of them in one project turned out to be incapable of refusing anything. An audit measured a miss correctly and wrote PASS beside it because one word was vague enough to carry it. Four separate results looked clean and proved nothing, every time because an empty or control-matching answer was read as a finding rather than as a question about the instrument. And the two worst defects in the build were caught by a photograph of a phone, not by 651 assertions that all said fine. Keep the assertions. Then go and look at the thing.

Confidence

Measured: The structure of both reference pages — receipt counts, schema blocks and types, the reading-age string, the audience toggle — read from the live pages on 2026-09-21.
Quoted: Every incident in modules 02 to 06 is quoted or paraphrased from the build archive's own reports and reconciliations, written by their authors about their own work before this class existed. Where an author corrected themselves, the correction is theirs, not mine.
Deliberately generic: Every business figure is invented. Line counts, service counts, spend caps and revenue do not appear here. The process numbers — eleven checks, 651 assertions, a twenty-point spread, 360 pixels — are about method and are reported as measured.
Not verified: Whether the self-contradiction in module 02 has since been repaired; this class describes the state the audit found on the date it ran. And the texture discrepancy in that archive is still open — two measurements of the same bytes that do not agree, left unresolved rather than settled in the author's favour, which is the correct way to leave it.

Questions

What does it mean for a number to open its own receipt?

Every figure on the page is a disclosure element. The summary shows the number and how it was established; opening it shows the method, the sample size, the date, and what the count excludes. The point is structural rather than stylistic: a footnote can drift away from the claim it supports, because they are two separate things that have to be kept in step by hand. A disclosure cannot drift, because the claim and its evidence are the same element. If you change the number without changing the receipt, the contradiction is sitting inside one set of tags where you cannot miss it.

Why grade a number MEASURED, CALCULATED or ASSERTED?

Because those three things fail differently and a reader deserves to know which one they are looking at. MEASURED came from a command or an API response you can re-run. CALCULATED was derived from other figures, so it inherits every assumption underneath it. ASSERTED was stated by someone with no working shown, which is not a criticism but is a different kind of claim. Grading is cheap to do and immediately changes how you write: once a figure has to carry a label, you discover how many of your numbers you cannot actually source.

What is a check that cannot fail?

A test whose answer does not depend on the thing it claims to test. It is not broken code; it runs, it returns, and it reports confidence. It simply has no input that would make it say no. Across one project eleven of these were found — five by accident, four by outside audits, and two by deliberately attacking the checks rather than the code. The test that finds them is mechanical: construct an input that should be refused, and if you cannot make the check refuse anything at all, it is a report rather than a gate.

What is the difference between a vacuous check and an over-fitted one?

A vacuous check cannot fail on any input. An over-fitted check fails on exactly one spelling of the defect and is blind to every other. One real example required a specific variable name to appear in both headers of a nested loop with no closing brace between them — rename the array, use a different loop construct, or put a brace in the middle, and it goes silent while still reporting a pass. Over-fitted is the worse of the two, because vacuous checks tend to look suspicious once examined, whereas a narrow check looks rigorous and reports a guarantee it has not earned.

When should a result be INDETERMINATE rather than pass or fail?

When the spread of your instrument exceeds the difference you are trying to resolve. A mobile performance run produced a median of 78 against an accepted floor of 79, with individual runs ranging from 78 to 98. Twenty points of noise cannot settle a one-point question in either direction, so the honest verdict is not a pass and not a miss — the run does not contain the information needed to say. The audit that produced those numbers measured them correctly and then wrote PASS beside them, on the grounds that 78 aligned with a floor of 79. The measurement was fine. The sentence was not.

How do you test your own tests?

By breaking the thing each test watches and confirming the test notices. The trap is choosing a mutation your checks are structurally unable to detect. One project's first battery emptied each source file and flagged seventeen of forty-five assertions as never firing, which looked like a spectacular discovery and was wrong: emptying a file cannot falsify an assertion that something is too big, or that a retired claim is absent, or that a directory contains certain assets. A second, additive battery that inflated, injected and renamed fired forty-four of the forty-five. Same code, same checks, opposite conclusions, because the first instrument could not express the failure.

Why did 651 assertions miss a defect that a photograph caught?

Because every automated pass measured the right numbers and nobody asked the right question. Emulation reported a content box of 115 pixels holding 140 pixels of content — the defect was in the data, and it was read as passing. What was missing was a question about whether twenty-five pixels of overflow inside a hidden-overflow container is visible to a human being, and a picture answers that in one second. A device photograph is not a lesser instrument than a headless run. For anything about whether something looks broken, it is the better one.

Which screen widths should I actually test?

At minimum 320, 360, 375, 412, 768 and 1440. The specific lesson behind that list: a sweep tested 375 and 412 and shipped a defect that only appears below about 400 pixels. 375 was chosen because it is the iOS default. The phone that found the defect reports 360, which is the most common Android width in the world. A sweep that skips the single most common phone width is not a sweep. Also expand every collapsed disclosure before measuring, because collapsed content reports a client width of zero and will manufacture enormous phantom overflows that are not real.

How do numbers on a page go stale without anyone noticing?

By being published more than once. One page carried a superseded figure in twelve separate places, another in eleven, and a FAQ answer that contradicted the body text of the same page. Worse, stale values sat inside structured data where no human reader will ever see them rot. The defence is a census: before you change a figure, count every occurrence of it — including the ones in schema, meta descriptions and image alt text — and make the build fail when two surfaces disagree. A number you publish once, you will eventually publish eleven times.

Do I need a build gate to do any of this?

No. The receipt pattern is HTML, the grading is a label, and the census is a search. Those three alone will catch most of what goes wrong, and you can adopt them this afternoon. The gate becomes worth building at the point where the same mistake has embarrassed you twice, because that is when a rule you have to remember should become a rule that remembers itself. When you do build one, attack it the week you write it — the checks written while the defect is fresh are the ones most likely to test the exact shape of that one defect and nothing else.

DDS Vibe Academy · Class 93 · Free, no signup All classes · Back to top