Skip to main content

Constitutional Structure (Part V)

20. Constitutional Schemas (CS)​

20.1. Introduction​

Constitutional Schemas (CS) define the authoritative constitutional structure of Constitutional Objects within the ZAYAZ constitutional ecosystem.

A Constitutional Schema specifies how a Constitutional Object is structurally composed, independently of any implementation technology, storage model, programming language or exchange format.

It establishes the constitutional contract governing the organisation, composition and structural integrity of Constitutional Objects.

A Constitutional Schema is not:

  • a JSON Schema;
  • an XML Schema;
  • a relational database schema;
  • a GraphQL schema;
  • an OpenAPI definition;
  • an RDF ontology;
  • a programming language class;
  • a serialization format.

Those are implementation artefacts that MAY be generated from Constitutional Schemas.

20.2. Purpose​

The purpose of Constitutional Schemas is to establish a technology-independent structural model for every Constitutional Object.

The Constitutional Schema architecture provides:

  • structural definition;
  • object composition;
  • structural semantics;
  • property organisation;
  • inheritance;
  • composition rules;
  • extensibility;
  • compatibility;
  • versioning;
  • validation;
  • compilation;
  • interoperability.

By separating constitutional structure from implementation, the same Constitutional Object may be represented consistently across multiple technologies without redefining its constitutional meaning.

20.3. Constitutional Principle​

Every Constitutional Object SHALL conform to a recognised Constitutional Schema.

A Constitutional Schema SHALL define the constitutional structure of the object independently of implementation technologies.

No implementation schema SHALL supersede or redefine a Constitutional Schema.

Implementation artefacts SHALL be derived from Constitutional Schemas through governed compilation.

20.4. Constitutional Position​

Constitutional Schemas define the structural layer of the constitutional architecture.

Constitutional Knowledge Model
        │
        │ defines concepts
        ▼
Constitutional Metadata Dictionary
        │
        │ defines metadata
        ▼
Constitutional Schema
        │
        │ defines structure
        ▼
Constitutional Object
        │
        ▼
Compiler
        │
        ▼
JSON Schema
GraphQL
SQL
OpenAPI
RDF
SDKs

The Constitutional Schema therefore bridges constitutional semantics and implementation.

20.5. Constitutional Schema as a Constitutional Object​

Every Constitutional Schema SHALL itself be represented as a specialised Constitutional Object.

Each schema SHALL possess:

  • Constitutional Identifier;
  • canonical name;
  • semantic definition;
  • schema classification;
  • governing authority;
  • applicability;
  • version;
  • lifecycle;
  • provenance;
  • relationships;
  • validation requirements;
  • publication profile.

Because schemas are Constitutional Objects, they participate in the same governance, lifecycle, traceability and validation mechanisms as every other constitutional artefact.

20.6. Schema Registry​

Constitutional Schemas SHALL be governed through a dedicated Constitutional Registry.

The Schema Registry SHALL govern:

  • schema identities;
  • schema definitions;
  • structural relationships;
  • compatibility;
  • inheritance;
  • composition;
  • lifecycle;
  • provenance;
  • version history;
  • publication.

Every Constitutional Schema referenced within the constitutional ecosystem SHALL be resolvable through the Constitutional Registry Registry.

20.7. Structural Identity​

Every Constitutional Schema SHALL possess a globally unique Constitutional Identifier.

Schema identity SHALL remain stable across:

  • implementation changes;
  • generated schemas;
  • language bindings;
  • storage technologies;
  • documentation formats.

Renaming a generated JSON Schema SHALL NOT change the Constitutional Schema identity.

20.8. Schema Classification​

Every Constitutional Schema SHALL declare its Schema Classification.

Typical classifications include:

Core Schemas

  • Constitutional Object
  • Constitutional Registry
  • Registry Entry

Governance Schemas

  • Constitutional Authority
  • Constitutional Role
  • Authority Assignment

Semantic Schemas

  • Metadata Definition
  • Value Provider
  • Value Set
  • Validation Source

Behaviour Schemas

  • Resolution Policy
  • Validation Rule
  • Workflow Definition

Structural Schemas

  • Template
  • Profile
  • Package
  • Module
  • Component

Schema classifications SHALL themselves originate from a governed Constitutional Value Provider.

