The authoritative runtime
Where your experiments actually execute
TameChaos Edge is the server that owns your hardware and runs your work on it: real and virtual sensor arrays, the experiments that exercise them, and every run they produce — in real, simulated, or hybrid mode. Execution lives here. The cloud observes and aggregates above it, and never commands a run.


The runtime
Sensors, experiments, runs — on your own server
The edge server is the core product runtime. It owns the instruments, executes the experiments, holds the runs, and keeps the analysis next to the data — with no cloud in the path and none required.
- Real and virtual sensor arraysIngest real sensors from the hardware the edge server owns, and generate virtual ones from models beside them — one array, whether a signal arrives over a wire or out of a model.
- Experiments, and the runs they produceAn experiment is a timeline you can execute again and again; each execution is a run, with its own measurements, anomalies, and narrative. Runs are started, executed, and owned on the edge server.
- Real, simulated, or hybridExercise a system that exists, one that does not yet, or a mix of the two — modeled inputs standing in for instruments you have not bought. The execution mode is a property of the run, not a different product.
- Analysis where the data already isQuery and compare time series, review anomalies, and document what happened against the runs on the server that produced them. No round trip to a cloud, and no dependency on one.
Studio and the runtime
Studio owns the design. The runtime owns what happens.
Authority divides by role, not by product — and the two roles meet at a Studio project that describes itself, rather than at a live connection between two apps.
A package, not a pipe
A Studio project describes itself: it carries its own type vocabulary — the base it started from, plus whatever the project adds — so a runtime learns the kinds from the package instead of compiling a schema both sides had to agree on first.
Two authorities, by role
Studio is authoritative over the design. The runtime is authoritative over execution and over what it measures. A design never overrules a running system — that asymmetry is the point of the boundary, not an oversight in it.
The edge holds the runtime role
Runtime authority is a role, and the edge server is where it lives — first, and today. Studio owning design time moves nothing about execution off the edge; edge-first remains the default.
Where the export stands today
On the roadmapThe design → runtime export is committed as a design, not as a working path. Studio can mark a project as a deployment candidate, check it for what an export would need, and write a structured package — but that package is provisional and has not been validated against a live edge ingest contract. The wire specification and the edge's ingest side are the next step, and direct push to an edge server, along with edge pairing, sits outside the first Studio release. Today the seam is a package you carry, not a button that deploys.
What runs where
Four products, one architecture
Authority divides by role. Studio owns the design, the edge owns execution, and the cloud only observes what edges report — so you can adopt one product or all four, in any order.
| Product | Where it runs | What it owns |
|---|---|---|
| Studio | Mac · iPad · iPhone · Windows | Design authority: the systems model, control topology, facilities, standards-compatible symbols, catalog selections, and the bill of materials projected from the drawing. |
| Field | Android | The same Studio core on rugged hardware: authoring a Studio project on site, with node-first capture straight into the diagram — plus an optional Edge companion for live runs. |
| Edge | Edge server | Runtime authority: real and virtual sensor arrays, experiments and their runs, real / simulated / hybrid execution, and local analysis. |
| Cloud | Web | Non-authoritative: fleet oversight, like-process aggregation and comparison, and zero-knowledge backup for Studio projects. |
The order is emphasis, not a sequence — see all four products and what each platform can do.
Edge authority
Cloud suggests. The edge decides.
The cloud is authoritative for definitions and identity; the edge is authoritative for adoption and execution. A template is an inert definition until an edge instantiates a run from it.
The cloud owns the definitions
Template and model definitions, and their identity — the registry. Cloud issues template identity and observes, aggregates, compares, and suggests.
The edge owns execution
Which definitions it adopts and runs, and the live runs themselves. Cloud never starts, stops, or mutates a run — distribution is publish-and-pull, never command.
Cloud
Owns definitions & identity
- Template & model definitions
- Identity & registry
- Cross-run comparison
- Suggestions
publish ·
pull & adopt
pull & adopt
runs &
measurements
measurements
Edge
Owns adoption & execution
- Adopted templates
- Active runs
- Local execution
- Real-time state
Above the runtime
Connect a fleet, and the cloud only watches
Your edges do not need a cloud to run. Connect them to one and it oversees them and compares like-processes across them, scoped entirely to your own fleet — aggregating what edges report, never commanding a run. The fleet-learning loop, its phasing, and the zero-knowledge custody surface for Studio projects all live on the Cloud page.
Put a runtime behind the design
TameChaos Edge is in closed beta, and so is the cloud oversight above it. Request access and we'll get you set up.