TameChaos
Cloud

Oversight for your fleet. Custody for your projects.

TameChaos Cloud is the non-authoritative layer above your edges. It watches the fleet, groups like-processes across it, and — on a second, deliberately blind surface — holds your Studio projects as ciphertext it has no key for. It never starts, stops, or commands a run, and nothing underneath it needs it to work.
Request beta accessSee pricing
What it is

A layer above the fleet, not a layer in charge of it

Cloud is the aggregation, coordination, and custody layer for one owner’s fleet of edge servers — and the place a Studio project can be kept without being read. It is not a runtime and not a control plane.
Non-authoritative, on purpose
Cloud observes, aggregates, compares, and suggests. Which definitions an edge adopts, and every run it executes, stay the edge’s call — improved work is published for edges to pull, never pushed at them and never commanded.
Two surfaces, opposite postures
Fleet aggregation reads what your edges report, because comparing like-processes is impossible otherwise. Studio custody reads nothing at all. One account and one identity behind both, with deliberately different amounts of knowing.
Optional at both ends
An edge server runs your experiments with no cloud in the path. Studio authors, backs up, and restores a project with no cloud either. Cloud adds a layer above them — it never becomes something they depend on.
The fleet-learning loop

Oversee, aggregate, improve, distribute

Your edges do not need a cloud to run. Connect them to one and it oversees them and compares like-processes across them — never commanding, only aggregating what edges report. Steps 1–2 ship today; steps 3–4 are the deferred model-loop phase.
Available now (v1)
1 · Oversee
A fleet registry: which edges exist, online / last-seen, software version, and their active runs.
Available now (v1)
2 · Aggregate like-processes
Group runs that instantiate the same process-class template, across edges, into comparable sets — the join key for everything downstream.
Model-loop phase — on the roadmap
3 · Improve models
Refine physics models (calibration / system identification) and inference models from aggregated like-process data.
Model-loop phase — on the roadmap
4 · Distribute
Publish improved templates and models back to the fleet for edges to pull and adopt — publish-and-pull, never command.
The TameChaos Cloud fleet registry: a fleet of five edges with online / stale / offline / unknown summary counts, and a card per edge showing its status, software version, last-seen time, active-run count, and last ingest — the cloud oversees the fleet, it never commands a run.
Cloud — fleet registry (step 1 · Oversee)
The TameChaos Cloud cross-run comparison workspace: runs grouped by a shared process-class template (“Rooftop-Unit Cooling Cycle”), comparing a metric across multiple edges into one aggregate matrix — the cloud aggregates what edges have synced, never a live stream.
Cloud — cross-run comparison (step 2 · Aggregate like-processes)
Per-fleet tenancy

A fleet gets smarter from its own operation

Aggregation and model improvement are scoped to a single owner’s fleet. There is no cross-tenant data or model sharing — your fleet learns only from its own operation.
Zero-knowledge custody

A cloud that holds your projects and cannot read them

Cloud’s second surface is a place to keep Studio projects — versioned, encrypted whole-project snapshots, uploaded from your own device. The encryption happens before anything leaves that device, and the key that opens it never goes with it. What Cloud stores is ciphertext it has no way to decrypt.
Encrypted before it leaves the device
Studio packages the whole project, encrypts it, and checksums it on your own machine. What crosses the network is already ciphertext — not a plaintext upload that a server decrypts, reads, and re-encrypts on the way past.
The key never leaves your devices
The project’s content key is sealed under a passphrase you choose, and only that sealed envelope travels with the archive. Cloud is never given the passphrase, so it holds no key material at all — nothing to leak, and nothing to subpoena.
Cloud cannot decrypt it
Not “does not” — cannot. There is no decryption capability on this side of Cloud, so a compromise of Cloud exposes ciphertext and nothing else. No inspecting, no indexing, no server-side processing of anything inside your project.
Metadata is kept to the minimum
Only what listing and lifecycle actually need: size, a checksum, when it was created, the Studio and schema versions your client declared, and an opaque reference. All of it client-supplied, none of it project content.
Never the system of record
The project on your device is the authoritative copy, always. Cloud is one destination beside your own disk, Files, and an iCloud Drive location you pick — and backup is never required for Studio to work at all.
Versioned, and yours to remove
Upload, list, download, delete. Snapshots are versioned so you can go back to an earlier one, and how many are retained is bounded by your plan rather than kept indefinitely by default.

Where this stands today

In build

The guarantee above is a decided design and part of Cloud’s first release scope — not an open door yet. Studio’s working backup destinations today are your own disk, Files, and an iCloud Drive location you choose; the Cloud destination and the relay below are the parts being built. The encryption model is not new work invented for a cloud feature: it is the same passphrase-sealed archive Studio already writes for those local destinations, which is exactly why the guarantee can be stated this precisely.

What zero-knowledge costs you