20.9. Structural Semantics​

A Constitutional Schema defines structural semantics rather than implementation syntax.

It specifies:

  • what structural elements exist;
  • how they relate;
  • which elements are required;
  • how they compose;
  • structural constraints;
  • extension rules.

It SHALL NOT prescribe:

  • database tables;
  • REST endpoints;
  • programming language classes;
  • serialization syntax.

20.10. Schema Elements​

Every Constitutional Schema SHALL consist of one or more Schema Elements.

Schema Elements MAY include:

  • structural properties;
  • structural references;
  • compositions;
  • collections;
  • embedded structures;
  • constraints;
  • inheritance declarations;
  • extension points.

Schema Elements define the constitutional organisation of an object rather than implementation fields.

20.11. Mandatory Structural Elements​

Every Constitutional Object Schema SHOULD normally define:

  • Constitutional Identifier;
  • object type;
  • metadata;
  • lifecycle;
  • governance;
  • provenance;
  • relationships;
  • structural constraints.

Additional mandatory elements SHALL be defined by specialised schemas.

20.12. Structural Composition​

A Constitutional Schema SHALL define how a Constitutional Object is composed.

Composition MAY include:

  • embedded objects;
  • references;
  • collections;
  • reusable structures;
  • nested compositions;
  • shared components.

Composition SHALL distinguish ownership from reference.

20.13. Structural Inheritance​

Schemas MAY inherit from other Constitutional Schemas.

Inheritance SHALL preserve:

  • semantic compatibility;
  • structural consistency;
  • constitutional identity.

Inheritance SHALL NOT alter inherited semantics unless explicitly governed.

20.14. Structural Specialisation​

A Constitutional Schema MAY specialise another schema.

Example:

Constitutional Object
        │
        ▼
Constitutional Registry
        │
        ▼
Value Provider Registry

Specialisation SHALL preserve compatibility with the parent schema unless explicitly declared otherwise.

20.15. Structural Extension​

Schemas MAY define extension points.

Extensions MAY be:

  • customer-specific;
  • white-label;
  • jurisdictional;
  • experimental;
  • domain-specific.

Extensions SHALL preserve:

  • constitutional identity;
  • compatibility;
  • provenance;
  • governance.

20.16. Schema Relationships​

Schemas MAY relate to one another through governed structural relationships.

Examples include:

  • extends;
  • composes;
  • references;
  • requires;
  • specialises;
  • replaces;
  • depends-on.

Relationship semantics SHALL be explicitly defined.

20.17. Structural Constraints​

Schemas SHALL define structural constraints independently of business validation.

Examples include:

  • required elements;
  • cardinality;
  • uniqueness;
  • structural dependencies;
  • containment;
  • ordering where applicable.

Business rules remain the responsibility of HECATE and Constitutional Resolution Policies.

20.18. Schema Compatibility​

Compatibility SHALL distinguish between:

  • fully compatible;
  • backward compatible;
  • forward compatible;
  • incompatible.

Compatibility SHALL be governed rather than inferred.

20.19. Schema Evolution​

Schema evolution SHALL preserve constitutional traceability.

Changes MAY include:

  • editorial improvements;
  • metadata enrichment;
  • structural additions;
  • structural removals;
  • compatibility changes;
  • semantic restructuring.

Breaking structural changes SHOULD normally require a new major schema version.

20.20. Schema Versioning​

Every Constitutional Schema SHALL participate in governed versioning.

Versioning SHALL distinguish:

  • schema identity;
  • schema version;
  • compatibility;
  • effective period;
  • supersession.

20.21. Schema Lifecycle​

Schemas SHALL participate in constitutional lifecycle management.

Typical states include:

  • Draft;
  • Proposed;
  • Approved;
  • Active;
  • Deprecated;
  • Superseded;
  • Retired;
  • Archived.

Lifecycle values SHALL originate from Constitutional Value Providers.

20.22. Schema Resolution​

Schemas SHALL be resolved through the Constitutional Resolution Architecture.

Schema Identifier
        │
        ▼
CRG
        │
        ▼
CRP
        │
        ▼
Schema Registry
        │
        ▼
Constitutional Schema

Consumers SHALL resolve schemas through Constitutional Identifiers rather than implementation names.

