Getting started

TameChaos is four products over one loop: design a real-world system, run it where the sensors are, and improve the models from what those runs measure. Studio designs; the edge executes; the cloud aggregates. Each one is useful on its own, and plenty of people will only ever need the first.

These pages are documentation for the marketing site — the products themselves live on their own platforms. Use them to understand the model before you install anything.

The four products

• TameChaos Studio — the experimental design system. Model the facility, the process, and the control topology, draw it with symbols compatible with ISA-5.1 and IEC 60617, specify it against real parts, and export a documented engineering package. On Mac, iPad, iPhone, and Windows, local-first and fully offline. Pre-release: the first release is targeted for August 31, 2026.
• TameChaos Field — a distinct product built on that same design core, on Android. Standalone by default — a field device authors a real Studio project with no server, no Mac, and no network — plus what the other platforms cannot offer: an optional Edge companion for live runs, and rugged hardware.
• TameChaos Edge — the authoritative runtime. The edge server owns your hardware and executes your experiments locally, in real, simulated, or hybrid mode.
• TameChaos Cloud — non-authoritative aggregation across the edges you own, and, in the first release, zero-knowledge encrypted backup for Studio projects. It observes, aggregates, compares, and suggests. It never runs anything.

Read that order as emphasis, not as a sequence. The four are peers rather than a funnel: nothing requires you to adopt the next one, and staying inside Studio is a supported way to use TameChaos.

Design → Run → Improve

• Design — in Studio: the facility, the process topology, the instruments, the control system, the operator views, and the bill of materials that falls out of them.
• Run — on the edge: experiments and the runs they produce, against real sensors, modeled ones, or a mix of the two, executed locally without waiting on a network.
• Improve — in the cloud: aggregate runs of like processes across the edges you own, and — in the model-loop phase, on the roadmap — refine and republish the models each edge chooses to pull.

Who is authoritative for what

The most important idea in the platform is that 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. Studio needs no runtime to deliver any of that.
• The runtime engine holds authority over execution — physics, simulation, measured reality, and experiment results. That role is realized today by the edge server.
• The cloud is authoritative for definitions and identity only — the registry that templates and models get their identity from. It never starts, stops, or mutates a run.

Design and runtime meet at a self-describing project package: a project carries its own vocabulary, so a runtime learns the kinds inside it from the package rather than from a schema compiled into some other application.

Studio leading the line-up does not move execution into Studio, and it does not demote the edge — the edge is reprioritized in sequence, not in importance. A design never overrules what a running system measures.

If you remember one thing, remember that split. The rest of the docs build on it.

Where to next

• Core concepts — the vocabulary on both sides of that boundary: Studio projects and Edge projects, facilities, topology, bills of materials, sensors, experiments, and runs.
• Studio — what the design system does, which platforms it runs on, and where procurement fits.
• Edge and cloud — exactly which responsibilities sit where, and why distribution is publish-and-pull.