Define the structure
Entities, fields, keys, and constraints describe how ChiralData's model is laid out for storage.
Concept · from data model to database structure
Coming soon
The structure between ChiralData and the database.
ChiralData describes state and operations. ChiralSchema turns that model into a database structure: entities, fields, relations, and the changes that keep it evolving. Still a concept; there is no CLI kit to install yet.
01 · What
ChiralSchema is the layer between the data model and a database. It defines the persisted shape, inspects what exists, and describes safe, versioned change.
Entities, fields, keys, and constraints describe how ChiralData's model is laid out for storage.
As a concept, migrations compare the declared model with the database, then record deliberate changes while preserving existing data.
02 · Why
A data model can be clear in code and still drift from what is stored. ChiralSchema names that boundary: it describes the database shape, observes what is already there, and makes change visible over time.
03 · How
The six layers move from a data contract to entities and relations, then pair planned migrations with inspection of the database. Versions and database targets complete the path to persistence.
A concept map from model to database: contracts, entities, relations, migration and inspection, versioned evolution, and database targets. These layers describe the intended boundary; they are not a claim that a CLI kit has shipped.
See the cross-domain framing in Chiral ArchitectureThe database-facing shape of the model: field types, keys, and constraints that state what can be persisted.
Named records and their fields, expressed as the tables or collections a database can store.
Links between entities, including ownership, cardinality, and the keys that keep references intact.
The paired directions: describe a schema change, then inspect the database to understand the structure that exists.
A history of schema changes that can be reviewed and applied in order, so each step has a known starting point.
The boundary where the schema meets a database dialect or adapter and becomes a physical, persisted structure.