Chapter 22 — Constitutional Relationships (CR)

Part I — Foundations

---

22.1. Introduction

Constitutional Relationships (CR) define the governed semantic, structural, temporal, computational and governance connections between Constitutional Objects within the ZAYAZ constitutional ecosystem.

While Constitutional Objects represent identifiable constitutional entities, Constitutional Relationships define the meaning, dependency, ownership, interaction and lineage between those entities.

A Constitutional Relationship is not merely a reference or implementation link. It is a first-class Constitutional Object with its own identity, semantics, governance, provenance, lifecycle and validation requirements.

Constitutional Relationships establish the constitutional topology of the ZAYAZ ecosystem, enabling deterministic reasoning, governance, traceability, impact analysis and knowledge discovery across all constitutional domains.

---

22.2. Purpose

The purpose of Constitutional Relationships is to establish a unified, technology-independent model for expressing every meaningful connection between Constitutional Objects.

The Constitutional Relationship architecture provides:

• semantic relationships;
• structural relationships;
• governance relationships;
• computational relationships;
• temporal relationships;
• dependency modelling;
• lineage;
• provenance;
• impact analysis;
• traceability;
• graph navigation;
• deterministic reasoning.

By governing relationships independently of implementation technologies, ZAYAZ ensures that constitutional meaning is preserved regardless of how relationships are represented within databases, APIs, programming languages or knowledge graphs.

---

22.3. Constitutional Principle

Every constitutionally significant connection between Constitutional Objects SHALL be represented by one or more Constitutional Relationships.

A Constitutional Relationship SHALL possess its own constitutional identity, semantic definition, governance, lifecycle and provenance.

Relationships SHALL NOT be treated merely as implementation references, foreign keys or object pointers.

Implementation references MAY be generated from Constitutional Relationships through governed compilation.

Constitutional Relationships SHALL remain technology independent.

---

22.4. Constitutional Position

Constitutional Relationships define the topology of the constitutional ecosystem.

Constitutional Object
        │
        │ participates in
        ▼
Constitutional Relationship
        │
        │ connects
        ▼
Constitutional Object

Together they establish the Constitutional Knowledge Graph.

Constitutional Objects

+

Constitutional Relationships

=

Constitutional Knowledge Graph

Every constitutional analysis—including governance, validation, reporting, impact analysis, AI reasoning and compilation—operates upon this governed graph.

---

22.5. Constitutional Relationship as a Constitutional Object

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

Each Constitutional Relationship SHALL possess:

• Constitutional Identifier;
• canonical name;
• relationship classification;
• relationship type;
• semantic definition;
• source object;
• target object;
• governing authority;
• applicability;
• jurisdiction;
• lifecycle;
• temporal validity;
• provenance;
• evidence;
• trust classification;
• assurance classification;
• version;
• publication profile.

Because Constitutional Relationships are Constitutional Objects, they participate fully in constitutional governance, lifecycle management, provenance preservation, validation and publication.

Relationships therefore become governable constitutional assets rather than hidden implementation details.

---

22.6. Constitutional Relationship Registry

All Constitutional Relationships SHALL be governed through one or more Constitutional Relationship Registries.

The Constitutional Relationship Registry governs:

• relationship identities;
• relationship types;
• semantic definitions;
• source and target definitions;
• lifecycle;
• provenance;
• temporal validity;
• relationship classifications;
• trust;
• evidence;
• compatibility;
• version history;
• publication.

Relationship Registries SHALL themselves be Constitutional Registries governed through the Constitutional Registry Registry.

---

22.7. Relationship Identity

Every Constitutional Relationship SHALL possess a globally unique Constitutional Identifier.

Relationship identity SHALL remain stable throughout its constitutional lifecycle.

Identity SHALL remain independent of:

• database foreign keys;
• API references;
• programming-language references;
• graph database identifiers;
• RDF predicates;
• serialization formats;
• implementation technologies.

Changing the technical representation of a relationship SHALL NOT change its constitutional identity.

Likewise, changing either the source or target object does not automatically preserve relationship identity. Where the semantic meaning of the relationship changes materially, a new Constitutional Relationship SHALL normally be established.

---

22.8. Relationship Semantics

Every Constitutional Relationship SHALL define one explicit constitutional meaning.

Relationship semantics SHALL describe:

• the nature of the relationship;
• the constitutional intent;
• the responsibilities implied by the relationship;
• behavioural implications;
• structural implications;
• governance implications;
• temporal implications;
• validation implications.

Relationship semantics SHALL originate from the Constitutional Knowledge Model and SHALL be described using the Constitutional Metadata Dictionary.

Implementation technologies SHALL NOT define relationship semantics.

Relationships with different constitutional meanings SHALL possess different Constitutional Relationship identities, even where their technical implementations appear identical.

---

22.9. Relationship Classification

Every Constitutional Relationship SHALL declare one or more Relationship Classifications.

Typical classifications include:

Structural Relationships

Describe structural organisation.

Examples:

• contains;
• composes;
• aggregates;
• specialises;
• extends.

---

Semantic Relationships

Describe constitutional meaning.

Examples:

• defines;
• describes;
• represents;
• classifies;
• maps to.

---

Governance Relationships

Describe constitutional governance.

Examples:

• governs;
• owns;
• stewards;
• approves;
• delegates;
• audits.

---

Resolution Relationships

Describe constitutional resolution.

Examples:

• resolves;
• selects;
• overrides;
• falls back to.

---

Validation Relationships

Describe constitutional validation.

Examples:

• validates;
• verifies;
• certifies;
• evidences.

---

Computational Relationships

Describe computational dependencies.

Examples:

• computes;
• derives;
• estimates;
• predicts.

---

Provenance Relationships

Describe lineage and origin.

Examples:

• originated from;
• imported from;
• synchronised with;
• transformed from.

---

Temporal Relationships

Describe chronological connections.

Examples:

• supersedes;
• replaces;
• succeeds;
• precedes;
• valid during.

---

Publication Relationships

Describe publication dependencies.

Examples:

• publishes;
• exposes;
• includes;
• references.

