Skip to main content

Chapter 25 — Constitutional Extension Framework

Part II — Structural, Schema, Registry and Graph Extensions​

Part II defines the governed structural extension layer through which ZAYAZ may add or specialise:

  • Constitutional Object Types;
  • object schemas;
  • properties;
  • datatypes;
  • units;
  • enumerations;
  • Value Providers;
  • Registries;
  • Relationship Types;
  • graph constraints;
  • inference rules;
  • identity mappings;
  • validation constraints;
  • migration rules.

Part I established the constitutional boundaries, Extension Classes, Extension Points, Namespaces, authority, lifecycle, layered architecture, compatibility and provenance requirements.

Part II applies those foundations to the structural artefacts from which constitutional data, graph, validation, runtime and publication behaviour are built.

The governing principles are:

A structural Extension SHALL add or specialise governed structure without silently changing the identity, meaning or historical interpretation of Core structure.

Every extended property, datatype, unit, value, Registry entry, Relationship Type and graph rule SHALL possess stable identity, explicit scope, declared compatibility, validation and complete provenance.

Technical schema acceptance SHALL not establish semantic compatibility.

A tenant-specific structural Extension SHALL remain tenant-bound across data, graph, search, vector, event, workflow, publication, evidence and backup representations.

Every structural Extension SHALL remain reconstructable at any historical time for which data, decisions or Publications depend upon it.

The structural extension path is:

Approved Extension Definition
        │
        ▼
Structural Extension Point
        │
        ├── Object Type Point
        ├── Property Point
        ├── Datatype Point
        ├── Unit Point
        ├── Value Provider Point
        ├── Registry Point
        ├── Relationship Point
        ├── Graph Constraint Point
        └── Validation Rule Point
        │
        ▼
Structural Artefact Definition
        │
        ├── Identity
        ├── Namespace
        ├── Parent or Target
        ├── Semantics
        ├── Cardinality
        ├── Temporal Treatment
        ├── Tenant Scope
        ├── Security
        ├── Compatibility
        └── Provenance
        │
        ▼
Compiler Validation and Projection
        │
        ├── Schemas
        ├── Graph Shapes
        ├── Validation Rules
        ├── API Contracts
        ├── Event Schemas
        ├── Publication Schemas
        └── Migration Artefacts
        │
        ▼
HECATE Validation
        │
        ▼
Extension Package and Manifest
        │
        ▼
Scoped Activation

Structural Extensions SHALL remain independent of any one schema language, database engine, graph database, ontology language, API specification, data warehouse, event platform, search index, vector store or serialization format.

25.13. Structural Extension Model​

A Structural Extension is an Extension that adds, specialises, constrains, maps, deprecates or migrates constitutionally governed structure.

Structural Extensions SHALL use explicit structural Extension Points.

25.13.1. Structural Extension Identity​

Every Structural Extension SHALL possess:

  • Structural Extension Identifier;
  • Extension Definition;
  • Namespace;
  • structural Extension Type;
  • owner;
  • authority;
  • Extension Point;
  • target Core artefact where applicable;
  • scope;
  • semantic definition;
  • compatibility;
  • validation;
  • migration;
  • lifecycle;
  • version;
  • effective time;
  • provenance.

25.13.2. Structural Extension Types​

Structural Extension Types MAY include:

  • Object Type Extension;
  • Object Specialisation;
  • Schema Extension;
  • Property Extension;
  • Datatype Extension;
  • Unit Extension;
  • Enumeration Extension;
  • Value Provider Extension;
  • Registry Extension;
  • Relationship Type Extension;
  • Graph Constraint Extension;
  • Inference Extension;
  • Identity Mapping Extension;
  • Validation Rule Extension;
  • Migration Extension.

25.13.3. Structural Artefact​

A Structural Artefact MAY be:

  • object-type definition;
  • schema fragment;
  • property definition;
  • datatype;
  • unit;
  • enumeration value;
  • Value Provider;
  • Registry;
  • Registry entry;
  • Relationship Type;
  • graph shape;
  • cardinality constraint;
  • uniqueness constraint;
  • temporal constraint;
  • validation rule;
  • mapping;
  • migration rule.

Every material Structural Artefact SHALL possess stable identity.

25.13.4. Core Structural Artefact​

A Core Structural Artefact is governed by Core constitutional authority.

An Extension SHALL reference but SHALL NOT impersonate a Core Structural Artefact.

25.13.5. Structural Parent​

A Structural Extension MAY declare a parent artefact.

The parent relationship SHALL identify:

  • parent identity;
  • inheritance type;
  • inherited semantics;
  • added constraints;
  • overridden presentation;
  • prohibited mutations;
  • compatibility;
  • provenance.

25.13.6. Structural Target​

A Structural Target is the Core or Extension artefact to which an Extension attaches.

The target SHALL exist, be valid, expose an applicable Extension Point and remain compatible with the Extension.

25.13.7. Structural Scope​

Scope MAY be:

  • global approved;
  • framework;
  • jurisdiction;
  • sector;
  • white-label;
  • tenant;
  • organisation;
  • legal entity;
  • Module;
  • Component;
  • workflow;
  • publication;
  • integration;
  • experimental environment.

25.13.8. Structural Context​

Structural applicability MAY depend on:

  • Runtime Context;
  • reporting framework;
  • jurisdiction;
  • sector;
  • tenant;
  • organisation;
  • effective time;
  • data classification;
  • publication audience;
  • assurance scope;
  • Runtime Bundle.

25.13.9. Structural Precedence​

Precedence SHALL be governed by:

  • Core non-overrideable controls;
  • Extension Point contract;
  • legal authority;
  • framework authority;
  • Extension Class;
  • scope specificity;
  • effective time;
  • approved override;
  • compatibility.

Database column order, schema import order and package load order SHALL not determine precedence.

25.13.10. Structural Conflict​

A Structural Conflict MAY arise from:

  • duplicate identity;
  • incompatible datatype;
  • incompatible unit;
  • contradictory cardinality;
  • incompatible lifecycle;
  • incompatible null semantics;
  • conflicting Registry value;
  • conflicting Relationship endpoint;
  • incompatible validation;
  • tenant-scope mismatch;
  • incompatible temporal semantics.

Unresolved conflict SHALL block activation.

25.13.11. Structural Resolution Outcome​

A Structural Resolution Outcome SHALL preserve:

  • target context;
  • candidate artefacts;
  • selected artefacts;
  • rejected artefacts;
  • effective schema;
  • effective graph constraints;
  • effective validation;
  • conflicts;
  • precedence;
  • explanation;
  • provenance.

25.13.12. Structural Snapshot​

A Structural Snapshot SHALL identify the exact structural state applicable to a subject, tenant, Runtime Bundle or historical time.

It SHOULD include:

  • object types;
  • properties;
  • datatypes;
  • units;
  • Registry values;
  • Relationship Types;
  • constraints;
  • validation rules;
  • Extension versions;
  • content digests;
  • provenance.

25.13.13. Structural Immutability​

An activated Structural Artefact version SHALL be immutable.

A semantic change SHALL create a new version or a new identity where compatibility rules require it.

25.13.14. Structural Projection​

A Structural Artefact MAY be projected into:

  • JSON Schema;
  • XML Schema;
  • GraphQL schema;
  • OpenAPI schema;
  • Protobuf;
  • database schema;
  • graph shape;
  • SHACL;
  • event schema;
  • UI form schema;
  • publication schema;
  • search mapping;
  • vector metadata schema.

The projection SHALL preserve source identity and information-loss metadata.

25.13.15. Structural Drift​

Structural Drift exists where observed deployed structure differs from the approved Structural Snapshot.

Drift MAY include:

  • unknown property;
  • missing required property;
  • incompatible datatype;
  • unregistered value;
  • unknown Relationship Type;
  • changed cardinality;
  • validation bypass;
  • tenant leakage;
  • stale schema;
  • undocumented default.

Material drift SHALL trigger quarantine, migration, rollback, incident or conformance failure.

25.13.16. Structural Validation​

HECATE SHALL validate:

  • identity;
  • Namespace;
  • Extension Point;
  • parent and target;
  • semantics;
  • scope;
  • compatibility;
  • conflict;
  • security;
  • migration;
  • provenance.

25.14. Object Type and Schema Extensions​

An Object Type Extension adds a new Constitutional Object Type or creates a governed specialisation of an existing Object Type.

A Schema Extension adds or specialises the structural contract applicable to one or more Object Types.

25.14.1. Object Type Extension Identity​

Every Object Type Extension SHALL possess:

  • Object Type Identifier;
  • Namespace;
  • canonical name;
  • semantic definition;
  • parent Object Type where applicable;
  • owner;
  • authority;
  • Extension Point;
  • permitted properties;
  • required properties;
  • lifecycle;
  • tenant scope;
  • temporal semantics;
  • security classification;
  • publication treatment;
  • compatibility;
  • version;
  • provenance.

25.14.2. New Object Type​

A new Object Type SHALL be justified where:

  • it possesses independent identity;
  • it has a distinct lifecycle;
  • it has distinct properties or relationships;
  • it cannot safely be represented as an existing type;
  • its semantics are stable enough to govern;
  • an approved Object Type Extension Point exists.

25.14.3. Object Specialisation​

A specialised Object Type SHALL preserve:

  • parent identity;
  • parent semantics;
  • inherited properties;
  • inherited constraints;
  • added properties;
  • stricter constraints;
  • scope;
  • compatibility;
  • provenance.

It SHALL NOT remove a mandatory parent property unless the Extension Point explicitly permits profile-based non-applicability.

