> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bijection.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Architecture

> What runs, what owns what, and where the boundaries are drawn.

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

```text theme={null}
identity provider ──── identity and grants ─────┐
signed model release ── compile ────────────────┤
                                          ▼
web / atelier / agents ──── HTTP ──►  one Go application
                                        │
                    ┌──────────────┬─────┼──────────┐
                    ▼              ▼     ▼          ▼
                 Postgres       Storage  XTDB   connectors
                facts/catalog    files   bases   capture
```

* **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.

<Note>
  BigQuery and DuckDB are not runtime components, and the temporal node's storage
  blocks are its own implementation state — not an application-managed lake.
</Note>

## Product interfaces and internal executables

| Executable   | Classification         | Owns                                                                                                                                                | Explicitly does not own                                        |
| ------------ | ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| `eclipse`    | Public product CLI/SDK | Eclipse account lifecycle requests, authoring, validation, secret versions, signed review submission, empty-repository bootstrap, explicit rollback | Infrastructure credentials, review merge, live-world authority |
| `atelier`    | Public product CLI/SDK | Governed operations over the workspace HTTP API                                                                                                     | Database, storage, connector, Git, or deployment credentials   |
| `mothership` | Deployment-internal    | Serve, migrate, capture, integrity, recovery, grant verification                                                                                    | Public SDK, authoring, or publishing a product                 |
| `panopticon` | Local-development-only | Local process supervision                                                                                                                           | Production authority or SDK                                    |

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:

```bash theme={null}
go run ./cmd/eclipse commands --json
go run ./cmd/atelier commands --json
go run ./cmd/atelier describe actions plan --json
```

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.