No invented numbers: the flag system behind this site

Published Oct 12, 2026 · Updated Oct 15, 2026

1. CLAIM “The site is live” Name the actual outcome before looking for proof.
2. EVIDENCE Build exit code only It proves the build, not the public page.
3. HOLD Missing live readback Get a public-page check or narrow the claim to “build passed.”
4. PUBLISH Claim matches the check Resolve source, verification and owner-decision questions first.

Correction — October 15, 2026: the schema enforces field types and status, not factual truth. The claim-review rules below are editorial policy; no status value certifies that a claim is true.

Build-in-public has a failure mode nobody frames honestly: the channel becomes a highlight reel with numbers nobody can check. Cost figures rounded down, time-to-build rounded down, results rounded up. The audience can’t tell which claims are measured and which are vibes.

This site has a rule against that, and the rule is boring enough to publish: no invented numbers, ever. Here’s how the editorial policy is recorded in the repo, and where mechanical validation stops.

The house rule

The policy is that factual numbers need primary evidence. Historical posts cite retained receipts; newer posts also use public versioned references. Private operational receipts are not public download links, and the articles must disclose that limit. If a claim can’t point at a receipt, it either gets one or gets cut.

In practice that means posts cite things like a measured tokens-per-second figure with the qualification run it came from, or a deploy with the git commit that shipped it. Not “we saw great performance” — the actual measurement and where it lives.

The three flags

Drafts carry three kinds of unresolved claim, each with a tag you can grep for:

• [SOURCE: …] — the claim needs a primary receipt before it can stand. This is the workhorse. A build exit code can support “the build passed.” It cannot support “the site is live” without a live readback. Likewise, absence of a bill does not prove zero total cost.
• [VERIFY: …] — the claim needs a live lookup against the thing itself, not a remembered state. Prices, stock, availability, whether a link still works.
• [DECIDE: …] — the claim needs an owned business decision before it can be public. How much internal plumbing to show, whether a revenue figure is comfortable to share. These aren’t research problems; they’re judgment calls, and they block publication until the owner makes them.

A draft is allowed to be wrong. A published post is not allowed to be unchecked.

Status is a field, not a truth certificate

Status lives in each post’s frontmatter: draft or published, one or the other, enforced by the site’s content schema. Public lists and generated article routes include only published entries; drafts stay out of the public build.

The status and content share one artifact, but a mistaken published value can still expose unchecked prose. Human and agent review must resolve the claims; the schema cannot do it.

What this costs

Slower publishing. That’s the honest trade. Receipt gathering slows publication, and some posts die in draft because the verification didn’t survive contact. This post itself went through it: the sentence you’re reading was checked against the repo’s README and content schema before publishing, and the two rules quoted above are quoted, not paraphrased.

What it buys is the only currency a build-in-public site has: a reader can assume any number here was measured, and can go find where. When a claim here turns out to be wrong, it will be wrong in public, with a date — which is a better failure mode than being quietly vague.

[Source receipts: site repo README.md (content rules), src/content.config.ts (status schema), and the flag taxonomy as written in this site’s draft posts.]

Public references

Astro content collections explains schema validation. Field validation is not verification of factual claims.