A Claim Ledger for the Person You Market

Somewhere in my vault there's a JSON file called the claim ledger. It holds every factual claim I'm allowed to publish about my own work — each one with an ID, a status, and a path to the file that proves it.

A JSON claim entry showing id, status, claim text, and a source file path — One entry, in full. The source field is the whole point — a claim with no traceable file cannot ship.

{
  "id": "mantium_deployment_time",
  "status": "approved",
  "claim": "Redesigned the flow for deploying a custom
            data-transformation application to others in the
            company, cutting deployment time from about two
            hours to about 30 minutes.",
  "source": "05-outputs/reports/proof-points/redesigned-enterprise-cx..."
}

Before any public artifact leaves my machine — portfolio, case study, bio — an audit script checks it against this ledger. Claims trace to sources or the export fails. Banned framings — there's a list — fail the export. A claim marked hold_for_user_confirmation is treated as removed until I personally resolve it. The audit returns PASS or the pipeline stops.

A JSON list of twenty banned marketing phrases — The banned framings are a list, not a judgment call. An export containing any of these fails whether or not the sentence around it is true.

This sounds like paranoid infrastructure for a one-person brand. Then this week it earned its keep twice.

Catch one: the machine inflated me

I had an agent draft a portfolio PDF from my public case studies. It did a beautiful job — strong layout, real metrics pulled from my own site, and the single largest element on one page was a giant orange "2,000+ users."

The ledger flagged it. That number sits at hold_for_user_confirmation because two of my own source documents disagree — one says 500+ active families, the other 2,000+ acquisitions. Those are different claims. Until I reconcile them, neither ships. The metric came out of the PDF before anyone saw it.

A JSON claim entry with status hold_for_user_confirmation — The entry that caught it. Two of my own source files disagree, so the claim is held — and held means removed, not softened.

Catch two: my website is the unreliable narrator

The uncomfortable part: the agent didn't invent that number. It got it from my own website. The site copy was written in a different era of my marketing, before the ledger existed. My live site and my truth system currently disagree, and the ledger is what noticed.

Which means the thing I built to keep AI honest turned out to be pointed at me. I don't think that's an accident. Generative tools amplify whatever claims they find lying around — write something optimistic once, and it gets repeated, reformatted, and enlarged into pull quotes forever. The only defense is a canonical record of what's actually true, checked by machine, at the exit door.

Why a designer built this

Because trust is a brand attribute, and I market exactly one brand with my name on it. Every discipline I care about — brand systems, design systems, content governance — is ultimately the same move: define the standard once, then build the production system that makes violating it hard.

A claim ledger is just a design system for facts. Tokens for truth. And like any design system, its value shows up the day someone — including you, including your own tools — tries to ship something off-spec and can't.

A JSON claim entry with status blocked_unsupported — And one that is simply blocked. The status field is the whole mechanism: the export reads it and refuses.