Relationship Classifications SHALL themselves originate from Constitutional Value Providers.

Multiple classifications MAY apply to the same Constitutional Relationship where constitutionally appropriate.

---

22.10. Relationship Directionality

Every Constitutional Relationship SHALL explicitly define its directionality.

Directionality establishes the constitutional interpretation of the relationship independently of implementation technologies.

A relationship MAY be:

• directional;
• bidirectional;
• symmetric;
• asymmetric;
• transitive;
• non-transitive.

Where direction is significant, the semantic meaning of the inverse relationship SHALL be explicitly defined rather than inferred.

For example:

Authority
    governs
Registry

is not constitutionally equivalent to:

Registry
    governs
Authority

Similarly:

Schema
    defines
Property

is distinct from:

Property
    belongs to
Schema

Both relationships may coexist, but each possesses its own constitutional identity and semantics.

---

22.11. Foundational Principle

A Constitutional Relationship is the governed Constitutional Object that defines the constitutional connection between two or more Constitutional Objects.

Constitutional Relationships express semantic meaning, structural organisation, governance, dependency, provenance, computation and temporal validity independently of implementation technologies. They are not database references, foreign keys, object pointers or graph edges, although such artefacts may be generated from them.

Every constitutionally significant connection SHALL therefore possess explicit identity, semantics, governance, lifecycle, provenance and validation. By elevating relationships to first-class constitutional assets, ZAYAZ establishes a governed Constitutional Knowledge Graph in which both the entities and the connections between them are equally authoritative, traceable and technology independent.

---

22.11.1 Architectural note

This chapter introduces one of the most important concepts in the entire ZAYAZ Constitution:

Constitutional Objects
        │
        │ represent
        ▼
Things

Constitutional Relationships
        │
        │ represent
        ▼
Meaning Between Things

Together they form the Constitutional Knowledge Graph:

Constitutional Objects
          +
Constitutional Relationships
          =
Constitutional Knowledge Graph

This is more than a modelling convenience—it is the architectural foundation for ZAYAZ's future capabilities. Governance, impact analysis, regulatory traceability, provenance, workflow orchestration, AI reasoning, compiler dependency analysis, and even cross-module navigation can all operate over the same governed graph. Because both nodes (objects) and edges (relationships) are Constitutional Objects, every element of the graph carries identity, authority, lifecycle, provenance and validation, creating a uniquely coherent and fully governed constitutional operating model.

---

Chapter 22 — Constitutional Relationships

Part II — Core Structure

---

22.12. Source Object

The Source Object identifies the Constitutional Object from which a Constitutional Relationship is expressed.

In a directional relationship, the Source Object occupies the originating semantic role.

For example:

Authority
    governs
Registry

The Authority is the Source Object.

The Registry is the Target Object.

The Source Object SHALL be identified by its Constitutional Identifier rather than by an implementation-specific key, name, path or address.

A source declaration SHALL preserve:

• source Constitutional Identifier;
• source object classification;
• source endpoint role;
• applicable source schema;
• applicable source version;
• resolution context where required;
• temporal applicability;
• tenant or deployment context where applicable.

The existence of a Source Object SHALL NOT by itself imply ownership, authority, control or direction. Those meanings arise exclusively from the Relationship Type.

For example:

Dataset
    derived from
Measurement

The Dataset is the Source Object, but it does not own or govern the Measurement.

22.12.1. Source Eligibility

A Relationship Type SHALL define which Constitutional Object types are eligible to occupy its source endpoint.

This eligibility constitutes the relationship domain.

For example:

Relationship Type:
governs

Permitted source classifications:
- Constitutional Authority
- Delegated Authority

HECATE SHALL reject a relationship whose Source Object does not conform to the permitted source domain.

22.12.2. Source Resolution

The Source Object SHALL be resolvable through the Constitutional Resolution Architecture.

Source Identifier
        │
        ▼
CRG
        │
        ▼
CRP
        │
        ▼
Constitutional Registry
        │
        ▼
Source Object

A relationship SHALL NOT become constitutionally active where its Source Object cannot be deterministically resolved.

22.12.3. Source Version

A relationship SHALL distinguish between:

• relationship to an object identity;
• relationship to a specific object version;
• relationship to the currently applicable version;
• relationship to a version selected through CRP.

This distinction is essential for historical reproducibility.

For example, a regulatory mapping may relate to a specific edition of an ESRS requirement rather than to every present and future version of that requirement.

22.12.4. Source Lifecycle

The Source Object's lifecycle SHALL be evaluated independently of the relationship lifecycle.

An active relationship MAY NOT automatically remain valid where its Source Object becomes:

• deprecated;
• superseded;
• retired;
• invalid;
• unavailable.

CRP SHALL determine the effect of source lifecycle changes upon the relationship.

22.12.5. Self-Relationships

A Constitutional Object MAY act as both Source Object and Target Object where the Relationship Type permits a reflexive relationship.

Examples may include:

• equivalent to;
• version of;
• references;
• validates itself under an expressly governed mechanism.

Reflexive relationships SHALL be explicitly permitted. They SHALL NOT be inferred merely because source and target identifiers are equal.

---

22.13. Target Object

The Target Object identifies the Constitutional Object toward which a Constitutional Relationship is expressed.

In a directional relationship, the Target Object occupies the receiving semantic role.

For example:

Schema
    defines
Property

The Schema is the Source Object.

The Property is the Target Object.

The Target Object SHALL be identified by its Constitutional Identifier.

A target declaration SHALL preserve:

• target Constitutional Identifier;
• target object classification;
• target endpoint role;
• applicable target schema;
• applicable target version;
• resolution context where required;
• temporal applicability;
• tenant or deployment context where applicable.

The Target Object SHALL NOT be interpreted as subordinate, contained, dependent or owned unless the Relationship Type explicitly establishes that meaning.

22.13.1. Target Eligibility

A Relationship Type SHALL define which Constitutional Object types are eligible to occupy its target endpoint.

This eligibility constitutes the relationship range.

For example:

Relationship Type:
governs

Permitted target classifications:
- Constitutional Registry
- Constitutional Schema
- Constitutional Policy
- Constitutional Package

