Last updated July 29, 2026

Studio

An orientation to TameChaos Studio, the experimental design system — the platforms it runs on, the design authority it holds, its standards-compatible symbols, and where procurement fits.

TameChaos Studio is the experimental design system: model a real-world system, specify it against real parts, and take a documented, procurable package out the other end. It is where most work starts, and it is standalone — Studio delivers its whole output with no runtime, no server, and no network.

Studio is pre-release. The first release is targeted for August 31, 2026, and this page marks anything that arrives with that release rather than describing it as though it already shipped.

The platforms

Studio is several implementations of one design core over one project format:

Platform	What it is
Mac	The primary engineering workstation — full canvas authoring, sourcing, and the documentation export
iPad	A touch-first authoring surface, not a viewer — topology, HMI mockups, facilities, sourcing
iPhone	The same project navigator in compact form: everything but the canvas, including node-first capture straight into the physical-process diagram
Windows	A WPF application on .NET 10, a close sibling of the Mac app on the same design core — in the first release alongside it

Android is TameChaos Field: the Android platform surface of this same core, and its own product rather than a fifth Studio build, because it adds an optional Edge companion and rugged hardware the other platforms cannot offer.

What you model

Facilities — a project holds one or more facilities, and every diagram belongs to exactly one of them. A facility owns both the physical process and the comms-and-control side of a place, and carries a real-world location.
Physical process topology — vessels, pumps, valves, sensor mounts; the connections between them designated as pipe, wire, conduit, or rail; and panels and cabinets that own what you drop inside them.
Communication and control topology — PLCs, RTUs, HMIs, historians, and gateways with protocol, segment, and vendor metadata. Drafting only: Studio does not simulate the transport.
Operator views — HMI and dashboard mockups bound to your sensors with units and thresholds. Design artifacts, not live dashboards.
The engineering notebook — markdown notes attached to the project or to any node, searchable across the project.
The documentation package — topology, comms, sourcing, mockups, and notes exported as Markdown and PDF. This is the standalone deliverable.

Design authority

Studio is the design-time authority for the systems model: the topology, the facility, the type vocabulary, the symbols bound to it, the catalog selections, and the bill of materials projected from them. Nothing upstream caps what you are allowed to model — the vocabulary is Studio's to author, not something a runtime hands down.

Two consequences worth understanding:

Projects describe themselves. In the first release a Studio project carries its own vocabulary — the base version it started from, plus whatever the project adds and the symbol bound to each kind — so it opens and validates on its own terms rather than against a schema compiled into another application.
Defining your own kinds is on the roadmap. Adding component kinds the base vocabulary does not have, binding each one a symbol, and curating a palette down to your discipline is decided, and lands after the first release.

Design authority does not mean authority over a running system. Studio owns the design; the runtime owns the result; a design never overrules what a running system measures. The two meet at that self-describing project package — a package a runtime reads and validates, not a live pipe into it. Edge and cloud covers the runtime side of the same boundary.

Standards-compatible symbols

Studio draws with a symbol library built to standard-faithful geometry — ANSI/ISA-5.1, IEC 60617, and IEC 61131-3 — redrawn in the TameChaos line style. An ISA field instrument is a bare circle with a loop tag; a gate valve is a bowtie; an IEC 61131 contact is two bars on a rung.

Each symbol carries named connection ports typed by what they carry — process, signal, electrical, mechanical, data — so an editor can route lines and refuse a connection that makes no sense. ISA loop tags are typeset over the body rather than baked into the artwork.
A general-control base covers most process and control drawings whatever the sector; water and wastewater, manufacturing, facilities, HVAC air-side, electrical, and PLC logic layer on top of it as thin profiles rather than as duplicate libraries that drift apart.
The library is drawn and shipped in the TameChaos design system today. Enabling packages per project and binding a symbol to each of your component kinds arrives with the first Studio release.

Two limits, stated plainly: the symbols are compatible with those standards and reference them by name — they are not certified against them. And standards-faithful symbols do not make Studio a P&ID editor; it remains a design and documentation environment.

Where procurement fits

Specifying a design against real parts is what makes a number at the end of it possible. The pieces, and how far each one goes today:

Capability	Where it stands
A placed node carries its own catalog part, so the bill of materials is generated from the drawing — quantity per instance, rolled up across instances	In the first release
The BOM walks the whole drawing: components, connectors as procurable media (pipe by length and diameter, wire by gauge, conduit by trade size), and enclosures as a line item plus their contents	In the first release
A vendor-neutral catalog underneath, classified by a shared taxonomy — which is what lets a line derive the accessories, licences, services, and documentation a part implies, and surface an unspecified node as a gap	In the first release
Budgetary pricing stamped with the date it was priced, rendering as stale past a threshold. Never a quote, and it never reorders or favours a vendor	In the first release
The Procurement Package — the BOM plus the design that produced it, exported as one versioned artifact you can snapshot	In the first release
Supplier offers in Sourcing — vendor-identified price breaks, stock, lead time, minimum order	On the roadmap; not a settled decision yet
A private RFQ — publish an immutable snapshot to specific vetted integrators you invite, and receive sealed bids only you can see	On the roadmap

Studio plans; it does not buy. There is no live distributor feed, no ordering rail, and no quote or purchase-order generation anywhere in it. A private RFQ is directed and never openly listed: no directory to browse, no live ranking, no integrator seeing who else you asked — and TameChaos brokers that exchange without being a party to it.

What Studio is not

Not a runtime, and not a SCADA or DCS replacement.
Not a simulation engine, a digital twin, or a live telemetry surface.
Not a historian.
Not a P&ID editor, and its standards-compatible symbols are not certified ones.
Not a purchasing system.

Where to next

Core concepts — the design-side vocabulary in detail: Studio projects, facilities, components, connectors, containers, and the bill of materials.
Edge and cloud — the runtime half of the authority boundary, and why distribution is publish-and-pull.

Core concepts

The vocabulary of TameChaos — Studio projects and Edge projects, facilities, topology nodes, connectors and containers, bills of materials, and the sensor arrays, experiments and runs the edge executes.

Edge and cloud

Which responsibilities sit on the authoritative edge, which sit in the non-authoritative cloud, and where design-time authority sits — plus why distribution is publish-and-pull, never command.