Skip to main content
One deployment is one workspace. Another customer means another deployment, another database project, another private temporal node, and another identity provider organization. There is no in-process tenant partitioning.

​
What runs

  • One Go application image. The kernel. Domain-blind: no business vocabulary in Go code, the platform schema, the API shape, or the frontend.
  • One managed Postgres plus private storage. Irreducible platform state — the append-only ledger, the content-free basis catalogue, identity resolution, and task state — plus immutable platform-owned files.
  • One durable temporal node (XTDB). Synchronized source documents with their history, plus the derived object projection. It executes reads over both.
  • Connectors. Customer-owned systems stay authoritative at capture time and never share the platform’s credentials or authority path.
BigQuery and DuckDB are not runtime components, and the temporal node’s storage blocks are its own implementation state — not an application-managed lake.

​
Product interfaces and internal executables

The web application and atelier cross the same governed API boundary. There is no privileged internal path that the UI takes and the CLI does not.

​
Source repository boundary

GitHub owns the Eclipse, Atelier, and Axiom application source. A separate Code.Storage repository owns one user-admin-authored product’s Requel .rql files and canonical model-directory configuration. Their commits, branches, credentials, and release histories are unrelated—even when both use a branch named main. Code.Storage is never a mirror, backup, or push target for the application repository. Code.Storage is private Eclipse infrastructure. Eclipse exposes ordinary Git smart HTTP and an environment-scoped mirror of Code.Storage’s native repository API, preserving its resource model and wire formats. Users authenticate only to Eclipse; backend tokens, signing keys, credential-management routes, and direct Code.Storage hosts are never public. Deployment combines a GitHub-built application image with one selected, immutable Code.Storage product revision. Either side can change without rewriting the other’s history.

​
Publication and operation are separate

A model change is validated and signed by Eclipse, published by an Eclipse repository review merge, and deployed by Eclipse. Mothership loads that exact revision with the immutable secret-version lock it was built against. Live operation always follows the same arc: plan → optional review → execute → ledger. Neither rail can reach into the other’s phase.

​
Machine contracts

Both public products publish their contract, so automation never scrapes help text:
Deployment-internal Mothership separately publishes the same discovery shape for deployment automation. That does not make it a customer CLI or SDK. Automation uses --json; diagnostics go to stderr.