20.23. Schema Validation​

HECATE SHALL validate:

  • schema identity;
  • structural completeness;
  • inheritance;
  • composition;
  • compatibility;
  • lifecycle;
  • provenance;
  • relationships;
  • constraints.

A structurally invalid schema SHALL NOT become constitutionally active.

20.24. Technology Independence​

A Constitutional Schema SHALL remain independent of:

  • programming languages;
  • databases;
  • APIs;
  • serialization formats;
  • messaging protocols;
  • cloud providers.

Technology implements structure.

Technology SHALL NOT define constitutional structure.

20.25. Compiler​

The Constitutional Compiler MAY generate:

  • JSON Schema;
  • XML Schema;
  • SQL DDL;
  • GraphQL Types;
  • OpenAPI Components;
  • RDF Shapes;
  • TypeScript interfaces;
  • C# classes;
  • Java classes;
  • SDK models;
  • documentation.

Generated artefacts SHALL preserve Constitutional Schema identity.

20.26. Structural Reuse​

Schemas SHOULD maximise reuse.

Reusable structures MAY include:

  • identifiers;
  • governance blocks;
  • provenance blocks;
  • lifecycle blocks;
  • publication metadata;
  • relationship collections.

Reuse SHALL minimise duplication while preserving clarity.

20.27. Publication​

Schemas MAY be published for:

  • developers;
  • architects;
  • auditors;
  • regulators;
  • customers;
  • white-label deployments;
  • AI systems.

Publication SHALL preserve constitutional semantics independently of representation format.

20.28. Conformance​

A Constitutional Schema conforms where it:

  1. is represented as a Constitutional Object;
  2. possesses stable constitutional identity;
  3. defines a complete structural contract;
  4. remains independent of implementation technologies;
  5. supports governed versioning;
  6. defines structural composition;
  7. supports inheritance and extension where applicable;
  8. preserves provenance;
  9. supports HECATE validation;
  10. supports compiler generation.

20.29. Relationship to Other Constitutional Components​

Constitutional Schemas provide the structural blueprint for every governed artefact within the constitutional ecosystem.

Their relationship to other constitutional components is as follows:

  • the Constitutional Knowledge Model defines the concepts represented by a schema;
  • the Constitutional Object System provides the common behavioural model for schema instances;
  • the Constitutional Metadata Dictionary defines the metadata elements that schemas organise;
  • Constitutional Value Providers supply controlled values used within schema definitions;
  • Constitutional Authorities govern schema ownership, approval and publication;
  • the Constitutional Role Registry defines the governance roles participating in schema stewardship and review;
  • Authoritative Validation Sources provide evidence supporting externally governed structural requirements where applicable;
  • the Constitutional Registry Registry governs discovery of schema registries;
  • Constitutional Resolution Policies determine schema resolution, version selection and compatibility rules;
  • HECATE validates structural correctness and conformance;
  • the Constitutional Compiler transforms Constitutional Schemas into technology-specific implementation artefacts while preserving constitutional semantics.

20.30. Foundational Principle​

A Constitutional Schema is the governed Constitutional Object that defines the authoritative structural composition of a Constitutional Object independently of implementation technology.

Constitutional Schemas specify how Constitutional Objects are organised, composed and constrained. They do not prescribe databases, APIs, programming languages or serialization formats. Those implementation artefacts are derived through governed compilation.

Every Constitutional Object SHALL conform to a recognised Constitutional Schema. Every Constitutional Schema SHALL itself be governed as a Constitutional Object, possessing stable identity, semantic meaning, lifecycle, provenance, versioning and traceability.

By separating constitutional structure from implementation, ZAYAZ establishes a technology-independent structural foundation from which consistent databases, APIs, documentation, SDKs, validation models, knowledge graphs and AI representations can be generated without redefining the constitutional meaning of the governed objects.

21. Constitutional Properties (CP)​

21.1. Introduction​

Constitutional Properties define the structural members that constitute Constitutional Schemas and, by extension, Constitutional Objects within the ZAYAZ constitutional ecosystem.

A Constitutional Property represents a governed structural characteristic of a Constitutional Object.

It defines what structural information may exist, independently of how that information is represented, stored, transmitted or implemented.

