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, whether portfolio, case study, or bio, an audit script checks it against this ledger. Claims trace to sources or the export fails. Banned framings fail the export too, and there's a list. 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, whether brand systems, design systems, or 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 and 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.