Changelog

What's new

A reverse-chronological log of releases across the TameChaos platform and cloud.
Direction

Studio leads the product line-up

The line-up is reordered Studio-first, design-time authority is separated from runtime authority, and Field becomes the Android surface of the Studio core — a direction entry, not a release.

This entry records a change of direction rather than a shipped release: no software went out on this date. It is here because the product line-up on this site visibly reordered, and a reordering with no explanation reads worse than the reordering itself.

What changed

  • TameChaos Studio now leads the line-up — Studio, Field, Edge, Cloud. Customer feedback and market analysis put the defensible near-term wedge at design plus procurement economics, ahead of the runtime. The order is emphasis, not a sequence: the four are peers, and staying inside Studio is a supported way to use TameChaos.
  • Authority is stated by role, not by product. Studio holds design-time authority over the systems model, the type vocabulary, the symbols bound to it, the catalog selections, and the bill of materials projected from them. The runtime engine holds authority over execution — realized today by the edge server. The two meet at a self-describing project package rather than at a shared compiled schema.
  • Studio is no longer described as an Apple product. It runs on Mac, iPad, iPhone, and Windows, and both desktop builds are in the first release. iPhone is a full authoring surface in compact form, not a capture companion.
  • TameChaos Field is the Android platform surface of that same Studio core — standalone by default, authoring a real Studio project with no server, no Mac, and no network. It remains a distinct product, because it adds an optional Edge companion and rugged hardware the other platforms cannot offer. Field is no longer described as an accessory to an edge server, or as needing one to be useful — it never did.
  • Cloud's second surface is now documented — zero-knowledge encrypted backup for Studio projects, stored as ciphertext the cloud has no key for, and never required for Studio to work.
  • "Studio project" and "Edge project" are now distinct terms everywhere. A .tcstudio package is a Studio project; a projection of a project on an edge server is always an Edge project, never a bare "project".

What is new in the documentation

  • A Studio page in the docs — the platforms, what you model, design authority and self-describing projects, the standards-compatible symbol library, and where procurement fits, each marked with how far it goes today.
  • Core concepts gains the design-side vocabulary: Studio project versus Edge project, facilities, components/connectors/containers, and the bill of materials and Procurement Package.
  • Edge and cloud gains the third leg of the authority split and the design → runtime export boundary — committed as a design, not as a working path.

What has not changed

  • The edge is still the authoritative runtime. It was reprioritized in sequence, not in importance, and nothing about execution moved into Studio. A design never overrules what a running system measures.
  • Aggregation stays scoped to the edges you own. No cross-tenant sharing of data or models, in either direction, by any surface.
  • The cloud still never commands a run. Distribution is publish-and-pull.
  • Studio is pre-release, with the first release targeted for August 31, 2026. Anything above marked as arriving in the first release has not shipped yet.
v0.3.0

Fleet oversight and like-process aggregation

The v1 cloud surface lands — fleet registry, oversight, and cross-run comparison across like-processes.

The first cut of the v1 cloud surface: oversee your fleet and compare runs across it. This is steps one and two of the fleet-learning loop; the model-loop phase remains on the roadmap.

Added

  • Fleet registry and oversight — which edges exist, online / last-seen, software version, and their active runs.
  • Like-process aggregation — group runs that instantiate the same process-class template into comparable sets across edges.
  • Cross-run comparison for A/B scenario analysis within a fleet.

Changed

  • Run ingestion now records the process-class template identity on every run, so aggregation has a stable join key.

Fixed

  • Last-seen timestamps no longer drift when an edge reconnects after an outage.
v0.2.0

Deterministic simulation and the template registry

Seedable, replayable simulation on the edge, plus the process-class template registry that later makes runs comparable.

Groundwork for fleet learning: a registry for process-class templates, and a simulation runtime that reproduces exactly.

Added

  • Process-class template registry and identity on the cloud — the definitions edges instantiate runs from.
  • Deterministic, fixed-timestep simulation on the edge: seedable and replayable, so a simulated run reproduces given the same seed.

Changed

  • Virtual, replay, and physical sensors now share one array abstraction, so experiments no longer special-case the source of a channel.

Fixed

  • Hybrid-mode runs no longer desync the simulated and real clocks under load.