HECATE SHALL validate target conformance before the relationship becomes active.

22.13.2. Target Resolution

The Target Object SHALL be resolvable through the Constitutional Resolution Architecture.

A relationship SHALL NOT be constitutionally complete where the Target Object:

• cannot be resolved;
• resolves ambiguously;
• is outside the permitted jurisdiction;
• is outside the permitted tenant boundary;
• violates the declared relationship range.

22.13.3. Target Version

The relationship declaration SHALL specify whether the target is:

• identity-bound;
• version-bound;
• context-resolved;
• latest-compatible;
• historically fixed.

A compiler SHALL preserve this distinction in generated artefacts.

A fixed historical target SHALL NOT be silently replaced by a newer version.

22.13.4. Target Lifecycle

The Target Object's lifecycle MAY affect:

• relationship validity;
• navigability;
• publication;
• compilation;
• runtime enforcement;
• historical interpretation.

Where a target is superseded, the existing relationship SHALL NOT automatically migrate to the successor unless a CRP expressly permits such migration.

22.13.5. External Targets

A Target Object MAY represent an externally governed object where that object has been constitutionally registered or federated.

External targets SHALL preserve:

• external authority;
• external identifier;
• internal Constitutional Identifier;
• federation mapping;
• provenance;
• trust;
• synchronisation state.

A raw URL or unmanaged external identifier SHALL NOT constitute a sufficient constitutional target.

---

22.14. Relationship Type

The Relationship Type defines the canonical semantic meaning of a Constitutional Relationship.

It answers:

What does the connection between the participating Constitutional Objects mean?

Examples include:

• governs;
• owns;
• contains;
• composes;
• references;
• depends upon;
• validates;
• derives from;
• supersedes;
• publishes;
• belongs to.

The Relationship Type SHALL be distinct from the relationship instance.

For example:

Relationship Type:
governs

Relationship Instance:
Constitutional Architecture Council
governs
Schema Registry

The first defines reusable semantics.

The second records a governed constitutional fact.

22.14.1. Relationship Type as Constitutional Object

Every Relationship Type SHALL itself be represented as a specialised Constitutional Object.

A Relationship Type SHALL possess:

• Constitutional Identifier;
• canonical name;
• semantic definition;
• permitted source domains;
• permitted target ranges;
• directionality;
• inverse type where applicable;
• cardinality rules;
• transitivity declaration;
• symmetry declaration;
• reflexivity declaration;
• lifecycle;
• version;
• governing authority;
• provenance;
• validation rules;
• publication profile.

Relationship Types SHALL be governed through a Relationship Type Registry.

22.14.2. Type and Instance Separation

The Constitution SHALL distinguish:

Relationship Type
        │
        │ classifies
        ▼
Constitutional Relationship Instance

A Relationship Type defines reusable semantics.

A relationship instance applies those semantics to specific Constitutional Objects.

Changing the Relationship Type definition MAY affect every relationship instance governed by that type and therefore requires compatibility and impact analysis.

22.14.3. Canonical Semantics

Each Relationship Type SHALL define one canonical meaning.

Relationship Types SHALL NOT be overloaded with unrelated semantics.

For example, contains SHALL NOT be used interchangeably to mean:

• owns;
• displays;
• references;
• groups;
• packages;
• aggregates.

Where meanings differ constitutionally, separate Relationship Types SHALL be created.

22.14.4. Relationship Type Classification

A Relationship Type MAY be classified as:

• structural;
• semantic;
• governance;
• temporal;
• computational;
• provenance;
• validation;
• publication;
• resolution.

Classification assists discovery and policy enforcement but SHALL NOT replace the canonical semantic definition.

22.14.5. Inverse Relationship Type

A directional Relationship Type MAY declare an explicit inverse type.

Examples:

owns
↔
owned by

contains
↔
contained in

governs
↔
governed by

An inverse SHALL preserve the same underlying constitutional fact while expressing it from the opposite endpoint.

An inverse view SHALL NOT automatically create a second independent relationship instance unless required by policy.

22.14.6. Relationship Type Specialisation

Relationship Types MAY specialise broader Relationship Types.

For example:

depends upon
        │
        ├── computationally depends upon
        ├── legally depends upon
        ├── structurally depends upon
        └── evidentially depends upon

Specialised types SHALL preserve the semantics of their parent type while adding governed specificity.

22.14.7. Relationship Type Compatibility

Changes to a Relationship Type SHALL be classified as:

• editorial;
• non-breaking semantic clarification;
• backward compatible;
• conditionally compatible;
• breaking.

A material semantic change SHALL normally require a new Relationship Type version or identity.

---

22.15. Endpoint Roles and Directionality

Every Constitutional Relationship SHALL define the semantic roles occupied by its participating objects.

For binary relationships, these roles are normally:

• source endpoint role;
• target endpoint role.

Endpoint roles SHALL be explicit where the meaning cannot be safely derived from source and target position alone.

For example:

Authority
    delegates to
Role

Possible endpoint roles are:

Source role:
Delegating Authority

Target role:
Delegated Role

22.15.1. Directional Relationships

A directional relationship expresses meaning from one endpoint toward another.

Source
    relationship
Target

Examples:

• Authority governs Registry;
• Schema defines Property;
• Dataset derives from Measurement;
• Report discloses Metric.

Reversing the endpoints changes the semantic statement.

22.15.2. Symmetric Relationships

A symmetric relationship has equivalent meaning in either direction.

Examples may include:

• equivalent to;
• compatible with;
• conflicts with.

Where a relationship is declared symmetric:

A relates to B

implies:

B relates to A

The inverse representation MAY be generated without creating a second authoritative relationship instance.

22.15.3. Asymmetric Relationships

An asymmetric relationship SHALL NOT be true in both directions for the same pair of objects under the same context.

For example:

A supersedes B

precludes:

B supersedes A

for the same effective context.

22.15.4. Antisymmetric Relationships

A Relationship Type MAY be declared antisymmetric.

Where:

A relates to B

and:

B relates to A

are both valid, antisymmetry requires that A and B represent the same constitutional object.

