Why every claim on this site has a receipt
A portfolio is a list of claims nobody can check, so readers discount all of them. Here every number opens its source, its method and how strong the evidence is. Including the weak ones.
I spend my days with coding agents, and the first rule I learned is that an agent's summary of its own work is weak evidence. So I stopped accepting summaries and started asking for proof. It would be odd to then ask you to take my word for everything on this site.
The problem with portfolios
A portfolio, a CV, a case study: all of them are lists of claims. "Led a transformation." "Cut latency by 90%." "Shipped in six weeks." The reader has no way to check, so a careful reader does the only sensible thing and discounts everything a little. The honest claims pay for the inflated ones.
AI makes this worse, not better. Anyone can now produce a polished case study in ten minutes. Polish no longer signals effort, and confident numbers no longer signal measurement.
What still carries information is the trail behind a claim: where the number comes from, how it was obtained, when it was checked, and whether you could check it yourself.
What a receipt is
Every claim here that could be wrong carries a small chip. Open it and you get the same six things every time :
- The claim, in one or two sentences, with its number.
- The source: a git history, a test suite, a run log, a document, a public paper.
- The method, when it matters: the command, the filter, what was counted and what was not.
- A reference: commits or files, for the record.
- The date it was checked. Numbers rot. A count from last month is labelled as such.
- Who can see the evidence. Public, or on request.
And one more field, the one I care most about: strength.
Three strengths, shown honestly
Not all evidence is equal, and pretending otherwise is the problem I am trying to avoid. So each receipt says which kind it is.
| Strength | What it means | Example |
|---|---|---|
| Measured | A number you can recount or replay with the stated method | a commit count, a test result, a cost log |
| Artifact | A file, a commit or a capture you can open | a design document, a pull request, a screenshot |
| Declared | My word, from my CV | twenty years of roles , a steel plant's IT transformation |
Declared receipts stay on the site. My career before 2023 left no git history I can show, and inventing a stronger-looking proof would defeat the point. They are marked for what they are, and references are available on request.
Most evidence is private, and that is fine
Much of the work behind this site lives in private repositories: tools I built for myself, products built for real people who did not sign up to be on a website. A receipt does not pretend otherwise. It says "private repository, walkthrough on request".
That is still worth something. A claim with a named source, a method and a date is one I can be held to in an interview. You can ask me to open the repository and run the command. If I cannot, you have learned something important about me.
The site checks itself
Receipts are not decoration typed by hand next to the text. They live in one file, each with an id, and the pages reference them by id. An unknown id fails the build . A claim cannot quietly lose its source in a later edit: the site would not deploy.
The rule for adding one is the same rule I give agents: nothing goes in without a source I have read. If a fact has no source, it gets cut, however good it sounds.
How to apply it to your own work
You do not need a website for this. The same discipline works for a CV, a promotion case or a project review.
- Write each claim as one sentence with one number. "Improved performance" is not a claim. "Cut the p90 response time from 900 to 300 ms" is.
- Attach the source and the method next to it. The query, the dashboard, the commit range. If you cannot name one, you are remembering, not measuring.
- Grade it honestly. Measured, artifact or declared. Readers trust a document more when some of it is visibly weaker.
- Date it. Then re-check the numbers you reuse.
- Cut what you cannot source. It hurts, and it makes everything left stronger.
- Make the check mechanical. A script, a build step, a reviewer who asks "where does this come from?" for every number. Anything that does not depend on you remembering to be careful.
The goal is not to look rigorous. It is to make every sentence one I am happy to defend with the evidence on the table.