Horizon

The wheelhouse console gets full control, the captain's tablet gets instruments, the phone on deck gets alarms. Same equipment, and what opens depends on where you attached from. The party that decides those grades is the party that built the device. Safety-critical domains keep outside software out for liability, not performance — and this structure does not move the liability.

MCP needed screens, and MCP Apps became the first official extension in answer. It is a well-designed specification. Its window belongs to the model, though, so remove the model and it does not open. A wheelhouse console has to be on when the power is on. Where the design premises part ways, described only from what the specification says.

The fence is already on hundreds of millions of units, so how does the ground get there. Not by fighting — it goes in as one app. The moment it is inside, that closed device becomes the place from which everything outside it can be handled. This is a story about what their device becomes, not about how we spread.

A platform that runs apps inside a device and this structure look alike from outside, but the shape of the business is reversed. There, one party — the one that owns the device — makes the business, and growth is measured in units shipped. Here, the people who own domains each make their own, and growth is measured in domains. "You can build it yourself without knowing IT or AI" was never about convenience; it was about ownership changing hands.

There is a two-day conversation between the person who designed this and an AI. In it the AI reads through the frame of the existing market first, and the designer corrects it toward the structure — four times. The record keeps the wrong claims instead of deleting them, so those four are exactly where this structure is most often misread. The quotes are the original words.

We kept being asked "how is that different from X". It turns out two different things look like this, and they resemble it at two different layers. One runs apps inside a device; the other opens a window while a model is talking. This volume answers by changing the question — not what it does, but who owns the screen.

In 2026-06 we closed the magazine's first six months with "the person who knows best what to build stands in front". That piece folded the earlier articles by summarising them, and the summarised things had no evidence. This time we fold while standing on fifteen rebuilt samples — and record that the original conclusion was only half right.

In 2026-05 we wrote that "experience kept in the same shape does not stop, it multiplies". What that "same shape" actually is was stated only in prose. This time we pay it in real things — it was six fields, and because of those six a sensor nobody had seen before fell straight into the rules. And that without an anchor, an exception cannot speak.

A server becoming an app does not mean putting every capability on a screen. What you never turn into a tool is the shape of that app, and its safety. We made that argument in 2026-04 and deferred it with "the next pieces will show you". This time we do not defer — that a capability absent from the tool list really cannot be reached is paid back in execution logs and a real board's answers.

In 2026-03 we wrote that "eight tenths of a tool is judgment, and that judgment is already in your hands". How those eight tenths sit down on a screen without an interpreter was stated only in prose. This time we pay it in real things — a farmer's piece of judgment was seven lines, and the verification stops the foreman's checklist from having a single character changed.

The two vision pieces from 2026-01 and 02 are merged into one, and every number written back then without measuring has been replaced with a measurement. Is a screen definition really small — 656 bytes. Does an edit really arrive immediately — 83 milliseconds, zero builds. And what still has to stay frozen.

For decades the domain expert explained from behind, and the developer built up front. When the screen becomes one axis you lay on, that order flips — the person who knows best what to make now stands in front. We close six months since launch with a single sentence, proven by a farmer, a teacher, a doctor, a tax accountant, and a translator.

A well-kept notebook can tell you, thirty years later, the judgment you made that day. But it stops there. Experience left in the same shape doesn't stop — it keeps growing, as the next person reads patterns one lifetime could never see, as facts become skill and skill becomes prediction. We watch experience grow across generations at compound interest, in one family's thirty years.

Anything that offers its capabilities as tools becomes an app the moment a screen ties those tools together. Server and app are no longer different things. And what you choose *not* to offer as a tool becomes the last line that keeps that app's integrity.

"Make your own tool" sounds like starting from bare ground. But the people who'd most benefit already hold the hardest foundation. What's missing is just one axis — the screen — and that axis is no longer something you build, but something you lay on. Why that twenty-percent wall was so vast, and how it came down.

Compiling is not translation. It is freezing the decisions of a moment into the device. The distribution chain we endured for decades was, in truth, the cost of thawing that ice and freezing it again. What changes when we lift that ice out of the screen layer — through history, mechanics, and objections.

What if the whole chain — build, review, install, update — simply disappeared? A look at the shift where the server becomes the app, traced through its history, its mechanics, and the hard objections.