25.14.4. Object Generalisation​

An Extension SHALL NOT create a broader generalisation that changes the interpretation of existing Core instances without Constitutional Evolution.

25.14.5. Object Type Discriminator​

Where serialization requires a discriminator, it SHALL:

  • reference the canonical Object Type Identifier;
  • remain Namespace-aware;
  • be version-compatible;
  • prevent cross-tenant spoofing;
  • preserve unknown-type handling;
  • preserve provenance.

25.14.6. Schema Extension Identity​

Every Schema Extension SHALL identify:

  • Schema Extension Identifier;
  • target Object Types;
  • Namespace;
  • schema language or abstract schema;
  • properties;
  • constraints;
  • conditional rules;
  • version;
  • compatibility;
  • migration;
  • provenance.

25.14.7. Abstract and Physical Schema​

The Runtime SHALL distinguish:

  • abstract constitutional schema; and
  • physical implementation schema.

A physical schema SHALL not become authoritative merely because it is deployed.

25.14.8. Schema Composition​

Schema composition MAY use:

  • inheritance;
  • intersection;
  • conditional inclusion;
  • profile composition;
  • mixin;
  • reference;
  • graph shape;
  • schema fragment.

Composition semantics SHALL be explicit.

25.14.9. Required Properties​

An Extension MAY add required properties only where:

  • the Extension Point permits it;
  • scope is explicit;
  • existing instances can be migrated or grandfathered;
  • compatibility is declared;
  • defaulting is governed;
  • publication and API effects are assessed;
  • provenance is preserved.

25.14.10. Conditional Properties​

A conditional property SHALL identify:

  • condition;
  • condition authority;
  • evaluated context;
  • required or prohibited state;
  • temporal applicability;
  • validation;
  • explanation;
  • provenance.

25.14.11. Additional Properties​

A schema SHALL explicitly define whether unknown properties are:

  • prohibited;
  • permitted within an approved Namespace;
  • preserved but not interpreted;
  • quarantined;
  • mapped;
  • ignored for specified projections only.

Silent acceptance SHALL NOT establish constitutional validity.

25.14.12. Open and Closed Schema​

A Closed Schema permits only explicitly defined properties.

An Open Schema MAY permit namespaced Extension properties under defined rules.

Open SHALL NOT mean unvalidated.

25.14.13. Schema Versioning​

A new schema version SHALL be created where changes affect:

  • properties;
  • required state;
  • datatype;
  • cardinality;
  • defaults;
  • null semantics;
  • constraints;
  • conditional logic;
  • serialization;
  • compatibility.

25.14.14. Backward Compatibility​

A backward-compatible schema allows newer readers to accept older valid instances or older readers to accept newer instances according to an explicit compatibility definition.

Compatibility direction SHALL be stated.

25.14.15. Unknown Object Type​

An unknown Object Type SHALL be:

  • rejected;
  • quarantined;
  • preserved as opaque content;
  • routed to an adapter;
  • accepted only in experimental scope.

The treatment SHALL be profile-governed.

25.14.16. Object Type Deprecation​

Deprecation SHALL identify:

  • deprecated Object Type;
  • replacement;
  • migration;
  • final creation date;
  • final update date;
  • historical-read support;
  • publication treatment;
  • provenance.

25.14.17. Schema Compilation​

The Constitutional Compiler SHOULD produce:

  • abstract schema;
  • physical schema projections;
  • validators;
  • migration stubs;
  • API contracts;
  • event schemas;
  • form schemas;
  • conformance fixtures;
  • manifest entries.

25.14.18. Object and Schema Validation​

HECATE SHALL validate:

  • Object Type identity;
  • parent;
  • discriminator;
  • schema composition;
  • required and conditional properties;
  • additional-property treatment;
  • compatibility;
  • deprecation;
  • migration;
  • provenance.

25.15. Property Extensions​

A Property Extension adds or specialises a governed property on one or more Object Types through an approved Property Extension Point.

A property SHALL possess constitutional identity independent of its display label or physical field name.

25.15.1. Property Identity​

Every extended property SHALL possess:

  • Property Identifier;
  • Namespace;
  • canonical name;
  • semantic definition;
  • target Object Types;
  • owner;
  • authority;
  • Extension Point;
  • datatype;
  • unit where applicable;
  • cardinality;
  • required state;
  • null semantics;
  • default semantics;
  • temporal semantics;
  • confidentiality;
  • validation;
  • publication treatment;
  • compatibility;
  • version;
  • provenance.

25.15.2. Property Names​

The Runtime SHALL distinguish:

  • canonical Property Identifier;
  • canonical name;
  • display label;
  • API field name;
  • database column name;
  • language-specific label;
  • legacy alias.

A change to a display label SHALL not create a new Property identity.

25.15.3. Target Object Types​

A Property Extension SHALL identify every permitted target Object Type.

A property SHALL not be attached to an unrelated Object Type merely because the physical database permits it.

25.15.4. Property Semantics​

Property semantics SHALL define:

  • what the value means;
  • what the value does not mean;
  • who or what the value describes;
  • applicable period;
  • applicable boundary;
  • unit;
  • measurement basis;
  • source expectations;
  • uncertainty treatment;
  • provenance.

25.15.5. Property Cardinality​

Cardinality MAY be:

  • exactly one;
  • zero or one;
  • one or more;
  • zero or more;
  • bounded range;
  • context-dependent.

Context-dependent cardinality SHALL be governed by an explicit rule.

25.15.6. Required Property​

A required property SHALL identify:

  • applicability;
  • enforcement point;
  • transition rule;
  • legacy-instance treatment;
  • default prohibition or permission;
  • validation severity;
  • provenance.

25.15.7. Optional Property​

Optional SHALL mean not constitutionally required in the applicable context.

It SHALL not mean semantically irrelevant or safe to omit from every Publication.

25.15.8. Computed Property​

A Computed Property SHALL identify:

  • computation;
  • source properties;
  • methodology;
  • Component;
  • determinism;
  • recalculation trigger;
  • override prohibition or policy;
  • provenance.

A computed value SHALL not be stored as independent truth without source lineage.

25.15.9. Derived Property​

A Derived Property SHALL preserve:

  • premises;
  • reasoning or inference rule;
  • confidence;
  • validation;
  • activation state;
  • publication treatment;
  • provenance.

25.15.10. Declared Property​

A Declared Property is provided by an authorised actor or source.

It SHALL preserve declarant identity, authority, time and evidence where required.

25.15.11. Observed Property​

An Observed Property SHALL preserve:

  • observation source;
  • method;
  • instrument;
  • time;
  • location;
  • quality;
  • uncertainty;
  • provenance.

25.15.12. Property Null Semantics​

A property SHALL distinguish as applicable:

  • absent;
  • unknown;
  • not applicable;
  • not available;
  • withheld;
  • confidential;
  • not measured;
  • not yet determined;
  • invalid;
  • estimated;
  • zero.

A physical null SHALL not be accepted without governed semantic interpretation.

25.15.13. Property Defaults​

A default SHALL identify:

  • default value;
  • authority;
  • applicability;
  • reason;
  • whether persisted or resolved;
  • whether historical;
  • whether publication-visible;
  • expiration;
  • provenance.

A default SHALL not fabricate evidence.

25.15.14. Property Constraints​

Constraints MAY include:

  • range;
  • pattern;
  • precision;
  • scale;
  • length;
  • enumeration;
  • uniqueness;
  • monotonicity;
  • temporal relation;
  • cross-property dependency;
  • evidence requirement;
  • assurance requirement.

25.15.15. Property Security​

Property security SHALL define:

  • classification;
  • audience;
  • tenant;
  • purpose;
  • masking;
  • redaction;
  • encryption;
  • indexing;
  • export;
  • publication;
  • retention.

25.15.16. Property Temporal Semantics​

A property SHALL identify whether its value is:

  • timeless;
  • valid-time bound;
  • effective-time bound;
  • transaction-time bound;
  • event-time bound;
  • reporting-period bound;
  • snapshot-only.

25.15.17. Property Publication Treatment​

The property SHALL identify:

  • publishable state;
  • audience restrictions;
  • aggregation;
  • rounding;
  • unit display;
  • assurance state;
  • omission treatment;
  • correction treatment.

25.15.18. Property Change​

A semantic change to a property SHALL create a new version or new identity according to compatibility rules.

25.15.19. Property Deprecation​

Deprecation SHALL preserve:

  • replacement;
  • migration;
  • aliases;
  • historical interpretation;
  • API treatment;
  • publication treatment;
  • provenance.

25.15.20. Property Validation​

HECATE SHALL validate:

  • identity;
  • target Object Types;
  • semantics;
  • datatype;
  • unit;
  • cardinality;
  • nulls;
  • defaults;
  • constraints;
  • security;
  • temporal semantics;
  • publication;
  • compatibility;
  • provenance.

25.16. Datatype, Measurement and Unit Extensions​

Datatype and unit Extensions SHALL preserve machine validity and domain meaning.

A syntactically valid number SHALL not be considered semantically valid without datatype, unit, scale, basis and temporal context.

25.16.1. Datatype Extension Identity​

Every Datatype Extension SHALL possess:

  • Datatype Identifier;
  • Namespace;
  • canonical name;
  • semantic definition;
  • base datatype;
  • lexical form;
  • value space;
  • normalization;
  • comparison semantics;
  • null treatment;
  • serialization;
  • compatibility;
  • version;
  • provenance.

25.16.2. Datatype Classes​