This may be relevant to governed hierarchy relationships.

22.15.5. Reflexive Relationships

A reflexive Relationship Type permits an object to relate to itself.

Reflexivity SHALL be explicitly declared.

Relationship Types SHOULD default to non-reflexive unless self-relationship has a clear constitutional meaning.

22.15.6. Transitive Relationships

A transitive Relationship Type permits relationship inference across a chain.

For example:

A is part of B
B is part of C

may imply:

A is part of C

only where the governing Relationship Type explicitly permits transitivity.

Transitivity SHALL NOT be inferred from linguistic similarity.

22.15.7. Derived Direction

The inverse or transitive view of a relationship SHALL be identified as derived unless separately asserted and governed.

The system SHALL distinguish:

• asserted relationship;
• inverse projection;
• transitive inference;
• computed relationship;
• AI-proposed relationship.

This distinction is essential for auditability.

22.15.8. Multi-Party Relationships

Although many Constitutional Relationships are binary, the model SHALL support relationships involving more than two participants.

Examples include:

• an assurance engagement involving a reporting entity, verifier, reporting period and assurance standard;
• a delegation involving a delegating authority, recipient role, governed scope and effective period;
• a calculation involving a metric, methodology, dataset and computation engine.

A multi-party relationship SHALL define named participant roles.

It SHALL NOT reduce constitutionally significant participants to ungoverned metadata.

A binary projection MAY be generated for implementation purposes, but the canonical multi-party meaning SHALL be preserved.

---

22.16. Cardinality

Cardinality defines the permitted number of Constitutional Objects that may participate in a Relationship Type or occupy a relationship endpoint.

Cardinality SHALL be expressed constitutionally rather than inferred from database constraints.

Typical cardinalities include:

• one-to-one;
• one-to-many;
• many-to-one;
• many-to-many;
• zero-or-one;
• exactly one;
• zero-or-more;
• one-or-more;
• bounded collection.

22.16.1. Source Cardinality

Source Cardinality defines how many source participants may participate in a relationship instance or relationship set.

22.16.2. Target Cardinality

Target Cardinality defines how many target participants may relate to a given source under the applicable context.

For example:

Schema
    defines
Property

may permit:

One Schema
to
One or more Properties

22.16.3. Minimum Cardinality

Minimum Cardinality establishes the least number of relationships required.

A minimum of one may express a constitutional requirement.

For example, an active Constitutional Schema may be required to have at least one governing Authority.

22.16.4. Maximum Cardinality

Maximum Cardinality establishes the largest permitted number of relationships.

For example, a registry may be permitted to have:

• exactly one primary owner;
• multiple stewards;
• multiple publication profiles.

22.16.5. Contextual Cardinality

Cardinality MAY vary according to:

• jurisdiction;
• lifecycle state;
• reporting period;
• tenant;
• white-label deployment;
• regulatory profile;
• object classification.

Contextual cardinality SHALL be resolved through CRP.

22.16.6. Temporal Cardinality

Cardinality SHALL be evaluated within an applicable time interval where relationships possess temporal validity.

For example, an object may have several historical owners but only one active primary owner at a given point in time.

22.16.7. Cardinality Validation

HECATE SHALL validate:

• minimum participation;
• maximum participation;
• endpoint eligibility;
• temporal overlap;
• contextual applicability;
• uniqueness where required.

A compiler MAY generate:

• database uniqueness constraints;
• foreign-key constraints;
• JSON Schema limits;
• GraphQL collection rules;
• RDF or SHACL cardinalities.

Generated constraints SHALL remain implementation projections of constitutional cardinality.

---

22.17. Ownership

Ownership is a governance relationship establishing constitutional responsibility and ultimate accountability for a Constitutional Object.

Ownership SHALL NOT be inferred from:

• database possession;
• repository location;
• file authorship;
• service hosting;
• object creation;
• administrative access;
• technical maintenance.

Ownership exists only where a recognised owns Relationship Type has been constitutionally established.

22.17.1. Ownership Semantics

Ownership MAY establish responsibility for:

• strategic accountability;
• lifecycle decisions;
• approval;
• resource allocation;
• risk acceptance;
• retirement;
• delegation;
• governance escalation.

Ownership SHALL NOT automatically imply unrestricted modification authority.

Modification permissions remain governed separately.

22.17.2. Owner Eligibility

The permitted owner MAY be:

• a Constitutional Authority;
• an organisation;
• a governed organisational unit;
• another eligible Constitutional Object expressly authorised by policy.

A technical service account SHALL NOT become a constitutional owner merely because it administers an implementation.

22.17.3. Primary and Secondary Ownership

Ownership MAY distinguish:

• primary owner;
• co-owner;
• delegated owner;
• custodial owner;
• jurisdictional owner;
• tenant owner.

These roles SHALL have explicit semantics.

22.17.4. Ownership Cardinality

A Constitutional Object SHOULD normally have one identifiable primary owner within a given governance context.

Multiple owners MAY be permitted where:

• joint accountability is intentional;
• responsibilities are divided by jurisdiction;
• responsibilities are divided by scope;
• a white-label deployment requires tenant-specific ownership.

Where multiple owners exist, conflict resolution and decision authority SHALL be governed explicitly.

22.17.5. Ownership Transfer

Ownership transfer SHALL preserve:

• former owner;
• new owner;
• effective date;
• approving authority;
• transfer evidence;
• scope;
• provenance.

Ownership transfer SHALL NOT overwrite historical ownership.

22.17.6. Ownership and Stewardship

Ownership SHALL remain distinct from stewardship.

Owner
    accountable for
Object

Steward
    manages
Object

The owner retains constitutional accountability.

The steward performs delegated operational governance.

---

22.18. Composition

Composition is a strong structural relationship in which a component Constitutional Object forms an integral part of a composite Constitutional Object.

A composed object participates in the constitutional identity or structural completeness of the composite.

Example:

Constitutional Schema
    composed of
Schema Elements

22.18.1. Composition Semantics

Composition normally implies:

• strong structural dependency;
• composite responsibility;
• governed lifecycle coupling;
• exclusive or constrained parentage;
• integral participation.

