Horizon

Same Machine, Different Hands — Authority Per Channel, Verification Left Where It Was

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.

By makemind · Aug 21, 2026

The last piece gathered several devices onto one screen. This one runs the other way. One device opens as several screens.

Back to the wheelhouse

Device (MCP server + screen description)
   ├── wheelhouse console   → full control
   ├── engine-room terminal → partial control + detailed instruments
   ├── captain's tablet     → dashboard + alarms
   └── personal phone       → status only

Same equipment. What opens depends on where you attached from.

The important part is not a different screen per channel but a different permission grade of screen per channel. It is not that the valve button is hidden on the phone; that screen never had the button.

And the party that sets those grades is the party that describes the device. The device owns the screen, so it also owns who sees what and who may touch what.

This magazine already has a sample of that shape. One server serves a kiosk screen, a counter screen and a kitchen screen depending on which machine attached. The three differ; the app is one.

Two people's hands on the same rail
Two people's hands on the same rail

The subject of verification does not change

This is what is decisive in safety-critical domains.

Ships and heavy equipment do not keep outside software out because of performance. It is liability. If there is an accident, who answers for it. So a structure that hands control outward is filtered before it is even considered.

Look at what crosses the boundary here and the answer appears: nothing does.

The device maker ports it themselves, to the specification, and sets the grade per channel. The screen description is theirs, the tools are theirs, what gets exposed is their decision. What this side supplies is the specification and a runtime that draws it.

A screen can be opened without handing control outward. And the subject of verification stays put. Whoever verified that equipment before goes on verifying it.

Nothing is taken from inside, and the position of liability does not move.

No dedicated app

A secondary freedom follows.

  • The existing dashboard can stay as it is
  • Another monitor can go on the front of the vehicle
  • The living-room TV can show status only
  • No separate tablet and phone apps get built

The last one is the largest in practice. Until now, an equipment company that wanted to give its customers a mobile screen had no route but to open an app development project. Build it, get it reviewed, maintain two platforms, and do it again when the equipment changes.

Here a channel is added. The description is the same; only the grade differs.

The screen is a window you attach through. The function is in the device.

Who Sets the Grades

That one server hands out a different screen depending on where the client attached is confirmed in the sample.

How many grades there are, and what each seat may open, is not set by this structure. It is set by whoever built the equipment. Full control at the bridge and alerts only on deck — or the reverse — separate at the same one line of declaration.

The device sets the grade and the screen is drawn from that decision. The decision itself never leaves the device.

makemind.dev "Horizon" — One server serving three screens by who attached is confirmed in the sample.

Twitter