A Constitutional Property is not:

  • a database column;
  • a JSON field;
  • an XML element;
  • an RDF predicate;
  • a GraphQL field;
  • a programming-language member;
  • a spreadsheet column;
  • an API parameter.

Those are implementation representations of Constitutional Properties.

A Constitutional Property defines the constitutional structural element from which those representations may be generated.

21.2. Purpose​

The purpose of Constitutional Properties is to establish a technology-independent vocabulary for the structural composition of Constitutional Schemas.

The Constitutional Property architecture provides:

  • structural definition;
  • property identity;
  • structural semantics;
  • composition;
  • inheritance;
  • reuse;
  • extensibility;
  • validation;
  • compatibility;
  • traceability;
  • compilation.

Properties provide the building blocks from which Constitutional Schemas are constructed.

21.3. Constitutional Principle​

Every structural member of a Constitutional Schema SHALL be represented by a Constitutional Property.

Constitutional Properties SHALL define structural meaning independently of implementation technologies.

Implementation fields SHALL be derived from Constitutional Properties through governed compilation.

21.4. Constitutional Position​

The relationship between schemas and properties is:

Constitutional Schema
        │
        │ composed of
        ▼
Constitutional Properties
        │
        │ represented as
        ▼
Implementation Fields

A schema defines the structure.

Properties define the structural members.

Implementations define their technical representation.

21.5. Constitutional Property as a Constitutional Object​

Every Constitutional Property SHALL be represented as a specialised Constitutional Object.

Each property SHALL possess:

  • Constitutional Identifier;
  • canonical name;
  • semantic definition;
  • property classification;
  • governing authority;
  • applicability;
  • lifecycle;
  • version;
  • provenance;
  • relationships;
  • constraints.

Properties therefore participate fully in constitutional governance.

21.6. Property Registry​

Constitutional Properties SHALL be governed through a dedicated Constitutional Registry.

The Property Registry SHALL govern:

  • property identities;
  • structural definitions;
  • property classifications;
  • inheritance;
  • compatibility;
  • lifecycle;
  • provenance;
  • relationships;
  • publication.

Every Constitutional Property SHALL be resolvable through the Constitutional Registry Registry.

21.7. Property Identity​

Every Constitutional Property SHALL possess a globally unique Constitutional Identifier.

Identity SHALL remain stable across:

  • implementation changes;
  • naming changes;
  • storage changes;
  • language bindings;
  • API evolution.

Changing an implementation field SHALL NOT change the Constitutional Property.

21.8. Property Classification​

Every Constitutional Property SHALL declare one or more Property Classifications.

Typical classifications include:

Identity Properties

  • Identifier
  • Namespace
  • Canonical Name

Governance Properties

  • Owner
  • Steward
  • Authority
  • Approval

Lifecycle Properties

  • Status
  • Version
  • Effective Period

Semantic Properties

  • Metadata Reference
  • Value Binding
  • Classification

Structural Properties

  • Composition
  • Reference
  • Collection

Validation Properties

  • Constraint
  • Validation Rule
  • Requirement

Provenance Properties

  • Source
  • Evidence
  • History

Publication Properties

  • Publication Profile
  • Visibility
  • Audience

Property classifications SHALL originate from Constitutional Value Providers.

21.9. Property Semantics​

Every Constitutional Property SHALL define one structural meaning.

The semantic definition SHALL specify:

  • purpose;
  • structural meaning;
  • applicability;
  • relationships;
  • constraints.

Implementation names SHALL NOT define semantics.

21.10. Property Types​

Every Constitutional Property SHALL declare its Property Type.

Typical Property Types include:

Scalar Property

Represents one atomic value.

Examples:

  • Identifier
  • Version
  • Name

Reference Property

Represents a governed relationship to another Constitutional Object.

Examples:

  • Authority
  • Role
  • Schema
  • Registry

Collection Property

Represents an ordered or unordered collection.

Examples:

  • Metadata Definitions
  • Roles
  • Validation Rules

Composition Property

Represents structural ownership.

The contained object forms part of the owning Constitutional Object.

Computed Property

Represents a value determined through governed computation.

Examples:

  • Risk Level
  • Materiality Score
  • Carbon Intensity

Derived Property

Represents information derived from one or more underlying properties.

Unlike a computed property, a derived property expresses structural derivation rather than algorithmic computation.

