One More Device Attached — The Host Was Not Touched

The last two pieces handled one device: it hands over its screen, and that screen arrives without an install.

Sites do not have one device. A wheelhouse has generators and ballast and a fuel gauge together. This piece is about what happens when several are gathered onto one screen.

Normally the host writes the joining

To see several devices on one screen, the app usually holds that joining in code. Which device's value goes where, which button reaches which device — the app knows.

So every added device means editing the app. And the combination is fixed at build time. When the equipment mix at a site changes, the app has to come out again.

Here the joining moves into the document

The composition profile of UI DSL 1.4 moves that joining into the document. The host does two things — hold connections, and open the origin the document names. There is no joining logic.

The document says: put the screen this connection gives here; put the screen that connection gives there.

The profile fixes four properties.

• Each device's served screen goes in unmodified. The device does not know it is being composed.
• Operations and subscriptions inside an embedded part go to that device.
• Failure is isolated per tile.
• Adding a server does not change the host.

All four are written in the specification. So we measured them on screen.

What was measured — three nodes

Three MCP nodes went up. Boiler A, Pump B, Valve C. Each serves its own screen, holds its own value, exposes its own tools. None knows the others.

Then one document that puts the three on a page. That document does not say what will be drawn. It says only which connection goes where.

① Three tiles drew as their own screens. Each with its own name, unit, colour, value. The app supplied none of it.

② A tile's button reached only its own server. Press the first tile's button and only the first server's value moves. We asked the servers directly — 29 → 30, the other two unchanged. Press the second, only the second. Press the third, only the third.

This is the quietest place composition can be wrong. The screen can draw correctly while the button goes to the wrong server, and that error does not appear on the screen.

③ One was killed. The second node was brought down. Only that tile became a fallback; the first tile stayed alive. The page and everything under it kept drawing. A screen with one of four devices off is a screen with three alive — not a blank page.

④ A third was added. Two entries went into the document — one connection, one slot. And the hash of the host binary was compared before and after.

It was the same. There was no rebuild.

Which is why the title reads that way

Be precise here. The app was not left untouched. Two entries were added to the document. To add a device, someone has to say where it goes.

What did not change is the host. The executable is identical. That means no resubmission for review, no redeployment, and nothing touched on the equipment already in the field.

That is what was measured, so that is what the title says.

What came out of this run

It did not work the first time. Both tiles were fallbacks at first, and finding out why took several control lines.

Four defects on this structure's side came out of it, and all four were fixed — a connection failure sitting silent for thirty seconds before timing out; calling a tool that does not exist returning success; a failed connection not arriving on the failure path; and several actions attached to one callback being dropped in silence.

Half of those were caused by our own document being outside the contract. The real reason the screen was empty was on that side. And the one where a missing tool returned success was caught by a control line put in on the side, while looking for something else — a defect nobody was looking for.

The bench laid out to measure composition surfaced a defect a layer below it at the same time.