The exact consequences SHALL be defined by the applicable Relationship Type and CRP.

22.18.2. Composite and Component

The relationship SHALL distinguish:

• Composite Object;
• Component Object.

Composite
    composed of
Component

A component SHALL remain a Constitutional Object where independent identity, governance or provenance is required.

22.18.3. Lifecycle Coupling

Retirement or deletion of a composite MAY affect its components.

The policy SHALL specify whether components are:

• retired with the composite;
• detached;
• transferred;
• archived;
• preserved independently.

Lifecycle effects SHALL NOT be assumed from implementation cascade behaviour.

22.18.4. Exclusive Composition

A composition MAY require that a component belong to only one composite in a given context.

For example, a particular schema element instance may be compositionally owned by one schema version.

Reusable definitions SHOULD normally be referenced rather than multiply composed.

22.18.5. Composition and Identity

A component MAY have:

• independent Constitutional Identity;
• identity scoped to the composite;
• derived identity;
• no separate publication identity.

The applicable Constitutional Schema SHALL define the identity model.

22.18.6. Composition Ordering

A composition MAY be ordered where sequence carries constitutional meaning.

Examples include:

• workflow stages;
• ordered calculation steps;
• report sections;
• precedence chains.

Presentation order alone SHALL NOT be treated as constitutional order.

22.18.. Composition Compilation

Composition MAY compile into:

• embedded JSON objects;
• owned database entities;
• nested GraphQL types;
• document substructures;
• graph edges;
• object containment structures.

The compiler SHALL preserve lifecycle and identity semantics.

---

22.19. Aggregation

Aggregation is a structural relationship in which one Constitutional Object groups or assembles other Constitutional Objects without making them inseparable parts of its identity or lifecycle.

Example:

Constitutional Package
    aggregates
Constitutional Schemas

The aggregated schemas may continue to exist independently of the package.

22.19.1. Aggregation Semantics

Aggregation normally implies:

• non-exclusive participation;
• independent lifecycle;
• independent identity;
• reusable membership;
• weak structural coupling.

22.19.2. Aggregate and Aggregated Object

The relationship distinguishes:

• Aggregate Object;
• Aggregated Object.

The aggregate organises or presents the participating objects but does not automatically own them.

22.19.3. Shared Aggregation

A Constitutional Object MAY participate in multiple aggregates.

For example, one Constitutional Schema may be included in:

• a core constitutional package;
• a CSRD profile package;
• a customer deployment package.

Each aggregation relationship SHALL preserve its own scope and provenance.

22.19.4. Aggregation Lifecycle

Retirement of an aggregate SHALL NOT normally retire its aggregated objects.

Retirement of an aggregated object MAY, however, cause the aggregate to become:

• incomplete;
• degraded;
• invalid;
• historically fixed.

HECATE SHALL evaluate aggregate integrity.

22.19.5. Aggregation and Composition

Composition and aggregation SHALL remain distinct.

Characteristic	Composition	Aggregation
Structural strength	Strong	Weak
Independent lifecycle	Limited or governed	Normally preserved
Exclusive parentage	Often	Normally not
Identity coupling	Possible	Normally absent
Reuse across parents	Constrained	Expected
Parent retirement effect	May affect component	Normally does not retire member

The terms SHALL NOT be used interchangeably.

---

22.20. Association

Association is a general semantic connection between Constitutional Objects where no stronger relationship category—such as ownership, composition, aggregation, containment or dependency—accurately describes the connection.

Examples include:

• Metric associated with Disclosure Requirement;
• Authority associated with Jurisdiction;
• Methodology associated with Scientific Publication.

22.20.1. Association Semantics

Every association SHALL still possess explicit constitutional meaning.

Associated with SHOULD NOT become an unstructured catch-all relationship.

Where a more precise Relationship Type exists, that type SHALL be used.

22.20.2. Qualified Associations

An association MAY be qualified by:

• purpose;
• context;
• relevance;
• jurisdiction;
• temporal validity;
• confidence;
• evidence;
• scope.

22.20.3. Symmetric and Directional Associations

An association MAY be symmetric or directional.

Examples:

Metric
    associated with
Disclosure Requirement

may be directional where the association expresses applicability.

Standard
    compatible with
Standard

may be symmetric.

22.20.4. Association Strength

Associations MAY declare governed strength classifications, such as:

• informational;
• relevant;
• material;
• required;
• preferred;
• weak;
• strong.

Strength SHALL originate from a governed CVP and SHALL NOT be inferred from usage frequency.

22.20.5. Association Use

Associations are particularly useful for:

• discovery;
• semantic navigation;
• recommendation;
• contextual enrichment;
• graph exploration.

They SHOULD NOT substitute for stronger relationships needed for enforcement or lifecycle control.

---

22.21. Reference

Reference is a relationship in which one Constitutional Object identifies or points to another Constitutional Object without implying ownership, composition, lifecycle coupling or semantic equivalence.

Example:

Report Definition
    references
Metric Definition

22.21.1. Reference Semantics

A reference establishes navigable constitutional linkage.

It MAY support:

• lookup;
• reuse;
• citation;
• inclusion by reference;
• cross-registry navigation;
• interoperability.

A reference SHALL NOT automatically imply:

• dependency;
• validation;
• approval;
• ownership;
• containment.

22.21.2 Strong and Weak References

A reference MAY be classified as:

Strong Reference

The target SHALL resolve for the source object to remain constitutionally valid.

Weak Reference

The target enriches or contextualises the source but is not required for validity.

Historical Reference

The target is fixed to a specific historical identity or version.

Contextual Reference

The target is selected through CRP.

External Reference

The target is governed outside the immediate constitutional deployment but represented through federation.

22.21.3. Referential Integrity

HECATE SHALL validate:

• target resolvability;
• target eligibility;
• version compatibility;
• lifecycle compatibility;
• tenant isolation;
• jurisdictional applicability.

22.21.4. Reference Stability

References SHALL use stable Constitutional Identifiers.

Names, URLs, database IDs and file paths MAY be compiler outputs or resolution hints but SHALL NOT serve as the canonical constitutional reference.

