Every entry in this ledger opens with the verdict. The first paragraph states the answer outright, and the sections after it explain the mechanism for anyone who wants to check the reasoning. The pattern is BLUF, bottom line up front, borrowed from military and wire-service writing, and it governs everything we publish here.
The reason is simple: respect for reader time, plus the way answer engines quote. Machines lift the first paragraphs of a page. If those paragraphs are warm-up, the warm-up is what gets quoted. If they are the answer, the answer is what gets quoted. So we put the answer there on purpose, every time.
The verdict is a field, not a habit
A style rule enforced by willpower decays. So we made the bottom line structural: every entry carries its verdict as a field in its frontmatter, right next to the title and date. That field renders as the "bluf" box at the top of the page and doubles as the meta description, so feeds, link previews, and AI answer surfaces get the verdict even when they never load the page. The prose can be skimmed, skipped, or scraped; the verdict travels anyway.
This is one of the payoffs of keeping this blog as MDX files in a repo. The answer is a piece of data sitting beside the prose, not a sentence we hope someone remembered to write, and it ships with every copy of the entry.
Why the first paragraphs must be the answer
Two audiences read the top of a page, and both stop early.
Humans decide in a paragraph whether the page is for them. A warm-up opener spends that paragraph proving nothing. An answer-first opener either satisfies them immediately or tells them exactly why to keep reading: they have the claim, and now they want the mechanism.
Answer engines are blunter. They quote the opening and move on. We do not control what they select, but we control what is there to select. The first paragraphs are the only real estate we can be sure gets read, so they carry the whole verdict.
| Surface | What it reads | What it should find |
|---|---|---|
| Feed or link preview | frontmatter | the verdict |
| Answer engine | first paragraphs | the answer, stated plainly |
| Human skimmer | headings and openers | enough to decide in seconds |
The same rule runs the shop
Entries here are the public face of a rule we already live by internally. Our docs and issue slices carry a description block up top, and that block decides whether the reader needs the body at all. An agent routing through our repo reads headers first and opens a body only when the header says it matters; the whole scheme is laid out in headers-first docs that agents can route.
The product works the same way. A Receipt leads with the verdict, criterion by criterion, and holds the evidence underneath for anyone who wants to audit it. Verdict first, mechanism second is not a blog affectation. It is how we think evidence should be packaged everywhere.
The test we apply before publishing
Every draft gets one question before it ships:
If the reader stops after the first paragraph, did they get the answer?
If the honest response is no, the entry is not done, whatever its word count. The fix is usually mechanical: find the sentence where the draft finally commits to a claim, and move it to the top. The rest of the piece rarely needs to change. It was always the mechanism section; it just had the wrong thing in front of it.
Where this goes next
The verdict field started as a writing discipline, and it is turning into an interface. Anything that can read frontmatter can ask this ledger a question and get a one-sentence verdict without parsing prose. We plan to keep tightening that contract: shorter answers, stricter checks, and the same headers-first shape across every document we produce, public or internal. The bottom line stays up front, and increasingly, the bottom line is the interface.