field notes
Short notes from real engineering work: one decision, one incident, one reversal at a time. Each one names the shape of the problem, the tension that made it hard, the decision, and what it cost. The internals stay out — the codename is the hint.
If you have five minutes rather than an afternoon: the three case studies condense this material to one problem, one decision and what the decision cost. The notes below are the record those studies cite — and the projects the codenames belong to are on the front page.
Everybody has decision templates: how a group picks among options, who may act for whom, how a bridge between two groups gets authorised. Those templates usually live in prose, and prose drifts. Two implementations of "the same" rule…
Most storage designs assume that whatever is written stays. This record assumes the opposite: keeping bytes is a recurring obligation, and an obligation with no named payer is a bug, not a policy.
A single act at the top of a layered system — one registration, one write, one listing that stays listed — touches a dozen components that each did some work. The easy answer is a central accountant that bills the caller once. That answer…
The easy way to admit a participant is one gate and one credential: pay the price, get a key. The design record refuses that, because a single gate forces a choice between two bad options — cheap enough that anyone can flood in, or…
method
Not a changelog entry and not a repository summary. One decision, one incident, one reversal, or one hard-won invariant — the thing an engineer would tell you at a whiteboard.
Prefer records with dates and root causes? Those are on incidents. Live numbers are on stats.