Schema governance
Most platforms decide a table's columns in one place, its replication behavior in a second, and its data-classification in a third, and the three drift apart. In System9 they are declared together. The canonical schema is defined in code and discovered at runtime by convention, and a schema loader applies it to both storage engines at bootstrap. The commercial consequence is precise: which data crosses which boundary is a property of the schema, not of a downstream config file somebody forgot to update.
In one paragraph
When a new table is added, its DDL, its replication policy, and its workspace-scope classification are decided at the same moment as its columns, so "which data crosses which boundary" cannot drift away from the table it describes.
Three things declared together
For every canonical table, three facts live in one declaration rather than three:
| Declared together | What it governs |
|---|---|
| The DDL | Tables, indexes, views, and triggers: the shape of the data. |
| The replication policy for that table | Whether and how the table's rows cross a cell boundary. |
| The workspace-scope classification of that table | The isolation scope the table belongs to. |
Because all three are in one place, a reviewer reading the schema can see a table's boundary behavior without cross-referencing a separate replication manifest or classification map.
How the schema reaches the engines
At bootstrap a schema loader walks the declared artifacts and applies them to both storage engines, with seed loading and schema-change retry. A governance layer validates the identity-model seed invariants before the platform accepts the schema.
*Figure: one declaration, applied and validated. The canonical schema declares DDL, replication policy, and workspace-scope classification together; it is discovered at runtime by convention and a schema loader applies it to both storage engines at bootstrap, with seed loading and schema-change retry. A governance layer validates the identity-model seed invariants and refuses a schema that violates them.
Table equivalent
| Step | Mechanism | Result |
|---|---|---|
| Declare | DDL + replication policy + classification in one artifact | The three facts cannot drift apart |
| Discover | Runtime discovery by convention | No separate registration step to forget |
| Load | Schema loader at bootstrap | Applied to both storage engines |
| Validate | Governance layer over seed invariants | A schema that breaks an invariant is refused |
| Recover | Seed loading + schema-change retry | Bootstrap survives a transient schema-change failure |
Why it is different
- Boundary behavior is co-located with the data it describes. A table's replication and isolation are decided where its columns are, so the answer to "does this cross a cell boundary?" is in the schema, not in tribal knowledge.
- The schema is validated, not just applied. The governance layer refuses a schema that breaks an identity-model invariant rather than booting into an inconsistent state.
- It works against an older database. Schema-change retry and seed loading are built for the normal case of new code meeting an older cell database. See the cell model.
Across the deployment matrix
- Single-cell, the loader applies the schema to the cell's own engines at first boot.
- Multi-cell, the per-table replication policy declared in the schema is what decides cross-cell behavior; version skew across cells is expected.
- Sovereign / air-gapped, schema discovery and loading are local; no external schema registry is in the path.
- Cloud-enabled, identical; the schema is code, not a hosted service.
Related
- Logical databases, the isolation scopes the schema classifies into.
- Classification and lineage, how classification travels once the schema sets it.
- Data lifecycle: how TTL, tombstone purge, and retention age the data the schema defines.
- Replication, DR & federation, the replication scopes a table's policy selects from.