22.21.5. Broken References

Where a target cannot be resolved, the reference SHALL be classified according to policy as:

• invalid;
• unresolved;
• temporarily unavailable;
• historically unavailable;
• degraded;
• warning-only.

Broken references SHALL NOT be silently ignored.

---

22.22. Dependency

Dependency is a relationship in which one Constitutional Object requires, relies upon or is materially affected by another Constitutional Object.

Example:

Carbon Calculation
    depends upon
Emission Factor

Dependency differs from reference because it expresses an operational, structural, semantic, legal or computational reliance.

22.22.1. Dependency Classifications

Dependencies MAY include:

• structural dependency;
• semantic dependency;
• computational dependency;
• data dependency;
• governance dependency;
• evidential dependency;
• regulatory dependency;
• publication dependency;
• runtime dependency;
• compilation dependency.

Each dependency classification SHALL have explicit semantics.

22.22.2. Required and Optional Dependencies

A dependency MAY be:

• mandatory;
• conditional;
• optional;
• fallback;
• preferred;
• substitutable.

Optionality SHALL be policy-governed.

22.22.3. Direct and Transitive Dependencies

A direct dependency is explicitly asserted.

A transitive dependency is inferred through a dependency chain where the Relationship Type permits transitivity.

The graph SHALL distinguish direct from transitive dependencies.

22.22.4. Dependency Criticality

A dependency MAY declare criticality such as:

• informational;
• low;
• moderate;
• high;
• critical;
• constitutional.

Criticality values SHALL originate from a CVP.

22.22.5. Dependency Failure

A dependency SHALL define the expected effect of target failure or unavailability.

Possible outcomes include:

• source invalidation;
• degraded operation;
• fallback resolution;
• warning;
• blocked compilation;
• blocked publication;
• historical preservation only.

22.22.6. Circular Dependencies

Circular dependencies SHALL be explicitly governed.

HECATE SHALL detect dependency cycles.

Cycles MAY be:

• prohibited;
• permitted;
• conditionally permitted;
• resolved through fixed-point computation;
• resolved through ordering policy.

A cycle SHALL NOT be accepted merely because the implementation can technically store it.

22.22.7. Dependency Impact Analysis

The Constitutional Knowledge Graph SHALL support traversal from a changed object to all dependent objects.

This enables:

• regulatory change impact;
• schema change impact;
• metric lineage;
• report dependency analysis;
• compilation impact;
• customer deployment impact;
• risk propagation.

22.22.8. Dependency Versioning

A dependency SHALL specify whether it requires:

• an exact version;
• a compatible version range;
• the active version;
• a jurisdiction-specific version;
• a contextually resolved version.

---

22.23. Containment

Containment is a structural relationship in which a containing Constitutional Object establishes a governed boundary within which another Constitutional Object resides, is organised or is scoped.

Example:

Registry
    contains
Registry Entry

Containment SHALL remain distinct from composition.

A contained object may reside within a boundary without necessarily forming an inseparable part of the container's identity.

22.23.1. Containment Semantics

Containment MAY establish:

• scope;
• namespace;
• governance boundary;
• tenant boundary;
• publication boundary;
• security boundary;
• jurisdictional boundary;
• organisational placement.

22.23.2. Container and Contained Object

The relationship distinguishes:

• Container;
• Contained Object.

A contained object MAY retain independent identity and lifecycle.

22.23.3. Exclusive and Shared Containment

Containment MAY be:

• exclusive;
• shared;
• hierarchical;
• virtual;
• contextual.

Exclusive containment permits one active container in a given context.

Shared containment permits participation in multiple containers.

22.23.4. Nested Containment

Containers MAY themselves be contained.

For example:

Component
    contained in
Module

Module
    contained in
Package

Nested containment SHALL support deterministic ancestry resolution.

22.23.5. Containment Cycles

Containment cycles SHOULD normally be prohibited.

A structure in which an object directly or indirectly contains itself is generally constitutionally invalid.

HECATE SHALL detect containment cycles.

22.23.6. Containment and Jurisdiction

Containment MAY determine which policies, authorities or publication rules apply to a contained object.

For example:

Object
    contained in
EU Deployment Context

may make EU-specific CRPs applicable.

Such policy inheritance SHALL be explicit.

22.23.7. Containment and Security

Containment MAY establish tenant or security boundaries.

Cross-boundary relationships SHALL be validated for:

• authorisation;
• data sovereignty;
• confidentiality;
• jurisdiction;
• publication permission.

22.23.8. Containment and Composition

Containment answers:

Within which governed boundary does the object reside?

Composition answers:

Of which larger object is the component an integral structural part?

An object may be contained without being composed.

An object may be composed without its containment context carrying primary constitutional meaning.

---

22.24. Membership

Membership is a relationship in which a Constitutional Object participates in a governed group, set, collection, classification, body or community.

Examples include:

Role
    member of
Authority Body

Schema
    member of
Schema Profile

Metric
    member of
Disclosure Set

Membership SHALL remain distinct from containment and aggregation.

22.24.1. Membership Semantics

Membership MAY establish:

• participation;
• eligibility;
• inclusion;
• classification;
• governance rights;
• obligations;
• access;
• representation.

The effects of membership SHALL be defined by the applicable Relationship Type or policy.

22.24.2. Member and Group

The relationship distinguishes:

• Member Object;
• Group Object.

The group SHALL itself be a Constitutional Object or a constitutionally governed set.

22.24.3. Membership Classifications

Membership MAY be classified as:

• direct;
• inherited;
• delegated;
• appointed;
• elected;
• automatic;
• conditional;
• temporary;
• observer;
• associate;
• full;
• historical.

Classifications SHALL originate from CVP.

22.24.4. Direct and Derived Membership

Direct membership is explicitly asserted.

Derived membership arises through governed rules.

For example:

Role
    member of
Committee

Committee
    member of
Authority Network

may or may not imply that the Role is a member of the Authority Network.

Such inheritance SHALL be explicitly defined.

22.24.5. Membership Period

Membership SHOULD normally define:

