Core concepts

The vocabulary has two halves, and the split is the same one that divides authority: design-time nouns that Studio authors, and runtime nouns that the edge produces. They meet at a project package that describes itself.

Studio project vs Edge project

"Project" is the one word that means two things, so TameChaos always keeps them apart:

The asymmetry is deliberate. A Studio project is the thing you open and own, so it earns the unqualified noun; an Edge project is a projection of something running on a server, so it always carries the qualifier. When in doubt, qualify.

Facility

A facility is a modeled physical location, and it sits between the project and the drawings: project → facility → diagrams. A diagram belongs to exactly one facility; a facility owns both halves of a place — the physical process and the comms-and-control side — and carries a real-world location. One project can hold several facilities, which is how a firm designing four plants keeps them in one place.

Facility is the entity name. Not "site", not "plant" — those are things a facility can be, not what the model calls it. Only Studio authors a facility; the edge and the cloud reference it.

Nodes, connectors, and containers

Everything you place on a topology diagram is one of three kinds of thing, and the model knows which:

• A component is a placed node — a vessel, a pump, a valve, a controller, a sensor mount.
• A connector is a typed connection between two components — a pipe, a wire, a conduit, a rail. You draw the connection first and then designate what it is, and the line re-renders in that connector's characteristics.
• A container is a node that owns what is inside it — a panel, a cabinet, a rack. Moving the container moves its members, and the container plus its members is a sub-assembly rather than a pile of unrelated parts.

The distinction is not cosmetic: it is what lets a pipe carry a diameter and a length, a panel carry its breakers, and the bill of materials count all three.

Bill of materials and the Procurement Package

A selection binds a design element to a real, catalog-referenced part. In the first release a placed node carries its own selection, so a bill of materials is generated by walking the drawing — components, connectors as procurable media, and containers with their members rolled up — with a quantity per instance and a roll-up across instances. A node you have not specified yet surfaces as a gap rather than silently disappearing.

The Procurement Package is the bill of materials plus the design that produced it — project summary, topology, control narrative, I/O, network and power summaries, and documentation references — as one versioned artifact you can snapshot, so a scope you send out stays fixed while the design moves on.

Pricing layers on top and stays budgetary: planning numbers stamped with the date they were priced, never a quote.

Sensor arrays

A sensor array is a set of inputs to a system — built from physical hardware, replay of recorded data, or model-backed virtual sensors. The abstraction is the same across all three, so an experiment does not care whether a channel is a real thermocouple or a simulated one.

Experiments and runs

An experiment is the definition of something to exercise — the sensors, the models in the loop, and the conditions to apply. A run is one execution of an experiment on the edge, in real, simulated, or hybrid mode. Runs are the record of what actually happened, and they belong to the edge that produced them.

experiment (definition)  ──run──▶  run #1  (edge A, real)
                          ──run──▶  run #2  (edge A, simulated)
                          ──run──▶  run #3  (edge B, hybrid)

Process-class templates

A process-class template describes a kind of process, independent of any single edge. When runs across the fleet instantiate the same template, they become comparable — that shared identity is the join key the cloud aggregates on.

This is what makes fleet-level learning possible: without a common template identity, runs on different edges are just unrelated time series. With it, they are a comparable set the cloud can aggregate and, in the model-loop phase, learn from.

How they fit together

A Studio project holds facilities; a facility holds diagrams; a diagram holds components, connectors, and containers; and the parts behind those become a bill of materials. On the runtime side, sensors define what you measure, experiments define what you do with them, runs are the record of doing it, and templates are what let many runs — across many edges — line up into something a fleet can improve against.

Between the two sits the self-describing project: a package that carries its own vocabulary so a runtime can read a design on that design's own terms. That boundary is committed as a design, not as a working path — see Edge and cloud for where it stands.