Last week's proposition — "what you don't export is the boundary" — came down this week into one concrete machine. The black box.
This Week's Signal
Integrity is kept not by blocking, but by absence. The case in this month's Build piece is the dashcam. The screen is rich — you view the driving log, skip across segments, mark the moment of an incident. And yet a tool to edit, delete, or re-encode the footage simply does not exist. It isn't a "no editing" button greyed out — the very tool to do that job is not in the tool list. So the footage is never touched by a single frame. Integrity kept by permission checks and integrity kept by the absence of capability are different in kind. There's no code to break through.
'A rich screen ≠ a screen that can do anything.' The most-shared insight this week. A flashy screen doesn't mean it can do anything. A screen's capability is decided by the tools woven into it, and a tool that isn't there remains something it can't do. The black box shows this honestly — every tool for viewing is present, not one tool for changing. Richness and inviolability coexist on a single screen.
Proof of last week's proposition. If the first week's "not exposing something is the boundary" was abstract, the second week is its proof. The server (the black box's recording capability) offered only the viewing tools and closed the changing tools. It became an app by taking on a screen, but the closed part stayed closed to the end.
Tool & Package Notes
This week's note is reading the tool list backwards. Usually we ask "what can this app do?" When designing for integrity, you must ask it in reverse — "what must this app absolutely never be able to do?" And you finish by removing that answer from the tool list. Instead of adding rules that block, you don't place the dangerous capability there in the first place. Less code, fewer holes. Blocking rules always spring new leaks over time, but a capability that was never there from the start doesn't leak. Even the maintenance burden shrinks.
A Short Thought
Talk of security always drifts toward "how do we block it." A stronger lock, a finer-grained check. But the strongest lock is not making a door at all. What can't be done can't be breached. What the black box teaches is this simple asymmetry — added security is breached endlessly, subtracted security has nothing to breach. We've always piled up more capability like a badge of honor, but in some places the inability is the quality. The black box's value comes from precisely that inability to touch the footage.
From the Field
Han Do-gyeong's story touches the same grain. As he sculpted the flow of care into tools, he never, to the end, placed a tool that renders a diagnosis. Tools to gather patient information and order the sequence — richly; but a tool that outputs "it's this disease" — by its absence. Just as the black box doesn't touch the footage, his tools leave the judgment to the human. The same principle — inviolability is kept by an empty seat.
This Week's Question · Next Week's Preview
If your screen has a "thing that must never happen," ask this before writing a rule to block it. Wouldn't it be enough to simply not place the tool that does it? Next week we go deeper into how the line between exposed and unexposed is drawn — into the sense of boundary that comes with designing capability as tools.
makemind.dev "Signal" — one breath each week, gathering a week's Signal.