Lose the passphrase and the archive is unrecoverable — by design, and Cloud cannot help. There is no backdoor, no support-side reset, and nothing held in escrow, because every one of those would mean Cloud could read your project. That trade is what the guarantee is made of, and it is the correct one for work like facility topology, control architecture, and supplier data.

Capture relay

Transport between your devices. Nothing more.

A capture bundle is an encrypted package of field work — observations, photos, evidence — moving from the device that captured it to the one consolidating the project. Cloud can hold that bundle until the other device collects it. It does not open it, and it does not decide what happens to what’s inside.
Store and forward
Upload an encrypted bundle from one device, see what’s pending from another, download it, and it’s deleted once collected. Bundles are transient by design — this is a mailbox, not an archive.
Opaque, exactly like a snapshot
The same passphrase-sealed content key as a project archive. Cloud relays bytes it cannot open, so a bundle in flight is no more legible to it than a backup at rest.
The merge happens on your desktop
Captures arrive in a project inbox for you to review and promote into real topology, inventory, and notes. Field capture is evidence, not finished design — and telling the two apart is an engineering judgement, not a server’s.
The direct path comes first
The preferred route is still the short one: local Wi-Fi or a plain file transfer between two devices in the same room. Cloud is what you use when they aren’t.

A bundle is one way work moves — not the only one

Every Studio platform authors a real project on its own, phones included — a capture bundle is not the price of working on a small screen. It is for the case where the capture and the consolidation genuinely happen on different devices, and Cloud’s whole role in it is to hold the sealed package in between.

Two surfaces

One substrate, opposite postures toward your content

Cloud serves two kinds of client over one identity, tenancy, and object store. It reads everything one of them sends and nothing the other does — and that asymmetry is designed, not incidental.
TameChaos Cloud's two surfaces compared: content-aware fleet aggregation and content-opaque Studio custody
Fleet aggregation Studio custody
Who the client isYour edge servers, unattended, on their own device credentials.Studio, on your own devices, signed in as you.
What Cloud holdsRuns and measurements the edges report, plus process-class template and model definitions and their identity.Client-encrypted whole-project snapshots and encrypted capture bundles — opaque blobs and a thin metadata record.
What Cloud can readAll of it. Content-aware by design — aggregation is impossible otherwise.None of it. Content-opaque by design — Cloud holds no key and cannot decrypt.
What it does with itGroups like-processes, compares runs across edges, and in the later phase refines models from that data.Stores, lists, and hands back the same bytes. It never inspects, merges, or reconciles.
What it is authoritative forTemplate and model definitions, and their identity. Never adoption, never execution — that is the edge’s.Nothing. Your device holds the authoritative project; Cloud is a copy you may keep.

Same account, same sign-in, same storage underneath — two different clients with opposite content postures. Aggregation has to understand what it holds; custody must not be able to.

Honest about phasing

What’s available now, what’s being built, and what’s next

On the aggregation side, v1 is aggregation-only. Zero-knowledge custody is decided and in build. The model-improvement loop and pull-based distribution are the phase after that — we’d rather be clear than over-claim.
Available now (v1)
Aggregation across your fleet, plus the registry it builds on.
  • Fleet registry & oversight
  • Run / measurement ingestion
  • Process-class template registry + identity
  • Time-series query + cross-run comparison
In build
The zero-knowledge custody surface — decided in full, and part of the first release.
  • Zero-knowledge project backup as a Cloud destination
  • Encrypted capture-bundle relay (store-and-forward)
  • Plan-bound storage quota and snapshot retention
On the roadmap
The model-loop phase — improving and redistributing models back to the fleet.
  • Physics + inference model registry and lineage
  • Model / template distribution & adoption back to the fleet
  • Cloud-side composition of refined templates
  • Cloud-run training / physics calibration
Honest scope

Cloud observes. The edge decides. Studio owns the design.

Cloud is an aggregation and custody layer — not a runtime, not a control plane, and not the place your work lives. Here is exactly where each line sits.
How the runtime worksSee TameChaos Studio
What Cloud does
Watch the fleet, compare like-processes across it, and hold what you ask it to hold.
  • Oversee your fleet — which edges exist, their status, version, and active runs
  • Group like-processes across edges into comparable sets, and compare them
  • Issue and hold process-class template and model definitions, and their identity
  • Store client-encrypted Studio project snapshots it has no key for
  • Relay encrypted capture bundles between your own devices, then drop them
What it isn’t
The edge stays authoritative over execution, and your device stays authoritative over your project.
  • Not a runtime and not a control plane — it never starts, stops, or mutates a run
  • Not required — an edge runs, and Studio authors, with no cloud in the path
  • Not the system of record for a Studio project, and never a merge authority
  • Not able to read what it holds for Studio — no key, no decryption, no inspection
  • No cross-tenant sharing — a fleet learns only from its own operation
  • Not a SCADA or DCS replacement, and not an industrial historian

Put a fleet layer above the runtime

TameChaos Cloud is in closed beta. Request access and we’ll get you set up — your edges keep running either way, and your projects stay yours to read.
Request beta accessSee pricing