# DEMOTE CLAIMS
:number I
:accent #d500a8
:message Honest documentation is a moat no one can fork.
:epigraph Demote claims. Do not promote them.
:drawn-from BLDBL · promptfluid/CMPSBL · CMPSBL Bestowal · RSLVBL · BulletSites · AetherionShield · RCRDBL

## THESIS

Every founder produces two descriptions of their work: the one in the marketing and the one in the database. Most spend their energy making the first sound bigger. The discipline this volume documents runs the other way: write the manual, then audit the manual against the live code, and wherever the two disagree, the code wins and the claim gets *demoted*.

The method is a six-level truth ladder. Every non-trivial claim in every manual carries a tag — [CONFIRMED] down through [SPECULATIVE] and [NEEDS CONFIRMATION] — and the standing rule is that claims only move down the ladder without fresh evidence, never up. A count is [CONFIRMED] when it comes from `psql`, not from a header comment. A feature is [OBSERVED] when it exists in committed code, even if nobody has exercised it. A vision statement is [SPECULATIVE] and says so in the same breath that states it.

This sounds like modesty. It is actually leverage. A buyer, licensee, investor, or heir reading an audited manual does not have to discount it, because the author already did the discounting. The deltas between draft and audit — the corrections themselves — become the credibility artifact: proof that the work is real and the discipline is real. Most founders need to be told what is wrong with their work. The alternative documented here is to write it down before anyone asks.

The exhibits that follow are corrections the source manuals made against their own earlier claims, published rather than buried. Read them as a genre: the self-audit as a product surface.

[[figure:truth-ladder]]


## CONTEXT — HOW TO READ THIS VOLUME

The material behind these pages is not a theory of documentation. It is twenty-nine owner's manuals written for real projects, each one audited against its own running system, and then corrected in public. This volume is the first because every other discipline in the library depends on it: a substrate you cannot measure is a story, an inheritance you cannot verify is a rumour, and a drift watch with no instruments is a mood.

Read the exhibits as evidence, not as anecdotes. Each one pairs a claim that was made with the number that survived contact with `psql`, `ripgrep`, or the test runner. The uncomfortable half is always printed with its denominator, because a demotion without its measurement is just a smaller boast. That is the whole grammar of the ladder: a claim is worth exactly as much as the mechanism that can check it.

What this volume does not argue is that modesty sells. It argues something narrower and more useful — that the audit trail is an asset. The corrections compound into a credibility artifact no competitor can fork, because forking it would require having done the work and then having told the truth about it.

## EXHIBIT A — THE 12,847 THAT BECAME 446
:source BLDBL — Founder's Owner's Manual

BLDBL is a registry of portable code blocks salvaged from shipped projects — "reuse with receipts," every block carrying a `sourcePath` back to a real file on disk. At one point its hero copy claimed "12,847 sealed builds." The audited count is 446 sealed blocks — 62 primitives, 82 components, 302 engines — and the manual states that on-disk directory counts match the registry one to one. [CONFIRMED]

The correction is not an embarrassment; it is the product's strongest claim. A registry whose marketing number survives an audit at 1:1 fidelity is a different asset class from a registry with an impressive number. The manual even preserves the distinction an evaluator needs: the repository was days old at audit, but the corpus represents years of feeder-project work absorbed in a harvest sprint. Age of methodology and age of material, stated separately. [CONFIRMED]

## EXHIBIT B — THE AUDIT THAT DEMOTED ITS OWN HEADLINE
:source promptfluid® / CMPSBL — Master Owner's Manual, v2.0 Audit Summary

The substrate's v1 manual described Cortex and SEBA as fully active subsystems. The v2 forensic audit demoted them: stubbed in the local distribution, by design. The headline capability counts — 269 capabilities, 200 synergies, 125 executors — were demoted from "observed" to "declared in source comments, not enforced by tests," with the open question stated plainly: whether every declared capability is wired end to end requires further audit. Meanwhile "266 tables" stayed [CONFIRMED], because that number came from a live `psql` count. [OBSERVED]

The audit summary also keeps a section most documentation never has: *still needs creator confirmation* — a list of things the author himself has not verified, published inside the manual. The document's authority comes precisely from what it refuses to assert.

[[figure:claim-delta]]


## EXHIBIT C — THE CHANGELOG THAT CORRECTED THE MANIFEST
:source CMPSBL Bestowal v2.1.0 — Owner's Manual

The shipped artifact's release notes correct its own layer count in public: 31 core plus 45 selectable, 76 total, where the manifest had previously claimed 42 and 67 inconsistently. Version numbers were unified across `package.json`, the manifest, and the filename before shipping. [CONFIRMED]

The same manual carries a section titled *Known Honest Constraints*: the audit chain's hash is forensic, not cryptographic, and the manual says so; only three languages are first-class while twenty-three are template-driven, and the manual says so; features reserved for v3 are named as absent from v2, and the manual says so. The constraint list is not an apology. It is a spec.

## EXHIBIT D — THE TOWN SQUARE THAT ADMITS IT IS EMPTY
:source RSLVBL — Master Owner's Manual

RSLVBL is a lore-driven discourse platform with a five-state content-decay model and simulated seed users. Its manual reports the live state without cushioning: 20 settlers, of which 19 are simulated and 1 is real; 857 transmissions, all NPC-generated; 0 echoes; 0 signal boosts. The simulated users are disclosed in the database (`is_simulated = true`) and labeled SIMULATED in the interface. [CONFIRMED]

Then the honest diagnosis: the platform side is MVP-plus, the demand side is pre-traction, and "the honest bottleneck is real-user discourse, not technology." A founder who can write that sentence about his own social product can be trusted on every other page.

## EXHIBIT E — ZERO, STATED PLAINLY
:source BulletSites — Owner's Manual · RCRDBL — Owner's Manual

BulletSites, a productized website service, reports: orders in database, 5; paid, 0. "Zero confirmed paying customers in the production database as of this audit." The same audit resolved a pricing contradiction by ripgrep — a stale $299 setup price appears nowhere in `src/`, so $499 / $29 is canonical. [CONFIRMED]

RCRDBL, an autoblog and narrative relay, reports 23 published posts of which 0 are canonical and 15 are degraded states — the system "currently operating primarily in its degraded narrative voice" — and lists six designed subsystems that have produced zero database rows to date: "designed, not exercised." [CONFIRMED]

Two projects, two uncomfortable numbers, both printed. The pattern to notice: *the zero is always accompanied by its denominator.* Not "early traction," but 5 orders, 0 paid. Not "subsystems in place," but zero rows.

## PRACTICE

**Adopt the ladder.** Six tags, or your own equivalent — the count matters less than the direction of travel. Write the rule where you will re-read it: claims move down without evidence, never up.

**Audit against the source of truth, not the docs.** A number is confirmed when it comes from the database, the filesystem, or the test runner. `psql`, `ripgrep`, and `ls | wc -l` are documentation tools. If a claim cannot be checked mechanically, tag it as the opinion it is.

**Publish the diff.** Keep a visible audit log at the top of each revision: corrections, additions, demotions. The delta between what you claimed and what you verified is the most persuasive document you own — it proves both the work and the discipline in one artifact.

**Keep a "needs confirmation" section.** An explicit list of what you have not verified converts your document's silence from a liability into a boundary. Readers trust the asserted parts more when the unasserted parts are fenced.

**State the zero with its denominator.** "5 orders, 0 paid" ages better than any euphemism, and it is the only version of the sentence you can build a real decision on.