• effective-from;
• effective-until;
• appointment date;
• suspension periods;
• termination reason.

Historical membership SHALL be preserved.

22.24.6. Membership Rights and Obligations

Membership MAY activate governed:

• permissions;
• responsibilities;
• voting rights;
• approval rights;
• review duties;
• access rights;
• reporting duties.

Rights and obligations SHALL not be embedded as informal assumptions. They SHALL be linked through explicit Constitutional Relationships or policies.

22.24.7. Membership Cardinality

A group MAY define:

• minimum members;
• maximum members;
• required member classifications;
• quorum rules;
• exclusivity;
• incompatibility rules.

A member MAY participate in multiple groups unless prohibited by policy.

22.24.8. Membership Conflicts

HECATE SHALL detect conflicts such as:

• mutually exclusive memberships;
• prohibited dual roles;
• invalid jurisdictional participation;
• expired appointment;
• insufficient authority;
• separation-of-duties violations.

22.24.9. Membership and Containment

Membership answers:

In which governed group does the object participate?

Containment answers:

Within which governed boundary does the object reside?

A Role may be a member of a committee without being structurally contained by that committee.

22.24.10. Membership and Aggregation

Membership may carry rights, obligations or status.

Aggregation primarily organises objects into a reusable collection.

A relationship SHALL be modelled as Membership where participation has constitutional consequences.

It SHALL be modelled as Aggregation where the purpose is primarily structural grouping.

---

Part II Foundational Rule

The core structure of a Constitutional Relationship SHALL identify its participating Constitutional Objects, their endpoint roles, the applicable Relationship Type, directionality, cardinality and the specific structural or semantic nature of the connection.

Ownership, Composition, Aggregation, Association, Reference, Dependency, Containment and Membership SHALL remain constitutionally distinct. They SHALL NOT be collapsed into a generic link, parent identifier or foreign key merely because an implementation technology represents them similarly.

The meaning of a relationship arises from its governed type and context, not from the physical mechanism used to store or traverse it.

---

Core Relationship Distinctions

Relationship	Primary constitutional meaning	Lifecycle coupling	Independent target identity	Exclusive participation
Ownership	Accountability	Governance-dependent	Yes	Often primary-owner constrained
Composition	Integral structural part	Strong	Sometimes	Often
Aggregation	Reusable grouping	Weak	Yes	No
Association	General semantic connection	None by default	Yes	No
Reference	Identification or navigation	None by default	Yes	No
Dependency	Reliance or requirement	Impact-based	Yes	No
Containment	Governed boundary or scope	Policy-dependent	Usually	Sometimes
Membership	Participation in a group	Membership-period dependent	Yes	Usually no

---

Architectural result

Part II establishes that a Constitutional Relationship is more than:

source_id
relationship_type
target_id

Its canonical structural model is closer to:

Constitutional Relationship
│
├── Constitutional Identity
├── Relationship Type
├── Participants
│   ├── Source Object
│   ├── Source Endpoint Role
│   ├── Target Object
│   └── Target Endpoint Role
├── Directionality
├── Cardinality
├── Structural Semantics
├── Temporal Validity
├── Governance
├── Provenance
├── Evidence
├── Lifecycle
└── Validation

This model gives ZAYAZ a sufficiently expressive foundation for binary and multi-party relationships, historical reproducibility, graph reasoning, deterministic impact analysis and technology-independent compilation. It also prevents the common architectural failure in which ownership, containment, dependency and membership are all reduced to indistinguishable technical references.

---

Chapter 22 — Constitutional Relationships

Part III — Semantic Relationships

Semantic Relationships define the constitutional meaning exchanged between Constitutional Objects.

Unlike structural relationships, which organise objects, Semantic Relationships describe how constitutional knowledge flows through the ecosystem.

---

22.25. Defines

The Defines relationship establishes that one Constitutional Object provides the authoritative definition of another.

Examples:

Constitutional Schema
    defines
Constitutional Property

CKM Concept
    defines
Constitutional Relationship Type

ESRS Standard
    defines
Disclosure Requirement

22.25.1. Semantics

Defines establishes normative meaning.

The defining object becomes the constitutional source of truth for the defined object.

22.25.2. Characteristics

Defines is:

• directional;
• non-symmetric;
• normally non-transitive;
• semantically authoritative.

22.25.3. Constraints

Only authorised Constitutional Objects MAY define other Constitutional Objects.

HECATE SHALL validate that:

• defining object type is permitted;
• target object type is permitted;
• authority exists.

---

22.26. Describes

The Describes relationship establishes that one Constitutional Object provides descriptive information about another without defining its constitutional meaning.

Examples:

Metadata Definition
    describes
Constitutional Property

Documentation
    describes
Schema

Semantics

Describes enriches understanding.

It SHALL NOT redefine the target object.

---

22.27. Represents

Represents establishes that one Constitutional Object acts as the constitutional representation of another concept, entity or abstraction.

Examples:

Registry Entry
    represents
Company

Digital Product Passport
    represents
Physical Product

Characteristics

Representation SHALL preserve:

• identity mapping;
• provenance;
• representation context.

Representation SHALL NOT imply equivalence.

---

22.28. Governs

The Governs relationship establishes constitutional authority.

Examples:

Authority
    governs
Registry

Authority
    governs
Schema

Authority
    governs
Policy

Semantics

Governance establishes constitutional responsibility.

It SHALL NOT imply ownership unless an Ownership relationship also exists.

---

22.29. Uses

Uses establishes that one Constitutional Object intentionally employs another during execution, governance, validation or computation.

Examples:

Calculation
    uses
Emission Factor

Workflow
    uses
Validation Rule

Report
    uses
Template

Uses expresses operational utilisation.

It SHALL NOT imply dependency unless Dependency also exists.

---

22.30. Supplies

Supplies establishes that an object provides governed information to another object.

Examples:

CVP
    supplies
Permitted Values

AVS
    supplies
Evidence

Dataset
    supplies
Input Values

Supply establishes information provision.

Ownership remains unaffected.

---

22.31. Resolves

Resolves establishes constitutional selection.