Datatype Classes MAY include:

  • text;
  • controlled text;
  • boolean;
  • integer;
  • decimal;
  • percentage;
  • ratio;
  • currency amount;
  • measurement;
  • date;
  • time;
  • instant;
  • duration;
  • interval;
  • identifier;
  • URI;
  • geographic coordinate;
  • uncertainty value;
  • probability;
  • scenario value;
  • evidence reference;
  • graph reference;
  • structured record.

25.16.3. Constrained Datatype​

A constrained datatype MAY define:

  • minimum;
  • maximum;
  • precision;
  • scale;
  • pattern;
  • permitted values;
  • normalization;
  • ordering;
  • comparison;
  • provenance.

25.16.4. Measurement Type​

A Measurement Type SHALL identify:

  • measured quantity;
  • permitted units;
  • measurement basis;
  • aggregation semantics;
  • uncertainty;
  • temporal treatment;
  • boundary;
  • provenance.

25.16.5. Unit Extension Identity​

Every Unit Extension SHALL possess:

  • Unit Identifier;
  • Namespace;
  • canonical symbol;
  • canonical name;
  • quantity kind;
  • dimension;
  • scale;
  • conversion rule;
  • reference unit;
  • precision;
  • rounding;
  • applicability;
  • version;
  • provenance.

25.16.6. Unit Classes​

Unit Classes MAY include:

  • mass;
  • energy;
  • volume;
  • area;
  • distance;
  • time;
  • temperature;
  • currency;
  • emissions;
  • water;
  • waste;
  • intensity;
  • headcount;
  • full-time equivalent;
  • monetary intensity;
  • lifecycle impact;
  • biodiversity measure.

25.16.7. Composite Unit​

A Composite Unit SHALL preserve:

  • numerator;
  • denominator;
  • exponents;
  • scale;
  • quantity kind;
  • canonical expression;
  • conversion;
  • provenance.

25.16.8. Currency Extension​

A currency measurement SHALL preserve:

  • currency;
  • amount;
  • price basis;
  • nominal or real state;
  • exchange-rate source;
  • exchange-rate date;
  • conversion method;
  • inflation basis where applicable;
  • provenance.

25.16.9. Emissions Unit​

An emissions unit SHALL preserve:

  • gas or basket;
  • mass unit;
  • CO2-equivalent basis where applicable;
  • GWP source;
  • GWP version;
  • time horizon;
  • biogenic treatment;
  • provenance.

25.16.10. Unit Conversion​

A conversion SHALL identify:

  • source unit;
  • target unit;
  • conversion rule;
  • factor;
  • source;
  • effective time;
  • precision;
  • uncertainty;
  • Component;
  • provenance.

25.16.11. Non-Linear Conversion​

A non-linear conversion SHALL be explicit and SHALL NOT be represented as a simple factor.

25.16.12. Context-Dependent Conversion​

A context-dependent conversion SHALL preserve all required context, including:

  • temperature;
  • pressure;
  • density;
  • geography;
  • period;
  • market;
  • exchange rate;
  • methodology.

25.16.13. Precision and Scale​

Precision and scale SHALL preserve:

  • source precision;
  • computation precision;
  • storage precision;
  • publication precision;
  • rounding method;
  • materiality threshold;
  • provenance.

25.16.14. Uncertainty Datatype​

An uncertainty representation MAY include:

  • point estimate;
  • range;
  • standard deviation;
  • confidence interval;
  • probability distribution;
  • qualitative confidence;
  • model uncertainty;
  • data-quality score.

The representation SHALL identify its method and interpretation.

25.16.15. Date and Time Datatypes​

Temporal datatypes SHALL distinguish:

  • local date;
  • local time;
  • offset time;
  • instant;
  • time zone;
  • interval;
  • reporting period;
  • open interval;
  • uncertain time.

25.16.16. Geospatial Datatype​

A geospatial datatype SHALL identify:

  • coordinate reference system;
  • geometry type;
  • precision;
  • altitude where applicable;
  • uncertainty;
  • confidentiality;
  • provenance.

25.16.17. Datatype Compatibility​

Changing from one datatype to another SHALL evaluate:

  • value-space preservation;
  • lexical preservation;
  • precision;
  • null semantics;
  • ordering;
  • serialization;
  • historical interpretation;
  • migration.

25.16.18. Unit Compatibility​

Units SHALL be classified as:

  • identical;
  • directly convertible;
  • contextually convertible;
  • comparable after normalisation;
  • incompatible;
  • unknown.

Unknown SHALL not be treated as convertible.

25.16.19. Datatype and Unit Validation​

HECATE SHALL validate:

  • identity;
  • base type;
  • lexical and value space;
  • quantity kind;
  • dimension;
  • unit;
  • conversion;
  • precision;
  • uncertainty;
  • temporal or geospatial context;
  • compatibility;
  • provenance.

25.17. Enumeration, Value Provider and Registry Extensions​

Controlled values SHALL be extended through governed Value Providers and Registries.

A text label SHALL not become a valid controlled value merely because it appears in input data or a user interface.

25.17.1. Enumeration Extension​

An Enumeration Extension adds, specialises, aliases, deprecates or maps controlled values within an approved Enumeration Extension Point.

25.17.2. Enumeration Value Identity​

Every controlled value SHALL possess:

  • Value Identifier;
  • Namespace;
  • canonical code;
  • canonical name;
  • semantic definition;
  • owning Value Provider or Registry;
  • parent value where applicable;
  • aliases;
  • mappings;
  • applicability;
  • lifecycle;
  • version;
  • effective time;
  • provenance.

25.17.3. Value Provider Extension​

A Value Provider Extension SHALL identify:

  • Value Provider Identifier;
  • owner;
  • authority;
  • Namespace;
  • supported values;
  • hierarchy;
  • validation;
  • localisation;
  • lifecycle;
  • version;
  • provenance.

25.17.4. Registry Extension​

A Registry Extension SHALL identify:

  • Registry Identifier;
  • Registry Type;
  • owner;
  • steward;
  • authority;
  • Namespace;
  • entry schema;
  • identity policy;
  • hierarchy;
  • relationship policy;
  • temporal policy;
  • security;
  • publication policy;
  • lifecycle;
  • version;
  • provenance.

25.17.5. Registry Types​

Registry Types MAY include:

  • organisation registry;
  • legal-entity registry;
  • framework registry;
  • jurisdiction registry;
  • methodology registry;
  • unit registry;
  • factor registry;
  • role registry;
  • authority registry;
  • publication-profile registry;
  • assurance registry;
  • agent registry;
  • tool registry;
  • Module registry;
  • Component registry;
  • Extension registry;
  • Namespace registry;
  • passport registry;
  • public-identifier registry.

25.17.6. Registry Entry​

Every Registry Entry SHALL possess:

  • Entry Identifier;
  • Registry;
  • Namespace;
  • semantic definition;
  • owner;
  • steward;
  • authority;
  • status;
  • effective time;
  • aliases;
  • mappings;
  • version;
  • provenance.

25.17.7. Hierarchical Value​

A hierarchical value SHALL preserve:

  • parent;
  • child;
  • hierarchy type;
  • ordering where applicable;
  • effective time;
  • multiple-parent policy;
  • cycle prohibition or policy;
  • provenance.

25.17.8. Polyhierarchy​

Polyhierarchy MAY be permitted where a value has multiple governed parents.

The semantic meaning of each parent relationship SHALL be explicit.

25.17.9. Value Alias​

An alias SHALL identify:

  • canonical value;
  • alias;
  • language;
  • context;
  • source;
  • ambiguity treatment;
  • deprecation;
  • provenance.

25.17.10. Value Mapping​

A mapping SHALL identify:

  • source value;
  • target value;
  • source and target authorities;
  • mapping type;
  • conditions;
  • information loss;
  • effective time;
  • confidence where applicable;
  • provenance.

Mapping Types MAY include:

  • exact;
  • narrower;
  • broader;
  • conditional;
  • aggregation;
  • decomposition;
  • approximate;
  • no safe mapping.

25.17.11. Unknown Value​

An unknown controlled value SHALL be:

  • rejected;
  • quarantined;
  • mapped through an approved alias;
  • proposed as a new Extension value;
  • preserved as unclassified external input.

It SHALL not silently create a Registry Entry.

25.17.12. Other Value​

An Other value MAY be permitted only where the applicable Value Provider defines:

  • meaning;
  • supporting free text;
  • validation;
  • review;
  • publication treatment;
  • migration path.

25.17.13. Not Applicable and Unknown​

Not Applicable, Unknown, Not Available, Withheld and Other SHALL remain distinct controlled values where used.

25.17.14. Registry Authority​

Registry entry creation, modification, deprecation, merging and withdrawal SHALL require explicit authority.

25.17.15. Duplicate Registry Entry​

A duplicate entry SHALL be resolved through:

  • merge;
  • alias;
  • mapping;
  • rejection;
  • coexistence with distinct meaning.

The original identities SHALL remain historically traceable.

25.17.16. Registry Entry Merge​

A merge SHALL preserve:

  • source entries;
  • surviving entry;
  • mapping;
  • effective time;
  • affected references;
  • migration;
  • provenance.

25.17.17. Registry Entry Split​

A split SHALL preserve:

  • source entry;
  • new entries;
  • distribution rule;
  • ambiguity;
  • migration;
  • historical interpretation;
  • provenance.

25.17.18. Registry Entry Deprecation​

Deprecation SHALL preserve:

  • replacement;
  • aliases;
  • mappings;
  • final-use date;
  • historical resolution;
  • publication treatment;
  • provenance.

