Commitment · Foundational

The ground has one schema, and it is data

adopted a build gate proves it

The shape of every file the ground and the ledger are written in is declared once, as data: for each object, its fields in order, each field's type, whether it is required, and its values where the set is closed. The build reads that declaration and validates every file against it before any other law runs, and no rule about shape lives in code. The same declaration is emitted as JSON Schema on every build, so an editor validates a file as it is written and an agent reads the contract without reading the build.

What goes wrong without it

A shape enforced only in code is a second declaration of the ground, hidden where a reader of the ground will not look, and two declarations drift: the platform this model learned from declared its edge order in its specification and again in the tool that applied it, and the two disagreed. A knowledge graph that expects to be extended by people and by agents needs its contract where the data is, in a form both can read. The ontology literature asks the same of any shared vocabulary, that its commitments be explicit and inspectable; a schema is that commitment for shape, and the standard for stating one is JSON Schema.

What proves it — 4

Each is a gate the build runs: a check inside a ring, a whole ring, or an eval beside them. A build stops at the first that refuses.

registry integritylicensed fields
Every file conforms to the one declared schema before any other law runs: a row carries only the fields the model licenses, and every field has the type and, where the set is closed, the value the schema states, so material arriving from outside cannot introduce structure merely by arriving.
ring:0the form ring
Every file of the ground and the ledger is in canonical form.
ring:1the files ring
Every file, the two law files first, conforms to the declared schema and sits where the registries say it sits.
ring:4the artifact ring
The graph conforms to its own schema and names the ground it is a function of.

Derived from — 3

JSON Schema (draft-bhutton-json-schema-01 and draft-bhutton-json-schema-validation-01), 2022JSON Schema, draft 2020-12: core and validation specifications
W3CShapes Constraint Language (SHACL)
Thomas R. GruberToward Principles for the Design of Ontologies Used for Knowledge Sharing

Where this model stands

registry/law.json declares every object type and file the registry holds, and the graph the build writes; knowledge/law.json declares the ledger's. The key orders the canonical form writes, the fields a row may carry and the fields a kind carries are all read from these declarations.

The loaders validate every file against its declared type and refuse the build on the first departure, naming the file, the item and the field; the laws that follow only ever meet a well-formed ground.

public/schema/ holds one JSON Schema document per file type, generated by the build and identical on every build from the same law, with an editor mapping in .vscode/settings.json so a file validates as it is typed.

The build validates its own output: the graph is held to the artifact schema before it is written, and the same schema is emitted beside the others.

The two law files declare their own shape: registry/law.json carries a `law` type and a `ledger_law` type among its authoring types, drawing on the artifact's types where the law and the artifact share one, and both files are held to them before anything is derived, so a law that lost a field is refused in ring 1 rather than failing wherever it was first read.

RUL-031