Examples:

CRP
    resolves
Applicable Schema

CRP
    resolves
Applicable Value Provider

CRP
    resolves
Applicable Version

Resolution SHALL preserve deterministic behaviour.

---

22.32. Validates

Validates establishes constitutional verification.

Examples:

HECATE
    validates
Schema

AVS
    validates
Evidence

Authority
    validates
Publication

Validation SHALL preserve:

• validation context;
• evidence;
• result;
• timestamp;
• validator identity.

---

22.33. Computes

Computes establishes computational derivation.

Examples:

Calculation
    computes
Metric

Bayesian Model
    computes
Probability

Monte Carlo Engine
    computes
Distribution

Computes SHALL preserve:

• methodology;
• computational provenance;
• reproducibility;
• algorithm version.

---

22.34. Publishes

Publishes establishes publication.

Examples:

Report
    publishes
Disclosure

Registry
    publishes
Dataset

API
    publishes
Resource

Publication SHALL distinguish:

• internal publication;
• external publication;
• public publication;
• regulatory publication.

---

22.35. References

References establishes informational linkage.

Unlike Dependency, the referenced object is not necessarily required.

Examples:

Policy
    references
Regulation

Report
    references
Dataset

Reference SHALL preserve stable constitutional identifiers.

---

22.36. Depends Upon

Depends Upon establishes constitutional reliance.

Examples:

Calculation
    depends upon
Dataset

Report
    depends upon
Metrics

Validation
    depends upon
Evidence

Dependency SHALL support impact analysis.

---

22.37. Derived From

Derived From establishes constitutional lineage.

Examples:

Metric
    derived from
Calculation

Report
    derived from
Disclosure Set

Dataset
    derived from
Measurements

Derived From SHALL preserve provenance.

---

22.38. Equivalent To

Equivalent To establishes constitutional equivalence.

Examples:

Customer Schema
    equivalent to
Core Schema

Equivalence SHALL preserve constitutional semantics.

Implementation differences MAY exist.

---

22.39. Compatible With

Compatible With establishes constitutional interoperability.

Examples:

Schema Version 2
    compatible with
Version 1

API
    compatible with
SDK

Compatibility SHALL declare:

• backward compatibility;
• forward compatibility;
• bidirectional compatibility.

---

22.40. Conflicts With

Conflicts With establishes constitutional incompatibility.

Examples:

Policy A
    conflicts with
Policy B

Role
    conflicts with
Role

Membership
    conflicts with
Membership

Conflict SHALL preserve:

• conflict classification;
• severity;
• resolution policy.

---

22.41. Replaces

Replaces establishes direct succession.

Examples:

Schema V3
    replaces
Schema V2

Replacement SHALL preserve historical traceability.

Replacement SHALL NOT overwrite history.

---

22.42. Supersedes

Supersedes establishes constitutional succession while preserving historical validity.

Examples:

Authority Decision
    supersedes
Previous Decision

Standard
    supersedes
Previous Standard

Supersession SHALL preserve:

• predecessor;
• successor;
• effective period;
• rationale;
• authority.

Superseded objects remain constitutionally valid for historical interpretation unless explicitly retired.

---

22.43. Semantic Relationship Registry

All Semantic Relationship Types SHALL be governed through the Constitutional Relationship Registry.

Each Semantic Relationship Type SHALL possess:

• Constitutional Identifier;
• canonical name;
• semantic definition;
• permitted source domains;
• permitted target ranges;
• inverse relationship where applicable;
• transitivity declaration;
• lifecycle;
• version;
• governing authority;
• provenance;
• validation rules.

---

22.44. Semantic Validation

HECATE SHALL validate Semantic Relationships for:

• semantic correctness;
• source eligibility;
• target eligibility;
• relationship type conformance;
• authority;
• lifecycle compatibility;
• version compatibility;
• contextual applicability;
• provenance completeness.

Invalid semantic relationships SHALL NOT become constitutionally active.

---

22.45. Semantic Reasoning

Semantic Relationships SHALL constitute the primary reasoning layer of the Constitutional Knowledge Graph.

Reasoning engines MAY infer:

• lineage;
• governance paths;
• dependency chains;
• impact analysis;
• semantic similarity;
• publication flows;
• validation chains;
• computational lineage.

Only relationships explicitly declared as inferable—such as transitive or equivalent relationships—MAY be used for automatic inference.

---

22.46. Compiler

The Constitutional Compiler MAY transform Semantic Relationships into implementation artefacts including:

• RDF predicates;
• OWL object properties;
• Neo4j relationship types;
• GraphQL edges;
• SQL foreign-key metadata;
• OpenAPI links;
• TypeScript navigation models;
• AI knowledge graph representations.

Generated artefacts SHALL preserve the canonical Constitutional Relationship Type.

---

22.47. Foundational Principle

A Semantic Relationship is a governed Constitutional Relationship that expresses the constitutional meaning exchanged between Constitutional Objects.

Semantic Relationships define how knowledge, governance, validation, computation, publication and provenance flow through the Constitutional Knowledge Graph. They are not merely descriptive verbs or implementation links; they are authoritative constitutional assets with stable identity, explicit semantics, lifecycle, provenance and governance.

Every Semantic Relationship Type SHALL be independently governed, versioned and validated. Together they form the constitutional language of ZAYAZ, enabling deterministic reasoning, graph traversal, AI interpretation, regulatory traceability and technology-independent compilation without ambiguity or loss of meaning.

---

22.47.1. Architectural insight

This part introduces a powerful separation that is rarely found in enterprise architectures:

Constitutional Relationship
        │
        ├── Structural Relationship
        │       (how things are organised)
        │
        └── Semantic Relationship
                (what things mean to one another)

The next parts of the chapter build on this foundation by adding Governance Relationships (who is responsible), Temporal Relationships (when relationships apply), Provenance Relationships (where knowledge comes from), and Computational Relationships (how results are produced). Together, these relationship families transform the Constitutional Knowledge Graph from a static network into a living constitutional model capable of supporting governance, reasoning, AI, impact analysis and compiler generation across the entire ZAYAZ platform.

---