25.17.19. Registry Publication​

A Registry MAY expose a public projection.

The public projection SHALL remain distinct from the authoritative Registry and SHALL comply with the Constitutional Publication Framework.

25.17.20. Value and Registry Compilation​

The Constitutional Compiler SHOULD produce:

  • enumerations;
  • code lists;
  • validation tables;
  • lookup APIs;
  • localisation bundles;
  • mapping tables;
  • migration artefacts;
  • conformance fixtures;
  • manifest entries.

25.17.21. Value and Registry Validation​

HECATE SHALL validate:

  • identity;
  • Namespace;
  • authority;
  • hierarchy;
  • aliases;
  • mappings;
  • duplicate treatment;
  • lifecycle;
  • temporal applicability;
  • publication;
  • provenance.

25.18. Relationship Type Extensions​

A Relationship Type Extension adds or specialises a governed relationship between Constitutional Object Types through an approved Relationship Extension Point.

A relationship SHALL possess constitutional meaning independent of the graph technology or physical edge label used to store it.

25.18.1. Relationship Type Identity​

Every extended Relationship Type SHALL possess:

  • Relationship Type Identifier;
  • Namespace;
  • canonical name;
  • semantic definition;
  • source Object Types;
  • target Object Types;
  • direction;
  • inverse Relationship Type where applicable;
  • owner;
  • authority;
  • Extension Point;
  • cardinality;
  • temporal semantics;
  • evidence requirements;
  • authority requirements;
  • security;
  • inference policy;
  • publication treatment;
  • compatibility;
  • lifecycle;
  • version;
  • provenance.

25.18.2. Relationship Semantics​

Relationship semantics SHALL define:

  • the meaning of the source role;
  • the meaning of the target role;
  • whether direction is semantic or representational;
  • whether the relationship is asserted, observed, computed or inferred;
  • whether the relationship is temporal;
  • whether it can carry properties;
  • whether it requires evidence;
  • whether it can be published;
  • provenance.

25.18.3. Endpoint Types​

A Relationship Type SHALL define permitted source and target Object Types.

An endpoint extension MAY add a new permitted subtype only where:

  • parent compatibility exists;
  • the Extension Point permits it;
  • security is preserved;
  • graph constraints remain valid;
  • inference effects are evaluated;
  • provenance is preserved.

25.18.4. Direction​

Direction SHALL be explicit.

The Runtime SHALL distinguish:

  • directed relationship;
  • symmetric relationship;
  • antisymmetric relationship;
  • bidirectional representation;
  • undirected conceptual relation.

25.18.5. Inverse Relationship​

An inverse Relationship Type SHALL preserve:

  • inverse identity;
  • semantic equivalence;
  • endpoint reversal;
  • property treatment;
  • temporal treatment;
  • validation;
  • provenance.

An automatically generated inverse SHALL remain traceable to its source relationship.

25.18.6. Relationship Cardinality​

Cardinality MAY apply to:

  • source-to-target count;
  • target-to-source count;
  • active-time count;
  • context-specific count;
  • tenant-specific count;
  • role-specific count.

Cardinality SHALL be evaluated within the applicable temporal and tenant scope.

25.18.7. Relationship Properties​

A relationship MAY possess properties including:

  • role;
  • percentage;
  • quantity;
  • validity interval;
  • confidence;
  • evidence;
  • authority;
  • source;
  • methodology;
  • sequence;
  • priority;
  • provenance.

Each relationship property SHALL possess a governed Property identity.

25.18.8. Relationship Assertion Types​

A relationship instance SHALL identify whether it is:

  • declared;
  • observed;
  • computed;
  • inferred;
  • imported;
  • reconciled;
  • disputed;
  • superseded;
  • withdrawn.

25.18.9. Relationship Evidence​

Evidence requirements MAY depend on:

  • Relationship Type;
  • endpoint types;
  • risk;
  • publication use;
  • assurance use;
  • authority;
  • jurisdiction.

25.18.10. Relationship Authority​

A Relationship Type SHALL identify who may:

  • assert;
  • validate;
  • approve;
  • correct;
  • withdraw;
  • publish

relationship instances.

25.18.11. Temporal Relationship​

A temporal relationship SHALL preserve:

  • valid from;
  • valid to;
  • effective time;
  • transaction time;
  • event source;
  • open-ended state;
  • overlap policy;
  • provenance.

25.18.12. Relationship Uniqueness​

A uniqueness rule SHALL identify:

  • endpoint combination;
  • applicable scope;
  • active interval;
  • property qualifiers;
  • tenant;
  • violation treatment;
  • provenance.

25.18.13. Relationship Lifecycle​

Lifecycle MAY include:

  • Proposed;
  • Active;
  • Suspended;
  • Disputed;
  • Superseded;
  • Withdrawn;
  • Archived.

25.18.14. Relationship Specialisation​

A specialised Relationship Type SHALL preserve parent semantics and MAY add:

  • narrower endpoint types;
  • stricter cardinality;
  • additional properties;
  • stronger evidence;
  • stronger authority;
  • narrower applicability.

It SHALL NOT broaden meaning incompatibly.

25.18.15. Relationship Composition​

Relationship composition SHALL identify whether a path of two or more relationships may support a derived relationship.

Composition SHALL require an explicit inference rule.

25.18.16. Relationship Type Mapping​

A mapping between Relationship Types SHALL preserve:

  • source and target identities;
  • mapping type;
  • endpoint mappings;
  • direction;
  • property mappings;
  • temporal semantics;
  • information loss;
  • provenance.

25.18.17. Relationship Type Deprecation​

Deprecation SHALL identify:

  • replacement;
  • migration;
  • endpoint treatment;
  • inference treatment;
  • historical interpretation;
  • publication treatment;
  • provenance.

25.18.18. Cross-Tenant Relationship​

A cross-tenant relationship SHALL be prohibited unless an explicit federation or shared-public-data policy permits it.

It SHALL preserve:

  • participating tenants;
  • authority;
  • purpose;
  • disclosure;
  • security;
  • revocation;
  • provenance.

25.18.19. Relationship Compilation​

The Constitutional Compiler SHOULD produce:

  • graph schemas;
  • endpoint constraints;
  • inverse rules;
  • cardinality validators;
  • temporal validators;
  • API representations;
  • event schemas;
  • publication mappings;
  • conformance fixtures.

25.18.20. Relationship Validation​

HECATE SHALL validate:

  • identity;
  • Namespace;
  • endpoints;
  • direction;
  • inverse;
  • properties;
  • cardinality;
  • evidence;
  • authority;
  • temporal state;
  • tenant isolation;
  • inference;
  • compatibility;
  • provenance.

25.19. Graph Constraint and Inference Extensions​

A Graph Constraint Extension adds or specialises rules governing valid graph structure.

An Inference Extension defines when new derived assertions or relationships may be produced from existing graph state.

Inference SHALL remain distinct from asserted truth.

25.19.1. Graph Constraint Identity​

Every Graph Constraint SHALL possess:

  • Graph Constraint Identifier;
  • Namespace;
  • semantic purpose;
  • target node or Relationship Types;
  • rule;
  • scope;
  • severity;
  • authority;
  • temporal semantics;
  • tenant semantics;
  • validation stage;
  • compatibility;
  • version;
  • provenance.

25.19.2. Graph Constraint Types​

Constraint Types MAY include:

  • node-shape constraint;
  • property constraint;
  • endpoint constraint;
  • cardinality constraint;
  • uniqueness constraint;
  • acyclicity constraint;
  • path constraint;
  • temporal-overlap constraint;
  • tenant-boundary constraint;
  • authority constraint;
  • evidence constraint;
  • publication constraint.

25.19.3. Node Shape​

A Node Shape SHALL define:

  • applicable Object Types;
  • required properties;
  • optional properties;
  • prohibited properties;
  • permitted Relationship Types;
  • conditional constraints;
  • severity;
  • provenance.

25.19.4. Relationship Shape​

A Relationship Shape SHALL define:

  • Relationship Type;
  • permitted endpoints;
  • required relationship properties;
  • cardinality;
  • evidence;
  • authority;
  • temporal treatment;
  • provenance.

25.19.5. Path Constraint​

A Path Constraint MAY govern:

  • maximum path length;
  • permitted Relationship Types;
  • prohibited traversal;
  • tenant boundary;
  • security classification;
  • inference use;
  • publication use;
  • provenance.

25.19.6. Cycle Constraint​

A cycle MAY be:

  • prohibited;
  • permitted;
  • conditionally permitted;
  • required for defined structures.

Cycle treatment SHALL be explicit.

25.19.7. Temporal Graph Constraint​

A temporal constraint MAY prohibit:

  • overlapping exclusive relationships;
  • invalid sequence;
  • relationship before subject existence;
  • relationship after withdrawal;
  • inconsistent effective periods;
  • impossible event ordering.

25.19.8. Tenant Graph Constraint​

Tenant constraints SHALL prevent:

  • cross-tenant node traversal;
  • cross-tenant relationship creation;
  • inference across tenant boundaries;
  • public-node misuse;
  • shared-cache leakage;
  • graph projection leakage.

25.19.9. Inference Rule Identity​

Every Inference Rule Extension SHALL possess:

  • Inference Rule Identifier;
  • Namespace;
  • premises;
  • conclusion type;
  • reasoning method;
  • scope;
  • authority;
  • confidence treatment;
  • contradiction treatment;
  • temporal semantics;
  • tenant semantics;
  • publication treatment;
  • lifecycle;
  • version;
  • provenance.

