Why the design tool moved to the front

Until recently this site opened with the edge: the authoritative runtime, the thing that owns your hardware and executes your experiments where the sensors are. That is still what the edge is, and it is still the part of the platform we would defend hardest. But it is no longer the first thing we put in front of you. TameChaos Studio leads now — the design system where a real-world system gets modeled, specified, and documented before any of it is built.

Reordering a product line-up in public invites one obvious reading — that the thing which moved down is being quietly abandoned. That reading is wrong here, and it is worth spending a post on why.

What changed is the order, not the architecture

The four products are the same four: Studio designs, Field takes that design into the field on Android, the edge executes, and the cloud aggregates across the edges you own. What changed is which one we lead with, and one architectural statement that had been implicit and is now explicit: authority divides by role, not by product.

• Studio holds design-time authority — the systems model, the type vocabulary, the symbols bound to it, the catalog selections, and the bill of materials projected from them.
• The runtime engine holds authority over execution — physics, simulation, measured reality, results. That role is realized today by the edge server.

Writing that down is what made leading with a design tool coherent instead of contradictory. "The edge is the authoritative runtime" now reads precisely: the runtime engine is authoritative over execution, wherever it is hosted, and the edge is that engine's first and current host. Nothing about execution moved into Studio.

Why the design tool goes first

Two reasons, one about our users and one about us.

The first: most of the work starts at design, and design is where a tool can be useful with zero hardware present. You can model a facility, lay out the process and control topology, draw it with symbols an instrumentation engineer recognises, mock up the operator views, and export an engineering package — with no server, no network, and nothing bought. A runtime cannot be useful that early, because there is nothing yet to run.

The second: specifying a design against real parts is where the money is. Once a placed node on a drawing carries the actual part it stands for, the bill of materials stops being a spreadsheet somebody maintains beside the drawing and becomes something the drawing produces — with quantities, the accessories and licences a part implies, and the gaps you have not specified yet named as gaps. That is the sharpest near-term value we can build, and it lives entirely on the design side.

We should be equally clear about what that means today: Studio is pre-release, with the first release targeted for August 31, 2026, and the node-first bill of materials is part of that first release rather than something you can use now. The catalog underneath it is a model and a taxonomy, not a populated database — so you will not find part counts or coverage claims anywhere on this site.

Why this is not a retreat from the edge

Because the edge was reprioritized in sequence, not in importance — and because the split above is not symmetric.

A design is a claim about what a system will do. A run is a measurement of what it actually did. A design never overrules measured reality. We considered giving Studio stronger authority over a runtime and rejected it outright: the whole value of an authoritative runtime is that the thing closest to the process gets to be right about the process. Studio owns the model; the runtime owns the result.

Everything that made the edge worth building is intact. Runs execute locally, without waiting on a network. The edge decides which templates and models it adopts. The cloud observes, aggregates, compares, and suggests, and it never starts, stops, or mutates a run — distribution is publish-and-pull, in that direction, always. Aggregation stays scoped to the edges you own; there is no cross-tenant sharing.

The seam is a package, not a pipe

The place where the two authorities meet is a self-describing project package. A project carries its own vocabulary — the base it started from plus whatever the project adds — so a runtime can learn the kinds inside a design from the package rather than from a schema both sides had to compile in advance.

That is a better boundary than a live connection between two applications, for a reason that has nothing to do with product order: it lets the vocabulary be yours to extend, and it does not care which engine eventually reads the package. It is also the honest state of things. The design → runtime export is committed as a design, not as a working path — Studio can write a structured package, but that package has not yet been validated against a live edge ingest contract, and pushing a project straight to an edge server sits outside the first Studio release. Today the seam is a package you carry, not a button that deploys.

Where this leaves you

The four products are peers, not a funnel. If you only ever model systems and hand documented packages to whoever builds them, Studio on its own is a complete answer and we are not going to pretend otherwise to sell you a runtime. If you run experiments against real hardware, the edge is exactly where it was — first in importance, third in the line-up, and unmoved in what it owns.

The docs carry the whole split in more detail: Studio for the design side, Edge and cloud for the runtime and aggregation halves, and Core concepts for the vocabulary on both sides of the boundary.