Five boundaries. One rule. Verify at the line, trust inside it.
THE BOUNDARY, IN FULL · ESSAY · GODFREYLEBO.DEV
General notes
- 01Everything that crosses a line is a claim until the boundary turns it into a fact. Then the code inside can be simple and confident.
- 02Five lines show up in every system. Each has its own failure, its own move, and its own sheet in this set.
Schedule of boundariesWhere it fails · What you do there
| Ref | Boundary | Failure | The move |
|---|---|---|---|
| B1 | Request enters your server | Client-claimed numbers | Recompute. Lock. Verify. |
| B2 | Document enters your parser | Hidden instructions | Sanitise before the model sees it |
| B3 | Prompt leaves for a model | Personal data reaches a sub-processor | Redact out, restore back |
| B4 | Dependency enters your build | Abandoned or hostile packages | Audit health, not just CVEs |
| B5 | Text leaves your editor | Secrets pasted into chat | Scrub before paste, restore after |
As posted
Five boundaries show up in every system I have built. Each has its own way of failing, and they all fail the same way.
A request enters your server carrying numbers the client chose. A document enters your parser carrying characters you cannot see. A prompt leaves for a model carrying a customer's details. A dependency enters your build carrying whatever its maintainer last pushed. A block of text leaves your editor for a chat window, carrying a key that was sitting in a log.
Five lines. One rule: verify at the line, trust inside it. Everything that crosses is a claim until the boundary turns it into a fact.
I wrote the long version this week. It is the essay behind this whole set: the five boundaries, the failure I have seen at each, and the move that closes it. No product pitch. No framework name. Just the line, and what to do when you are standing on it.
The first boundary has burned me twice. Sheets 003 and 012 are the record.
Essay in the first comment. Sheet 009.
Long form: read the essay behind this sheet.