25.19.10. Inference Classes​

Inference Classes MAY include:

  • deterministic;
  • monotonic;
  • non-monotonic;
  • probabilistic;
  • heuristic;
  • statistical;
  • machine-learned;
  • human-reviewed;
  • external-rule-based.

25.19.11. Derived Assertion​

Every inferred output SHALL be represented as a Derived Assertion or Derived Relationship with:

  • source premises;
  • Inference Rule;
  • rule version;
  • execution Component;
  • confidence;
  • time;
  • scope;
  • contradiction state;
  • validation;
  • activation state;
  • provenance.

25.19.12. Open-World and Closed-World Assumptions​

An Inference Rule SHALL declare whether absence of information is treated under:

  • open-world assumption;
  • closed-world assumption;
  • bounded closed-world assumption;
  • explicit-negation model.

25.19.13. Negation​

The Runtime SHALL distinguish:

  • absence;
  • explicit false;
  • contradicted;
  • unknown;
  • not applicable;
  • prohibited.

Inference SHALL not collapse these states.

25.19.14. Confidence​

Probabilistic or heuristic inference SHALL preserve:

  • confidence value;
  • confidence interpretation;
  • calibration method;
  • threshold;
  • uncertainty;
  • validation;
  • provenance.

25.19.15. Inference Authority​

An Inference Rule MAY be authorised for:

  • internal intelligence;
  • workflow recommendation;
  • validation support;
  • publication support;
  • authoritative activation.

Authoritative activation SHALL require separate governed approval where applicable.

25.19.16. Inference Conflict​

Conflicting inferred outputs SHALL preserve:

  • competing rules;
  • premises;
  • confidence;
  • precedence;
  • contradiction state;
  • resolution;
  • provenance.

25.19.17. Inference Retraction​

Where a premise changes or is withdrawn, affected Derived Assertions SHALL be:

  • invalidated;
  • recomputed;
  • suspended;
  • revalidated;
  • retained historically.

25.19.18. Recursive Inference​

Recursive inference SHALL define:

  • termination;
  • cycle handling;
  • depth;
  • fixed-point semantics;
  • performance limits;
  • explanation;
  • provenance.

25.19.19. Inference Isolation​

Inference SHALL not cross:

  • tenant boundaries;
  • restricted graph partitions;
  • incompatible Extension scopes;
  • prohibited security classifications;
  • revoked trust boundaries.

25.19.20. Inference Publication​

A Derived Assertion SHALL not be published as authoritative fact unless the Publication Profile, validation state, authority, evidence and assurance permit it.

25.19.21. Graph Constraint Compilation​

The Constitutional Compiler SHOULD produce:

  • graph shapes;
  • validation queries;
  • inference plans;
  • dependency graphs;
  • invalidation rules;
  • explanation templates;
  • conformance fixtures.

25.19.22. Graph and Inference Validation​

HECATE SHALL validate:

  • constraint identity;
  • target shapes;
  • severity;
  • path and cycle treatment;
  • temporal and tenant constraints;
  • inference premises;
  • conclusion;
  • confidence;
  • contradiction;
  • authority;
  • publication;
  • provenance.

25.20. Identity, Alias and Mapping Extensions​

Identity Extensions govern how external, legacy, local and specialised identifiers relate to ZAYAZ constitutional identities.

Mapping SHALL not silently collapse distinct meaning.

25.20.1. Identity Extension​

An Identity Extension MAY introduce:

  • external identifier scheme;
  • tenant identifier scheme;
  • white-label identifier scheme;
  • sector identifier scheme;
  • public identifier;
  • legacy identifier;
  • composite identifier;
  • resolver profile.

25.20.2. Identifier Scheme​

Every Identifier Scheme SHALL possess:

  • Identifier Scheme Identifier;
  • Namespace;
  • issuer;
  • owner;
  • authority;
  • syntax;
  • uniqueness scope;
  • subject types;
  • issuance policy;
  • resolution policy;
  • lifecycle;
  • version;
  • provenance.

25.20.3. Identifier Assignment​

An assignment SHALL preserve:

  • identifier;
  • scheme;
  • subject;
  • issuer;
  • authority;
  • assignment time;
  • validity;
  • revocation;
  • provenance.

25.20.4. Canonical Identity​

Canonical ZAYAZ identity SHALL remain distinct from external identifiers.

External identifiers MAY resolve to canonical identity but SHALL not replace it.

25.20.5. Composite Identity​

A composite identity SHALL define:

  • constituent identifiers;
  • ordering;
  • normalization;
  • uniqueness;
  • scope;
  • version;
  • provenance.

25.20.6. Alias Extension​

An Alias Extension SHALL identify:

  • canonical identity;
  • alias;
  • alias type;
  • language;
  • context;
  • source;
  • ambiguity;
  • validity;
  • deprecation;
  • provenance.

25.20.7. Mapping Extension​

A Mapping Extension SHALL identify:

  • Mapping Identifier;
  • source Namespace;
  • target Namespace;
  • source artefact;
  • target artefact;
  • mapping type;
  • conditions;
  • transformation;
  • information loss;
  • confidence;
  • authority;
  • effective time;
  • version;
  • provenance.

25.20.8. Mapping Types​

Mapping Types MAY include:

  • exact equivalence;
  • narrower;
  • broader;
  • conditional equivalence;
  • aggregation;
  • decomposition;
  • transformation;
  • approximation;
  • reference only;
  • no safe mapping.

25.20.9. Mapping Direction​

Mappings MAY be:

  • unidirectional;
  • bidirectional;
  • reversible;
  • partially reversible;
  • non-reversible.

Direction SHALL be explicit.

25.20.10. Lossy Mapping​

A lossy mapping SHALL identify:

  • lost properties;
  • lost precision;
  • lost hierarchy;
  • lost temporal detail;
  • lost provenance detail;
  • impact;
  • permitted uses.

25.20.11. Ambiguous Mapping​

An ambiguous mapping SHALL preserve all candidate targets and SHALL NOT resolve automatically unless an approved Resolution Policy permits it.

25.20.12. Mapping Conditions​

Conditions MAY depend on:

  • jurisdiction;
  • framework version;
  • sector;
  • tenant;
  • reporting period;
  • object subtype;
  • property value;
  • unit;
  • methodology;
  • time.

25.20.13. Mapping Authority​

Mapping authorship SHALL remain distinct from Mapping Approval Authority.

An external published crosswalk SHALL not automatically become an approved ZAYAZ mapping.

25.20.14. Mapping Conflict​

A Mapping Conflict MAY arise where:

  • multiple target mappings apply;
  • reciprocal mappings disagree;
  • mappings differ by version;
  • tenant mapping conflicts with framework mapping;
  • information loss exceeds permitted threshold.

25.20.15. Mapping Resolution Outcome​

A Mapping Resolution Outcome SHALL preserve:

  • source;
  • candidate mappings;
  • selected mapping;
  • rejected mappings;
  • conditions;
  • information loss;
  • confidence;
  • authority;
  • explanation;
  • provenance.

25.20.16. Identity Merge​

An identity merge SHALL preserve:

  • source identities;
  • surviving identity;
  • merge authority;
  • effective time;
  • affected relationships;
  • affected Publications;
  • migration;
  • provenance.

25.20.17. Identity Split​

An identity split SHALL preserve:

  • source identity;
  • new identities;
  • allocation rule;
  • unresolved references;
  • historical interpretation;
  • migration;
  • provenance.

25.20.18. Identity Revocation​

Revocation SHALL preserve:

  • revoked identifier;
  • subject;
  • reason;
  • authority;
  • effective time;
  • replacement;
  • historical resolution;
  • provenance.

25.20.19. Public Resolver​

A public resolver MAY expose approved identifier status and public mappings.

It SHALL comply with the Constitutional Publication Framework and SHALL not expose restricted identity data.

25.20.20. Mapping Compilation​

The Constitutional Compiler SHOULD produce:

  • mapping tables;
  • transformation functions;
  • resolver rules;
  • compatibility checks;
  • migration artefacts;
  • API mappings;
  • conformance fixtures.

25.20.21. Identity and Mapping Validation​

HECATE SHALL validate:

  • scheme;
  • assignment;
  • canonical identity;
  • alias;
  • mapping type;
  • conditions;
  • direction;
  • information loss;
  • ambiguity;
  • merge or split;
  • revocation;
  • provenance.

25.21. Validation Rule and Constraint Extensions​

A Validation Rule Extension adds or specialises a governed rule used to determine whether constitutional structure or instances conform to applicable requirements.

Validation Extensions SHALL not create publication approval, assurance or constitutional authority.

25.21.1. Validation Rule Identity​

Every Validation Rule Extension SHALL possess:

  • Validation Rule Identifier;
  • Namespace;
  • canonical name;
  • semantic definition;
  • owner;
  • authority;
  • Extension Point;
  • target artefacts;
  • rule expression;
  • evaluation context;
  • severity;
  • failure code;
  • remediation guidance;
  • lifecycle;
  • version;
  • provenance.

25.21.2. Validation Rule Types​

Rule Types MAY include:

  • schema rule;
  • datatype rule;
  • property rule;
  • unit rule;
  • enumeration rule;
  • Registry rule;
  • Relationship rule;
  • graph rule;
  • temporal rule;
  • authority rule;
  • evidence rule;
  • security rule;
  • publication rule;
  • compatibility rule;
  • migration rule;
  • cross-object rule.

25.21.3. Validation Target​

