Edge and cloud

TameChaos divides responsibility by role, not by product. Studio is authoritative for the design, the edge is authoritative for execution, and the cloud is authoritative for definitions and identity. Getting these boundaries right is what keeps real-world control correct under bad networks while still letting a fleet learn.

Design-time authority sits with Studio

Studio owns the systems model, the type vocabulary, the symbols bound to it, the catalog selections, and the bill of materials projected from them. That authority is design-time and stops there: it does not extend into a running system, and a design never overrules what a running system measures.

This is what makes a design tool leading the line-up coherent rather than contradictory. "The edge is the authoritative runtime" reads as "the runtime engine is authoritative over execution, wherever it is hosted" — and the edge is that engine's first and current host. The edge is reprioritized in sequence, not in importance.

The edge is authoritative for execution

The edge server decides which definitions it adopts and runs, and it owns the live runs themselves. It executes the control loop locally, without waiting on the network. Nothing in the cloud can start, stop, or mutate a run — the edge holds that authority because it is the only place close enough to the process to be right about it.

The cloud is authoritative for definitions

The cloud owns template and model definitions and their identity — the registry. It issues template identity, and it observes, aggregates, compares, and suggests. A template is an inert definition until an edge instantiates a run from it.

On a second, deliberately blind surface the cloud also holds Studio project backups as client-encrypted ciphertext it has no key for. That surface is custody, not aggregation: it never inspects, decrypts, merges, or reconciles a project, and nothing in Studio requires it to function.

The boundary is a package, not a pipe

Design and runtime meet at a self-describing project package. A project carries its own vocabulary — the base it started from, plus whatever the project adds — so a runtime learns the kinds inside it from the package instead of compiling a schema both sides had to agree on first. That is also what keeps the runtime pluggable: the edge realizes the runtime role today, and a package does not care which engine reads it.

The word for this is export, not handoff — "handoff" already means the snapshot that moves a project between Mac and iPad.

The design → runtime export is committed as a design, not as a working path. Studio can 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 pushing a project directly to an edge server sits outside the first Studio release. Today the seam is a package you carry, not a button that deploys.

Publish-and-pull, never command

Because the edge is authoritative for adoption, improved templates and models are published to the fleet and pulled by edges that choose to adopt them. The cloud never pushes a change into a running system. This is the safe direction for real-world control: the device that owns the process decides what it runs.

Model improvement and distribution are the model-loop phase, on the roadmap; fleet oversight and like-process aggregation are the v1 cloud surface today. Aggregation is scoped to the edges you own — there is no cross-tenant sharing. The authority boundaries above hold in both phases: the cloud's role grows, but it never crosses into commanding the edge, and it never acquires authority over the design.