Inherited Property

Obtains its value through governed inheritance.

Constant Property

Represents an immutable structural characteristic.

Contextual Property

Resolved according to Resolution Context.

Virtual Property

Exists constitutionally but need not possess physical storage.

Property Types SHALL themselves originate from Constitutional Value Providers.

21.11. Property Value​

A Constitutional Property defines a structural member.

It does not define its permitted values.

Values originate from Constitutional Value Providers.

For example:

Property

Lifecycle Status

↓

CVP

Draft
Approved
Active
Archived

This preserves the constitutional separation between structure and values.

21.12. Property Metadata​

Properties MAY themselves possess metadata.

Examples include:

  • display name;
  • description;
  • publication profile;
  • multilingual labels;
  • ordering;
  • grouping.

Property metadata SHALL remain distinct from the property itself.

21.13. Property Cardinality​

Every Constitutional Property SHALL define cardinality.

Typical cardinalities include:

  • exactly one;
  • zero or one;
  • one or more;
  • zero or more.

Cardinality defines structural multiplicity rather than implementation constraints.

21.14. Required and Optional Properties​

Properties SHALL declare whether they are:

  • mandatory;
  • optional;
  • conditionally required;
  • prohibited.

Conditional requirements SHALL be governed through Constitutional Constraints and Resolution Policies.

21.15. Property Ownership​

Every Constitutional Property SHALL declare its owning Constitutional Schema.

A property MAY be reused by multiple schemas.

Ownership SHALL remain distinct from reuse.

21.16. Property Reuse​

Reusable properties SHALL preserve:

  • identity;
  • semantics;
  • provenance;
  • governance.

Multiple schemas SHOULD reference the same Constitutional Property rather than duplicate equivalent definitions.

21.17. Property Inheritance​

Properties MAY participate in governed inheritance.

Inheritance SHALL preserve:

  • semantics;
  • compatibility;
  • identity.

Inherited properties SHALL remain identifiable.

21.18. Property Specialisation​

A property MAY specialise another property.

Example:

Identifier

↓

Registry Identifier

↓

Authority Identifier

Specialisation SHALL preserve compatibility unless explicitly declared otherwise.

21.19. Property Groups​

Properties MAY be organised into Property Groups.

Examples include:

  • Governance
  • Lifecycle
  • Provenance
  • Validation
  • Relationships
  • Publication

Groups improve readability.

They SHALL NOT alter semantics.

21.20. Property Ordering​

Schemas MAY define property ordering.

Ordering MAY support:

  • documentation;
  • publication;
  • APIs;
  • user interfaces.

Ordering SHALL NOT alter constitutional meaning.

21.21. Property Relationships​

Properties MAY participate in governed relationships.

Examples:

  • depends-on;
  • derived-from;
  • excludes;
  • requires;
  • complements;
  • supersedes.

Relationship semantics SHALL be explicitly defined.

21.22. Property Compatibility​

Compatibility SHALL distinguish:

  • compatible;
  • backward compatible;
  • forward compatible;
  • incompatible.

Compatibility SHALL be governed rather than inferred.

21.23. Property Constraints​

Properties MAY declare structural constraints.

Examples include:

  • uniqueness;
  • cardinality;
  • reference integrity;
  • containment;
  • ordering;
  • dependency.

Business rules remain the responsibility of HECATE and Constitutional Constraints.

21.24. Property Evolution​

Property evolution MAY include:

  • editorial improvements;
  • semantic clarification;
  • structural enrichment;
  • compatibility changes.

Breaking semantic changes SHOULD normally require a new Constitutional Property identity.

21.25. Property Versioning​

Properties SHALL participate in governed versioning.

Versioning SHALL preserve:

  • property identity;
  • compatibility;
  • lifecycle;
  • provenance.

21.26. Property Lifecycle​

Properties SHALL participate in lifecycle management.

Typical states include:

  • Draft;
  • Proposed;
  • Approved;
  • Active;
  • Deprecated;
  • Superseded;
  • Retired;
  • Archived.

21.27. Property Resolution​

Properties SHALL be resolved through the Constitutional Resolution Architecture.

Property Identifier
        │
        ▼
CRG
        │
        ▼
CRP
        │
        ▼
Property Registry
        │
        ▼