A target MAY be:

  • Extension Definition;
  • Structural Artefact;
  • object instance;
  • property value;
  • relationship instance;
  • graph subgraph;
  • Registry entry;
  • mapping;
  • Package;
  • Runtime Bundle;
  • Publication Object;
  • migration result.

25.21.4. Validation Context​

The rule SHALL identify required context, including:

  • tenant;
  • white-label;
  • jurisdiction;
  • framework;
  • time;
  • object state;
  • publication purpose;
  • assurance state;
  • security classification;
  • Runtime Bundle.

25.21.5. Rule Expression​

A Rule Expression SHALL preserve:

  • source language or abstract expression;
  • normalized representation;
  • inputs;
  • outputs;
  • side-effect prohibition;
  • determinism;
  • dependencies;
  • provenance.

25.21.6. Deterministic Validation​

Equivalent input, context, rule version and dependency versions SHALL produce semantically equivalent Validation Results.

25.21.7. Validation Severity​

Severity MAY include:

  • Information;
  • Warning;
  • Moderate;
  • High;
  • Critical;
  • Blocking.

Severity SHALL be governed and SHALL not be inferred from implementation exceptions.

25.21.8. Validation Result​

Every Validation Result SHALL preserve:

  • Validation Result Identifier;
  • rule;
  • target;
  • observed state;
  • expected state;
  • outcome;
  • severity;
  • evidence;
  • explanation;
  • remediation;
  • time;
  • Component;
  • provenance.

25.21.9. Rule Preconditions​

A rule MAY apply only where explicit preconditions hold.

Failure to satisfy preconditions SHALL be distinguished from rule failure.

25.21.10. Cross-Property Rule​

A cross-property rule SHALL preserve:

  • participating properties;
  • dependency direction;
  • condition;
  • null treatment;
  • temporal alignment;
  • explanation;
  • provenance.

25.21.11. Cross-Object Rule​

A cross-object rule SHALL identify:

  • object types;
  • relationship path;
  • scope;
  • tenant boundary;
  • time;
  • consistency requirement;
  • provenance.

25.21.12. Validation Override​

A Validation Result MAY be overridden only where:

  • the rule is overrideable;
  • authority exists;
  • scope is explicit;
  • reason is recorded;
  • risk is accepted;
  • duration is bounded;
  • compensating controls exist;
  • provenance is preserved.

25.21.13. Non-Overrideable Validation​

Non-overrideable validation MAY include:

  • Namespace collision;
  • invalid Core identifier reuse;
  • cross-tenant leakage;
  • invalid signature;
  • prohibited Relationship endpoint;
  • incompatible unit;
  • missing authority;
  • withdrawn Package;
  • materially incomplete provenance.

25.21.14. Rule Precedence​

Where multiple rules apply, precedence SHALL consider:

  • Core authority;
  • legal authority;
  • Extension Point contract;
  • restrictive rule;
  • scope specificity;
  • effective time;
  • approved override.

25.21.15. Rule Conflict​

Conflicting Validation Rules SHALL produce an explicit Rule Conflict.

Unresolved conflict SHALL block authoritative activation or use.

25.21.16. Validation Profile​

A Validation Profile SHALL define:

  • applicable rules;
  • rule versions;
  • sequence;
  • parallel stages;
  • severities;
  • fail-fast policy;
  • exception policy;
  • completion criteria;
  • provenance.

25.21.17. Incremental Validation​

Incremental validation MAY evaluate only affected artefacts where dependency analysis proves completeness.

The dependency basis SHALL be preserved.

25.21.18. Validation Cache​

A cached Validation Result MAY be reused only where:

  • target digest matches;
  • context fingerprint matches;
  • rule versions match;
  • dependency versions match;
  • authority remains valid;
  • cache policy permits.

25.21.19. Rule Deprecation​

Rule deprecation SHALL identify:

  • replacement;
  • final-use date;
  • affected profiles;
  • migration;
  • historical replay support;
  • provenance.

25.21.20. Validation Rule Compilation​

The Constitutional Compiler SHOULD produce:

  • executable validators;
  • dependency graphs;
  • result schemas;
  • error codes;
  • explanation templates;
  • test fixtures;
  • manifest entries.

25.21.21. Validation Extension Validation​

HECATE SHALL validate:

  • Rule identity;
  • target;
  • context;
  • expression;
  • determinism;
  • severity;
  • override policy;
  • conflict;
  • profile inclusion;
  • cache safety;
  • provenance.

25.22. Structural Migration, Backfill and Coexistence​

Structural Extensions MAY require migration of existing data, graph state, Registry entries, event payloads, workflows, APIs, Publications or evidence.

Migration SHALL preserve identity, meaning, time, tenant, authority and provenance.

25.22.1. Structural Migration Object​

Every material Structural Migration SHALL possess:

  • Migration Identifier;
  • source Structural Snapshot;
  • target Structural Snapshot;
  • affected Extension;
  • affected Object Types;
  • affected properties;
  • affected datatypes and units;
  • affected Registry entries;
  • affected Relationship Types;
  • affected validation rules;
  • affected tenants;
  • authority;
  • plan;
  • lifecycle;
  • version;
  • provenance.

25.22.2. Migration Types​

Migration Types MAY include:

  • Object Type migration;
  • property addition;
  • property rename;
  • property split;
  • property merge;
  • datatype conversion;
  • unit conversion;
  • enumeration migration;
  • Registry-entry migration;
  • Relationship Type migration;
  • graph-shape migration;
  • identity migration;
  • validation-rule migration;
  • schema-version migration.

25.22.3. Migration Plan​

A Migration Plan SHALL define:

  • source and target versions;
  • eligibility;
  • affected records and relationships;
  • transformation;
  • validation;
  • backfill;
  • cutover;
  • coexistence;
  • rollback;
  • reconciliation;
  • publication impact;
  • retention;
  • provenance.

25.22.4. Migration Authority​

Migration SHALL require authority over:

  • source artefacts;
  • target artefacts;
  • affected tenant;
  • affected data;
  • affected graph;
  • affected Publications;
  • affected runtime.

25.22.5. Migration Eligibility​

Migration eligibility SHALL evaluate:

  • source identity;
  • source version;
  • target compatibility;
  • tenant scope;
  • data quality;
  • legal constraints;
  • retention;
  • active workflows;
  • active Publications;
  • assurance;
  • rollback feasibility.

25.22.6. Backfill​

Backfill SHALL preserve:

  • source snapshot;
  • extraction time;
  • transformation;
  • generated values;
  • default use;
  • estimation;
  • rejected records;
  • counts;
  • validation;
  • provenance.

A backfilled value SHALL identify whether it was:

  • directly transformed;
  • inferred;
  • defaulted;
  • estimated;
  • manually supplied;
  • unavailable.

25.22.7. Property Rename​

A property rename that changes only display or physical name SHALL preserve canonical Property identity.

A semantic rename SHALL create a new property identity or version according to compatibility rules.

25.22.8. Property Split​

A property split SHALL preserve:

  • source property;
  • target properties;
  • distribution rule;
  • ambiguous cases;
  • missing cases;
  • historical interpretation;
  • provenance.

25.22.9. Property Merge​

A property merge SHALL preserve:

  • source properties;
  • target property;
  • precedence;
  • conflict treatment;
  • information loss;
  • historical interpretation;
  • provenance.

25.22.10. Datatype Migration​

A datatype migration SHALL preserve:

  • source and target datatypes;
  • conversion;
  • precision loss;
  • invalid values;
  • null treatment;
  • ordering changes;
  • serialization changes;
  • provenance.

25.22.11. Unit Migration​

A unit migration SHALL preserve:

  • source and target units;
  • conversion rule;
  • factor source;
  • context;
  • rounding;
  • uncertainty;
  • original value;
  • converted value;
  • provenance.

25.22.12. Enumeration Migration​

An enumeration migration SHALL preserve:

  • source values;
  • target values;
  • mapping;
  • unmapped values;
  • merged values;
  • split values;
  • deprecation;
  • provenance.

25.22.13. Relationship Migration​

A Relationship migration SHALL preserve:

  • source Relationship Type;
  • target Relationship Type;
  • endpoint mapping;
  • property mapping;
  • temporal state;
  • evidence;
  • authority;
  • inference impact;
  • provenance.

25.22.14. Identity Migration​

Identity migration SHALL preserve:

  • source identity;
  • target identity;
  • aliases;
  • mappings;
  • affected references;
  • affected relationships;
  • affected Publications;
  • historical resolver behaviour;
  • provenance.

25.22.15. Dual-Schema Coexistence​

A coexistence period MAY support source and target schemas simultaneously.

It SHALL define:

  • authoritative schema;
  • read behaviour;
  • write behaviour;
  • transformation;
  • event treatment;
  • validation;
  • conflict handling;
  • sunset;
  • provenance.

25.22.16. Dual Write​

Dual write SHOULD be avoided where atomic consistency cannot be established.

Where required, it SHALL define:

  • authoritative side;
  • write order;
  • transaction semantics;
  • retry;
  • reconciliation;
  • compensation;
  • provenance.

25.22.17. Dual Read​

Dual read MAY compare source and target representations.

It SHALL define:

  • authoritative result;
  • divergence threshold;
  • conflict treatment;
  • performance impact;
  • tenant scope;
  • provenance.

25.22.18. Event Migration​

Event migration SHALL preserve:

  • Event Type identity;
  • schema version;
  • event identity;
  • order;
  • correlation;
  • causation;
  • tenant;
  • replay;
  • provenance.

Historical event payloads SHALL remain interpretable.

