Skip to content
Merulan

Schema model

The Schema model defines Entity kinds, Relationships, and Interfaces so Records and their consumers share the same meaning.

The Schema model defines kinds, fields, and links in Company Schema. It gives Records a shape before they hold values.

Ownership

The Schema model gives each Entity kind a stable name, a display name, and declared fields. An Entity is the type. A Record is one stored instance. In the Console, /schema/entities holds Entity definitions. A field names one value slot and its rule. A reference field points to its declared target. It does not accept any Record that happens to share an identifier.

Relationships and Interfaces

The Schema model uses Relationships to define links between kinds. /schema/relationships holds those definitions. An Interface instead names a role that several kinds can fill. /schema/interfaces shows the roles and their bindings. Pipelineable, Contactable, Listable, Scoreable, and Agreement are Interfaces. A kind binds its fields to the required roles. A List targeting an Interface can then accept Records from more than one kind.

Lifecycle

The Schema model compares a change with the current definition. Added fields, removed fields, changed types, and changed Interface bindings carry different risks. Change schema safely explains which changes need a warning check or an approved plan. A retired field keeps its name reserved. The field stays in the definition for history, and its stored Record values remain.

Boundaries

The Schema model can bind a field to an exact Value Type revision. The field cannot override that revision's options, reference target, or media rule. Reusable logic owns those shared rules. The model grants no access to a field's values. Record reads and writes still apply the current Workspace and policy decisions, including when a consumer reaches the Record through an Interface.

Failures

The Schema model refuses an Interface binding whose fields do not satisfy the role. A missing field or a type that cannot fill the role makes the kind unsuitable. Reserved names such as account, person, contact, deal, and product cannot become declared business kinds. A breaking definition change also requires a matching approved plan before the write can proceed.

Recovery

The Schema model names the field or binding that needs repair. Read the current kind and correct the named field or role. Then preview the changed definition. Choose a non-reserved kind name for a business type. Use ontology.declareKind for the exact call contract and change controls. Read the kind back to check which definition became current.

  • Reusable logic helps builders choose a shared value rule or selection after the model is clear.
  • Change schema safely guides a builder through compatibility and approval before changing a kind.
  • Records and history explains what an operator reads under the declared model.