retention that names a payer or loses the thing
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.
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.
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.
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.