25.22.19. Publication Impact​

Structural migration SHALL evaluate impact on:

  • Publication Objects;
  • released Publications;
  • machine schemas;
  • APIs;
  • datasets;
  • passports;
  • correction and restatement obligations;
  • assurance conclusions;
  • historical reconstruction.

25.22.20. Migration Reconciliation​

Reconciliation SHALL compare:

  • record counts;
  • object identities;
  • property values;
  • units;
  • Registry values;
  • relationships;
  • temporal intervals;
  • validation results;
  • publication outputs;
  • provenance.

25.22.21. Migration Finding​

A Migration Finding SHALL identify:

  • affected artefact;
  • source state;
  • target state;
  • difference;
  • severity;
  • materiality;
  • tenant;
  • remediation;
  • provenance.

25.22.22. Cutover​

Cutover SHALL identify:

  • cutover time;
  • Clock Source;
  • source freeze;
  • final synchronization;
  • validation;
  • traffic or workload shift;
  • rollback window;
  • authority;
  • tenant communication;
  • provenance.

25.22.23. Rollback​

Rollback SHALL define:

  • trigger;
  • authority;
  • source restoration;
  • reverse transformation;
  • event treatment;
  • publication treatment;
  • data-loss risk;
  • validation;
  • provenance.

25.22.24. Migration Completion​

Migration SHALL be complete only where:

  • target structure is active;
  • required data and graph state migrated;
  • reconciliation passed;
  • findings are resolved or accepted;
  • events remain interpretable;
  • Publications remain verifiable;
  • old structure is governed;
  • provenance is complete.

25.22.25. Migration Validation​

HECATE SHALL validate:

  • plan;
  • authority;
  • source and target snapshots;
  • transformation;
  • backfill;
  • coexistence;
  • reconciliation;
  • cutover;
  • rollback;
  • publication impact;
  • provenance.

25.23. Structural Extension Runtime and Projection Integration​

Structural Extensions SHALL be applied through governed runtime resolution and projection.

Physical implementations SHALL derive from approved structural state rather than becoming the source of constitutional structure.

25.23.1. Structural Resolution Request​

Every material Structural Resolution Request SHALL identify:

  • Runtime Context;
  • Core release;
  • Runtime Bundle;
  • subject or Object Type;
  • tenant;
  • white-label deployment;
  • jurisdiction;
  • framework;
  • effective time;
  • requested capability;
  • provenance.

25.23.2. Candidate Structural Extensions​

Candidate Extensions MAY include:

  • global approved structural Extensions;
  • framework Extensions;
  • jurisdictional Extensions;
  • sector Extensions;
  • white-label Extensions;
  • tenant Extensions;
  • organisation Extensions;
  • experimental Extensions where permitted.

25.23.3. Candidate Evaluation​

Each candidate SHALL be evaluated for:

  • identity;
  • Namespace;
  • Extension Point;
  • activation;
  • scope;
  • authority;
  • compatibility;
  • dependencies;
  • temporal validity;
  • tenant;
  • security;
  • provenance.

25.23.4. Effective Structural Model​

The Effective Structural Model SHALL identify:

  • Object Types;
  • schemas;
  • properties;
  • datatypes;
  • units;
  • controlled values;
  • Registries;
  • Relationship Types;
  • graph constraints;
  • inference rules;
  • validation rules;
  • mappings;
  • versions;
  • provenance.

25.23.5. Structural Context Fingerprint​

The Effective Structural Model SHOULD possess a fingerprint derived from:

  • Core release;
  • Runtime Bundle;
  • active Extension Packages;
  • tenant;
  • jurisdiction;
  • framework;
  • effective time;
  • Structural Artefact versions;
  • validation profiles.

25.23.6. Projection Plan​

A Projection Plan SHALL identify:

  • source Effective Structural Model;
  • target technology or representation;
  • included artefacts;
  • excluded artefacts;
  • transformation;
  • information loss;
  • target version;
  • Component;
  • validation;
  • provenance.

25.23.7. Database Projection​

A database projection SHALL preserve:

  • tables or collections;
  • fields;
  • keys;
  • constraints;
  • indexes;
  • tenant partitioning;
  • temporal fields;
  • migration;
  • provenance.

A database schema SHALL not silently introduce constitutional properties.

25.23.8. Graph Projection​

A graph projection SHALL preserve:

  • node labels or types;
  • Relationship Types;
  • properties;
  • endpoint constraints;
  • tenant partitioning;
  • temporal semantics;
  • inference state;
  • provenance.

25.23.9. API Projection​

An API projection SHALL preserve:

  • object and property identities;
  • schema version;
  • null semantics;
  • units;
  • tenant;
  • security;
  • compatibility;
  • deprecation;
  • provenance.

25.23.10. Event Projection​

An event projection SHALL preserve:

  • Event Type;
  • payload schema;
  • object and property identities;
  • tenant;
  • event and transaction time;
  • version;
  • replay;
  • provenance.

25.23.11. User Interface Projection​

A UI projection MAY derive:

  • labels;
  • forms;
  • controls;
  • field ordering;
  • help text;
  • validation messages;
  • conditional visibility.

UI presentation SHALL not redefine property semantics or validation.

25.23.12. Search Projection​

A search projection SHALL preserve:

  • source identity;
  • property identity;
  • tenant;
  • classification;
  • analyzers;
  • language;
  • freshness;
  • deletion state;
  • provenance.

25.23.13. Vector Projection​

A vector projection SHALL preserve:

  • source identity;
  • source version;
  • tenant;
  • embedding model;
  • model version;
  • selected properties;
  • transformation;
  • classification;
  • retention;
  • deletion linkage;
  • provenance.

Vector similarity SHALL not create constitutional equivalence.

25.23.14. Publication Projection​

A Publication projection SHALL preserve:

  • source Structural Artefacts;
  • Publication Profile;
  • audience;
  • disclosure;
  • units;
  • labels;
  • controlled values;
  • schema;
  • version;
  • provenance.

25.23.15. Projection Loss​

Every lossy projection SHALL identify:

  • omitted artefacts;
  • reduced precision;
  • flattened hierarchy;
  • collapsed temporal detail;
  • removed security metadata;
  • removed provenance detail;
  • permitted uses;
  • provenance.

25.23.16. Projection Validation​

HECATE SHALL validate:

  • source model;
  • target projection;
  • identity preservation;
  • compatibility;
  • information loss;
  • tenant isolation;
  • security;
  • provenance.

25.23.17. Structural Cache​

A cached Effective Structural Model MAY be reused only where:

  • Structural Context Fingerprint matches;
  • Extension versions remain active;
  • authority remains valid;
  • tenant remains equivalent;
  • no withdrawal or migration applies;
  • cache policy permits.

25.23.18. Hot Activation​

Hot activation of a Structural Extension MAY occur only where:

  • compatibility is proven;
  • migration is unnecessary or completed;
  • active transactions remain safe;
  • caches are invalidated;
  • Components support the version;
  • rollback is available;
  • provenance is preserved.

25.23.19. Structural Runtime Failure​

Failure MAY include:

  • unresolved schema;
  • missing dependency;
  • incompatible Component;
  • invalid projection;
  • stale cache;
  • tenant-scope mismatch;
  • unknown Registry value;
  • graph constraint failure;
  • migration gap.

Failure SHALL produce explicit rejection, quarantine or degraded state.

25.23.20. Structural Runtime Receipt​

A Structural Runtime Receipt SHOULD contain:

  • Resolution Request;
  • Effective Structural Model;
  • fingerprint;
  • selected Extensions;
  • rejected Extensions;
  • Runtime Bundle;
  • projections;
  • validation;
  • Component lineage;
  • time;
  • provenance.

25.23.21. Runtime Replay​

Replay SHALL use historical:

  • Core release;
  • Runtime Bundle;
  • Extension Packages;
  • Structural Snapshot;
  • profiles;
  • migrations;
  • projection Components;
  • validation rules;
  • tenant context.

25.23.22. Runtime Diff​

A Structural Runtime Diff SHOULD identify changes in:

  • Object Types;
  • properties;
  • datatypes;
  • units;
  • Registries;
  • Relationship Types;
  • constraints;
  • mappings;
  • validation;
  • projections;
  • provenance.

25.23.23. Runtime Impact Analysis​

Structural change SHALL support impact analysis over:

  • data;
  • graph;
  • events;
  • workflows;
  • agents;
  • tools;
  • APIs;
  • searches;
  • vectors;
  • computations;
  • validations;
  • Publications;
  • assurance;
  • audits;
  • tenants;
  • Modules;
  • Components.

25.24. Structural Extension Provenance and Conformance​

Structural Extensions SHALL preserve complete lineage from Core Extension Point to runtime and publication effect.

25.24.1. Structural Provenance​

Structural provenance SHALL include:

  • Core release;
  • Extension Proposal;
  • Extension Definition;
  • Extension Point;
  • Namespace;
  • owner;
  • authority;
  • Structural Artefacts;
  • dependencies;
  • compatibility;
  • validation;
  • Package;
  • Manifest;
  • activation;
  • Structural Snapshot;
  • migration;
  • projection;
  • runtime use;
  • publication use;
  • Module lineage;
  • Component lineage;
  • tenant lineage;
  • temporal lineage.

25.24.2. Structural Provenance Graph​

Core Structural Artefact
        │
        ▼
Structural Extension Point
        │
        ▼
Structural Extension Definition
        │
        ├── Object Type
        ├── Property
        ├── Datatype and Unit
        ├── Value or Registry
        ├── Relationship Type
        ├── Graph Constraint
        ├── Mapping
        └── Validation Rule
        │
        ▼