Constitutional Property

21.28. Property Validation​

HECATE SHALL validate:

  • identity;
  • semantic completeness;
  • property type;
  • ownership;
  • reuse;
  • compatibility;
  • constraints;
  • lifecycle;
  • provenance.

Invalid properties SHALL NOT become constitutionally active.

21.29. Property Compilation​

The Constitutional Compiler MAY transform Constitutional Properties into:

  • JSON fields;
  • XML elements;
  • SQL columns;
  • GraphQL fields;
  • RDF predicates;
  • OpenAPI properties;
  • programming-language members;
  • documentation;
  • SDK definitions.

Compilation SHALL preserve Constitutional Property identity.

21.30. Technology Independence​

Constitutional Properties SHALL remain independent of:

  • programming languages;
  • databases;
  • APIs;
  • serialization formats;
  • cloud providers;
  • user-interface frameworks.

Technology SHALL implement properties.

Technology SHALL NOT define them.

21.31. Conformance​

A Constitutional Property conforms where it:

  1. is represented as a Constitutional Object;
  2. possesses stable constitutional identity;
  3. defines one structural meaning;
  4. declares a Property Type;
  5. belongs to one or more Constitutional Schemas;
  6. supports governed lifecycle and versioning;
  7. preserves provenance;
  8. supports HECATE validation;
  9. remains implementation independent.

21.32. Relationship to Other Constitutional Components​

Constitutional Properties provide the structural vocabulary from which Constitutional Schemas are composed.

Their relationship to other constitutional components is as follows:

  • the Constitutional Knowledge Model defines the concepts that properties represent;
  • the Constitutional Object System defines the common behaviour of properties as Constitutional Objects;
  • the Constitutional Metadata Dictionary defines the metadata used to describe properties;
  • Constitutional Value Providers supply controlled values for property classifications, property types, cardinalities and lifecycle states;
  • Constitutional Schemas organise Constitutional Properties into governed structural definitions;
  • Constitutional Authorities govern property ownership, approval and stewardship;
  • the Constitutional Role Registry defines governance participation for property lifecycle management;
  • Authoritative Validation Sources provide evidence for externally governed structural requirements where applicable;
  • Constitutional Resolution Policies govern property resolution, inheritance and compatibility;
  • HECATE validates structural integrity, consistency and conformance;
  • the Constitutional Compiler transforms Constitutional Properties into implementation-specific fields while preserving constitutional identity and semantics.

21.33. Foundational Principle​

A Constitutional Property is the governed Constitutional Object that defines a structural member of a Constitutional Schema independently of implementation technology.

Constitutional Properties express structural meaning, composition and behaviour. They do not define database columns, JSON fields, API parameters or programming-language members. Those representations are compiler-generated implementations of Constitutional Properties.

Every Constitutional Property SHALL possess stable identity, explicit semantics, governed lifecycle, provenance and traceability. Property values SHALL be supplied through Constitutional Value Providers, while business rules and contextual evaluation SHALL be governed by Constitutional Constraints, Constitutional Resolution Policies and HECATE.

By separating structural properties from implementation fields, ZAYAZ establishes a durable, reusable and technology-independent structural model capable of generating consistent implementations across databases, APIs, schemas, knowledge graphs, programming languages and future technologies without redefining constitutional meaning.

Architectural note​

This chapter introduces another key separation that strengthens the constitutional architecture:

Constitutional Schema
        │
        │ defines structure
        ▼
Constitutional Property
        │
        │ defines structural member
        ▼
Metadata Definition
        │
        │ describes the property
        ▼
Constitutional Value Provider
        │
        │ supplies permitted values
        ▼
Implementation Field

This layered model is deliberately orthogonal:

  • Constitutional Schemas answer: How is an object organised?
  • Constitutional Properties answer: What structural members can it contain?
  • Constitutional Metadata Dictionary answers: How are those members described?
  • Constitutional Value Providers answer: Which values are permitted?
  • Implementation artefacts answer: How are those members represented in a specific technology?

This separation avoids the common enterprise mistake of conflating structure, metadata, values and implementation, and provides the compiler with a clean, deterministic model for generating consistent representations across every supported platform.



GitHub RepoRequest for Change (RFC)
Last updated on by ZAYAZ