Extension Package and Manifest
        │
        ▼
Activation
        │
        ▼
Effective Structural Model
        │
        ▼
Technology Projections
        │
        ▼
Runtime, Data, Graph and Publication Use
        │
        ▼
Migration, Deprecation or Withdrawal

25.24.3. Structural Extension Receipt​

A high-impact Structural Extension action SHOULD produce a receipt containing:

  • action;
  • Structural Extension;
  • Package;
  • Manifest digest;
  • Core release;
  • Extension Point;
  • Namespace;
  • target scope;
  • authority;
  • compatibility;
  • migration state;
  • Effective Structural Model;
  • validation;
  • Runtime Bundle;
  • Module and Component lineage;
  • provenance.

25.24.4. Structural History Object​

A Structural History Object SHALL preserve:

  • artefact identity;
  • all versions;
  • parent lineage;
  • compatibility;
  • activation history;
  • migrations;
  • deprecations;
  • supersessions;
  • withdrawals;
  • projections;
  • provenance.

25.24.5. Provenance Completeness​

Completeness MAY be:

  • Complete;
  • Complete with Controlled Redaction;
  • Materially Complete;
  • Partially Complete;
  • Materially Incomplete;
  • Reconstructed;
  • Disputed;
  • Unavailable.

Materially incomplete provenance SHALL block unqualified high-assurance structural conformance.

25.24.6. Structural Replay​

Structural Replay SHALL reconstruct:

  • Core release;
  • Extension state;
  • Effective Structural Model;
  • applicable validation;
  • migrations;
  • projections;
  • runtime effects;
  • publication effects.

25.24.7. Structural Diff​

A Structural Diff SHALL be able to identify:

  • added artefacts;
  • removed artefacts;
  • changed semantics;
  • changed datatype;
  • changed unit;
  • changed cardinality;
  • changed null treatment;
  • changed Registry values;
  • changed Relationship endpoints;
  • changed graph constraints;
  • changed validation;
  • changed compatibility;
  • changed scope;
  • provenance.

25.24.8. Structural Impact Analysis​

Impact analysis SHALL include:

  • existing instances;
  • historical instances;
  • data stores;
  • graph stores;
  • event streams;
  • APIs;
  • workflows;
  • agents;
  • tools;
  • computations;
  • reports;
  • Publications;
  • assurance conclusions;
  • audit evidence;
  • Runtime Bundles;
  • tenants;
  • white-label deployments;
  • Modules;
  • Components.

25.24.9. Structural Audit​

An audit MAY examine:

  • Extension Point validity;
  • Namespace;
  • identity;
  • semantic definition;
  • schema;
  • datatype;
  • unit;
  • Registry authority;
  • graph constraints;
  • mapping;
  • validation;
  • migration;
  • projection;
  • tenant isolation;
  • provenance.

25.24.10. Structural Findings​

A Structural Finding SHALL identify:

  • affected artefact;
  • criterion;
  • observed state;
  • expected state;
  • severity;
  • materiality;
  • affected tenants;
  • affected Runtime Bundles;
  • affected Publications;
  • remediation;
  • owner;
  • provenance.

25.24.11. Pergamum Pulse Integration​

Pergamum Pulse MAY derive intelligence including:

  • schema fragmentation;
  • property duplication;
  • datatype divergence;
  • unit inconsistency;
  • Registry sprawl;
  • mapping ambiguity;
  • Relationship Type proliferation;
  • graph-constraint conflict;
  • inference risk;
  • migration backlog;
  • stale projections;
  • tenant structural divergence;
  • white-label structural divergence;
  • Module-level structural risk;
  • Component-level structural risk.

Pergamum Pulse SHALL preserve:

  • Module lineage;
  • Component lineage;
  • Structural Extension lineage;
  • Object Type lineage;
  • Property lineage;
  • Datatype and Unit lineage;
  • Registry lineage;
  • Relationship Type lineage;
  • Validation Rule lineage;
  • migration lineage;
  • projection lineage;
  • tenant lineage;
  • temporal validity;
  • provenance.

Derived intelligence SHALL remain Intelligence Layer assertions until governed activation.

25.24.12. Part II Conformance Suite​

The Constitutional Compiler Framework SHOULD generate fixtures including:

  • valid new Object Type;
  • valid Object Specialisation;
  • prohibited Object generalisation;
  • Open Schema with namespaced property;
  • unknown unnamespaced property;
  • required-property addition;
  • property with governed null semantics;
  • invalid default;
  • computed property;
  • observed property;
  • valid custom datatype;
  • incompatible datatype change;
  • direct unit conversion;
  • context-dependent unit conversion;
  • incompatible units;
  • valid Enumeration value;
  • unknown controlled value;
  • Registry merge;
  • Registry split;
  • valid Relationship Type;
  • invalid endpoint;
  • temporal cardinality conflict;
  • cross-tenant relationship rejection;
  • valid graph shape;
  • path-boundary violation;
  • deterministic inference;
  • invalid cross-tenant inference;
  • inference retraction;
  • exact mapping;
  • lossy mapping;
  • ambiguous mapping;
  • valid Validation Rule;
  • prohibited validation override;
  • schema migration;
  • property split migration;
  • unit migration;
  • dual-schema coexistence;
  • migration reconciliation;
  • valid Structural Projection;
  • lossy projection disclosure;
  • Structural Drift detection;
  • historical Structural Replay.

Part II Conformance​

An implementation conforms to Part II of the Constitutional Extension Framework where it:

  1. represents Structural Extensions as governed constitutional artefacts;
  2. distinguishes abstract constitutional structure from physical implementation schemas;
  3. requires stable identity, Namespace, authority, scope, version and provenance for every Structural Artefact;
  4. preserves Core Structural Artefacts from in-place Extension mutation;
  5. represents Object Type Extensions and Object Specialisations explicitly;
  6. prevents incompatible generalisation of Core Object Types through Extensions;
  7. governs Open and Closed Schemas explicitly;
  8. prevents unknown properties from becoming constitutionally valid through silent schema acceptance;
  9. gives every extended property independent constitutional identity;
  10. preserves property semantics, datatype, unit, cardinality, nulls, defaults, time, security and publication treatment;
  11. distinguishes declared, observed, computed and derived properties;
  12. prevents defaults from fabricating evidence;
  13. governs custom datatypes through explicit lexical and value spaces;
  14. preserves quantity kind, dimension, unit, conversion, precision and uncertainty;
  15. rejects unknown or incompatible unit conversion;
  16. extends controlled values only through governed Value Providers and Registries;
  17. preserves value identity, hierarchy, aliases, mappings, lifecycle and authority;
  18. prevents unknown input text from silently creating controlled values;
  19. governs Registry entry merge, split, deprecation and public projection;
  20. represents Relationship Type Extensions independently from physical graph edge labels;
  21. preserves endpoints, direction, inverse, cardinality, properties, evidence, authority, time and tenant scope;
  22. prevents unauthorised cross-tenant relationships;
  23. governs graph shapes, path constraints, cycle constraints and temporal constraints;
  24. represents inferred outputs as Derived Assertions or Derived Relationships rather than asserted truth;
  25. preserves inference premises, rule version, confidence, contradiction and invalidation;
  26. prevents inference across prohibited tenant or security boundaries;
  27. governs identifier schemes, aliases, mappings, merges, splits and revocations;
  28. preserves mapping direction, conditions, ambiguity and information loss;
  29. governs Validation Rule Extensions through explicit targets, contexts, severities, overrides and profiles;
  30. prevents non-overrideable structural validation from being bypassed;
  31. governs structural migration, backfill, coexistence, cutover, reconciliation and rollback;
  32. preserves original values, identities, units, relationships and temporal states through migration;
  33. evaluates publication and assurance impact of structural migration;
  34. resolves Effective Structural Models through CRP and validates them through HECATE;
  35. projects structural models into databases, graphs, APIs, events, UIs, search, vectors and Publications without losing source lineage;
  36. discloses information loss in lossy projections;
  37. detects Structural Drift;
  38. supports historical Structural Snapshots, replay, diff and impact analysis;
  39. preserves both Module and Component lineage;
  40. integrates Pergamum Pulse without granting intelligence structural authority;
  41. provides conformance fixtures covering schemas, properties, datatypes, units, Registries, relationships, inference, mappings, validation, migration and projection.

Part II Foundational Principle​

Structural extensibility is the governed constitutional mechanism through which ZAYAZ may add or specialise Object Types, schemas, properties, datatypes, units, controlled values, Registries, Relationship Types, graph constraints, inference rules, mappings and validation without fragmenting Core meaning.

Every Structural Artefact SHALL possess stable identity, an approved Namespace, an explicit Extension Point, bounded authority, declared compatibility, tenant scope, temporal semantics, validation and complete provenance. Technical schema acceptance, database deployment, graph storage or API exposure SHALL not establish constitutional validity.

Structural migration SHALL preserve identity, value, unit, relationship, time, evidence, publication meaning and historical interpretation. Projections into databases, graphs, APIs, events, user interfaces, search indexes, vector stores and Publications SHALL preserve source lineage and disclose information loss.

By making structural Extensions namespace-safe, semantically explicit, graph-aware, migration-governed, compiler-projected, HECATE-validated and historically reconstructable, ZAYAZ can support customer, sector, jurisdictional and white-label specialisation without sacrificing Core coherence, tenant isolation, regulatory assurance or long-term data integrity.



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