Skip to main content

Chapter 22 — Constitutional Relationships

Part VIII — Resolution Relationships​

Resolution Relationships define how Constitutional Objects and Constitutional Relationships are deterministically selected, prioritised, reconciled and applied within a specific Constitutional Context.

Resolution establishes which constitutional knowledge becomes applicable when multiple valid alternatives exist.

Resolution SHALL be deterministic, reproducible, explainable and independently auditable.

Resolution Relationships SHALL themselves be governed Constitutional Relationship Types.

22.126. Resolves To​

The Resolves To relationship establishes that a Constitutional Object or Constitutional Relationship resolves to another Constitutional Object or Constitutional Relationship within a specified Constitutional Context.

Examples:

Customer Profile
        resolves to
Customer Schema V7
Emission Calculation
        resolves to
Emission Factor Dataset
Reporting Context
        resolves to
ESRS Reporting Profile

22.126.1. Semantics​

Resolution establishes constitutional applicability.

Resolution SHALL preserve:

  • determinism;
  • reproducibility;
  • explainability.

22.126.2. Resolution Context​

Every resolution SHALL occur within an explicit Constitutional Context.

Context MAY include:

  • tenant;
  • jurisdiction;
  • reporting framework;
  • reporting period;
  • deployment;
  • language;
  • regulatory version;
  • organisation;
  • product profile;
  • assessment scope.

22.127. Selects​

The Selects relationship establishes that one constitutional alternative has been chosen from a governed set.

Examples:

Schema Registry
        selects
Applicable Schema
CVP
        selects
Enumeration Value

Selection SHALL preserve:

  • candidate set;
  • selection rationale;
  • governing policy.

22.128. Prefers​

Prefers establishes constitutional precedence without excluding alternatives.

Examples:

Organisation Policy
        prefers
ISO Methodology
Jurisdiction
        prefers
National Emission Factors

Preference SHALL remain distinguishable from mandatory resolution.

22.129. Overrides​

Overrides establishes constitutional precedence.

Examples:

Customer Policy

overrides

Default Policy
Tenant Schema

overrides

Core Schema

Override SHALL preserve:

  • authority;
  • scope;
  • justification;
  • effective period.

Overrides SHALL NOT remove historical visibility of overridden constitutional knowledge.

22.130. Falls Back To​

Falls Back To establishes deterministic secondary resolution.

Examples:

Primary Dataset

falls back to

Default Dataset
Customer Profile

falls back to

Global Profile

Fallback SHALL only occur when governing resolution policies permit.

22.131. Matches​

Matches establishes constitutional applicability.

Examples:

Reporting Context

matches

Reporting Profile
Jurisdiction

matches

Applicable Regulation

Matching SHALL preserve:

  • matching criteria;
  • confidence;
  • governing rules.

22.132. Applies To​

Applies To establishes constitutional scope.

Examples:

Validation Rule

applies to

Calculation
Policy

applies to

Registry

Applicability SHALL remain distinct from governance.

22.133. Excludes​

Excludes establishes constitutional inapplicability.

Examples:

Policy

excludes

Supplier Category
Reporting Profile

excludes

Optional Disclosure

Exclusion SHALL preserve rationale.

22.134. Conflicts With​

Conflicts With establishes competing constitutional applicability.

Examples:

Policy A

conflicts with

Policy B
Profile

conflicts with

Profile

Conflict SHALL preserve:

  • conflict type;
  • severity;
  • resolution status.

Conflict SHALL NOT be silently resolved.

22.135. Resolves Conflict​

Resolves Conflict establishes constitutional conflict resolution.

Examples:

CRP

resolves conflict

Policy Conflict
Authority

resolves conflict

Version Conflict

Conflict resolution SHALL preserve:

  • applied policy;
  • authority;
  • decision;
  • rationale;
  • evidence.

22.136. Resolution Chain​

Resolution Relationships SHALL support deterministic resolution chains.

Example:

Request
        │
matches
        ▼
Profile
        │
selects
        ▼
Schema
        │
selects
        ▼
Version
        │
selects
        ▼
Value Provider
        │
selects
        ▼
Metric Definition

Every step SHALL remain explainable.

22.137. Resolution Policies​

Every Resolution Relationship SHALL be governed by one or more Constitutional Resolution Policies (CRPs).

Resolution Policies MAY define:

  • precedence;
  • inheritance;
  • specificity;
  • jurisdiction;
  • authority;
  • effective dates;
  • confidence thresholds;
  • evidence quality;
  • compatibility;
  • fallback order.

Policies SHALL be explicit Constitutional Objects.

22.138. Resolution Strategies​

The Constitution SHALL support multiple deterministic resolution strategies, including:

  • exact match;
  • hierarchical resolution;
  • inheritance resolution;
  • precedence resolution;
  • jurisdictional resolution;
  • temporal resolution;
  • version resolution;
  • profile resolution;
  • policy-driven resolution;
  • weighted resolution.

Each strategy SHALL define its selection criteria, tie-breaking rules and applicability.

22.139. Resolution Provenance​

Every Resolution Relationship SHALL preserve:

  • governing CRP;
  • evaluated candidates;
  • selected candidate;
  • rejected candidates;
  • rationale;
  • authority;
  • evidence;
  • timestamp.

Resolution SHALL therefore be completely explainable.

22.140. Resolution Validation​

HECATE SHALL validate:

  • deterministic outcomes;
  • missing candidates;
  • circular resolution;
  • conflicting precedence;
  • ambiguous matches;
  • invalid overrides;
  • fallback loops;
  • inconsistent policies.

Ambiguous resolution SHALL prevent constitutional activation unless explicitly permitted by policy.

22.141. Resolution Reasoning​

The Constitutional Knowledge Graph SHALL support automated resolution reasoning.

Examples include:

  • applicable schema selection;
  • profile resolution;
  • authority resolution;
  • jurisdiction resolution;
  • version selection;
  • methodology selection;
  • value provider selection;
  • validation rule selection;
  • disclosure resolution.

Derived resolution outcomes SHALL remain distinguishable from explicitly asserted relationships.

22.142. Resolution Compiler​

The Constitutional Compiler MAY generate:

  • rule engines;
  • decision tables;
  • resolution trees;
  • policy evaluators;
  • GraphQL resolvers;
  • API routing logic;
  • validation pipelines;
  • configuration selectors.

Generated implementations SHALL preserve the canonical Constitutional Resolution Relationships and their governing policies.

22.143. Constitutional Resolution Graph​

Resolution Relationships SHALL form a dedicated Resolution Graph within the Constitutional Knowledge Graph.

Conceptually:

Constitutional Context
        │
        ▼
Candidate Set
        │
matches
        ▼
Applicable Objects
        │
prefers
        ▼
Preferred Candidates
        │
overrides
        ▼
Final Candidate
        │
resolves to
        ▼
Applicable Constitutional Object

The Resolution Graph SHALL support complete replay of every constitutional decision.

22.144. Explainable Resolution​

Every constitutional resolution SHALL be explainable.

For any resolved outcome, the Constitutional Knowledge Graph SHALL be capable of identifying:

  • the initiating context;
  • all candidate objects;
  • all evaluated relationships;
  • all governing Resolution Policies;
  • all precedence decisions;
  • all rejected alternatives;
  • the final selected object;
  • the supporting evidence and authority.

Explainability SHALL be machine-readable, human-readable and independently auditable.

22.145. Foundational Principle​

A Resolution Relationship is a governed Constitutional Relationship that determines which Constitutional Objects and Constitutional Relationships become applicable within a defined Constitutional Context.

Resolution Relationships define how constitutional ambiguity is eliminated through explicit policies, deterministic strategies and governed precedence rules. They SHALL preserve every evaluated alternative, every governing policy and every decision taken during the resolution process.

Resolution SHALL never rely on implicit implementation behaviour or hidden application logic. Instead, every constitutional decision SHALL be represented, governed and explainable within the Constitutional Knowledge Graph. By elevating resolution to a first-class constitutional capability, ZAYAZ enables deterministic behaviour, transparent governance, reproducible decision-making, AI explainability and technology-independent execution across all modules and deployments.

22.145.1. Architectural insight​

With Part VIII, the Constitutional Knowledge Graph gains its decision-making dimension. The relationship families now answer a complete set of constitutional questions:

Relationship FamilyConstitutional Question
Core StructureHow is the relationship formed?
Semantic RelationshipsWhat does the relationship mean?
Governance RelationshipsWho is responsible?
Structural RelationshipsHow are objects organised?
Temporal RelationshipsWhen is the relationship applicable?
Provenance RelationshipsWhy should this knowledge be trusted?
Resolution RelationshipsWhich constitutional knowledge applies in this context, and why?

22.145.2. Constitutional Context​

Constitutional Context is a first-class Constitutional Object. Every significant operation in ZAYAZ—validation, computation, publication, governance, temporal evaluation and resolution depends on context. By making context explicit we allow every resolution to reference a stable, versioned, governable object that captures dimensions such as tenant, jurisdiction, reporting framework, reporting period, deployment profile, language, regulatory version and organisational scope. This makes resolution fully replayable, simplify AI reasoning, and provide a single constitutional anchor for deterministic behaviour across the platform.

22.145.3. Operational Constitutional System​

Resolution is what transforms the Constitution from a passive knowledge model into an operational constitutional system.

In ZAYAZ, nothing should simply be "looked up." Everything should be constitutionally resolved.

That means every decision answers questions such as:

  • Which schema applies?
  • Which version is active?
  • Which Value Provider should be used?
  • Which regulation governs?
  • Which methodology has precedence?
  • Which relationship wins when multiple are applicable?
  • Which authority has jurisdiction?
  • Which evidence is authoritative?

This is exactly what CRP (Constitutional Resolution Policies) is envisioned to accomplish.

Excellent. Graph Architecture should formalize how all previous relationship families coexist inside one governed, queryable and implementation-independent Constitutional Knowledge Graph.

This part should avoid defining a particular graph database. Neo4j, RDF stores, relational databases, document stores and search indexes are implementation projections. The Constitution must define the logical graph architecture that all implementations preserve.

The central principle is:

The Constitutional Knowledge Graph is the canonical interconnected model of Constitutional Objects, Constitutional Relationships and Constitutional Contexts.

It is not merely a visualization layer or secondary index. It is the machine-reasonable architecture through which ZAYAZ performs governance, validation, resolution, provenance tracing, temporal reconstruction and impact analysis.

Part IX — Graph Architecture​

Graph Architecture defines the constitutional organization, partitioning, traversal, interpretation and implementation-independent representation of the Constitutional Knowledge Graph.

The Constitutional Knowledge Graph SHALL consist of governed Constitutional Objects connected through governed Constitutional Relationships and interpreted within explicit Constitutional Contexts.

The canonical graph SHALL remain independent of any database, query language, serialization format or vendor technology.

22.146. Constitutional Knowledge Graph​

The Constitutional Knowledge Graph, abbreviated CKG, is the canonical network of constitutional knowledge within ZAYAZ.

Conceptually:

Constitutional Knowledge Graph
│
├── Constitutional Objects
├── Constitutional Relationships
├── Constitutional Contexts
├── Constitutional Assertions
├── Provenance
├── Temporal States
├── Resolution Outcomes
└── Validation States

The CKG SHALL preserve:

  • stable constitutional identity;
  • explicit relationship semantics;
  • object and relationship lifecycle;
  • temporal validity;
  • provenance;
  • governance;
  • resolution context;
  • validation status;
  • implementation lineage.

The CKG SHALL be capable of representing both current and historical constitutional states.

22.146.1. Canonical Status​

The Constitutional Knowledge Graph is the canonical logical model of constitutional interconnectedness.

A graph database SHALL NOT become the canonical constitutional source merely because it stores or indexes the graph.

The authoritative source hierarchy remains governed independently.

Graph implementations SHALL be projections of canonical constitutional definitions.

22.146.2. Constitutional Scope​

The CKG MAY include relationships across:

  • Modules;
  • Components;
  • registries;
  • schemas;
  • properties;
  • metrics;
  • calculations;
  • evidence;
  • authorities;
  • policies;
  • standards;
  • disclosures;
  • reports;
  • products;
  • organisations;
  • supply-chain actors;
  • jurisdictions;
  • assurance engagements;
  • AI agents.

Pergamum Pulse SHALL preserve both Module and Component lineage when ingesting, analysing or projecting Constitutional Relationships.

22.147. Graph Elements​

The Constitutional Knowledge Graph SHALL distinguish at least the following graph elements:

Graph ElementConstitutional Purpose
Constitutional ObjectIdentifiable constitutional entity
Constitutional RelationshipGoverned connection among objects
Constitutional ContextConditions under which knowledge is interpreted
Constitutional AssertionClaim that a relationship or state applies
Evidence ObjectSupport for an assertion
Temporal IntervalTime during which an assertion is applicable
Resolution DecisionDetermination of applicable knowledge
Validation ResultConformance status of graph knowledge

These elements SHALL remain distinguishable even where an implementation stores them using the same technical primitive.

22.148. Constitutional Context​

A Constitutional Context is a first-class Constitutional Object that defines the conditions under which constitutional knowledge is interpreted, validated, resolved or executed.

Examples include:

Tenant Context
2028 ESRS Reporting Context
Norwegian Product Passport Context
Supplier Assurance Context

A Constitutional Context MAY include:

  • tenant;
  • organisation;
  • jurisdiction;
  • regulatory framework;
  • reporting period;
  • fiscal period;
  • deployment;
  • product;
  • facility;
  • language;
  • currency;
  • unit system;
  • methodology;
  • scenario;
  • access profile;
  • assurance level;
  • publication profile;
  • applicable constitutional version.

22.148.1. Context Identity​

Every Constitutional Context SHALL possess:

  • Constitutional Identifier;
  • context type;
  • governing authority;
  • lifecycle;
  • provenance;
  • temporal validity;
  • applicable dimensions;
  • validation status.

Context SHALL NOT be represented solely as an ungoverned parameter map.

22.148.2. Context Composition​

A Constitutional Context MAY be composed from multiple subordinate contexts.

Example:

Disclosure Resolution Context
│
├── Tenant Context
├── Jurisdiction Context
├── Reporting Period Context
├── ESRS Version Context
└── Assurance Context

Context composition SHALL be deterministic.

Conflicting context dimensions SHALL be resolved through Constitutional Resolution Policies.

22.148.3. Context Inheritance​

Contexts MAY inherit from broader contexts.

Example:

Global ZAYAZ Context

↓

European Union Context

↓

Norway Context

↓

Customer Context

Inherited context values MAY be specialised or overridden only where permitted by policy.

22.148.4. Context Fingerprint​

Every resolved Constitutional Context SHOULD possess a deterministic fingerprint.

The fingerprint SHOULD represent the canonicalized set of context dimensions and their applicable versions.

It MAY be used for:

  • cache keys;
  • resolution replay;
  • validation reproducibility;
  • computation reproducibility;
  • audit comparison;
  • AI reasoning traceability.

Equivalent contexts SHALL produce equivalent fingerprints under the same canonicalization policy.

22.149. Constitutional Nodes​

A Constitutional Node is a graph projection of a Constitutional Object.

Nodes SHALL preserve the identity of their underlying Constitutional Objects.

A node MAY represent:

  • a class or type;
  • an instance;
  • a version;
  • an authority;
  • a policy;
  • an evidence item;
  • a temporal interval;
  • a context;
  • a resolution event.

Node labels used by implementations SHALL NOT replace constitutional classification.

For example:

(:Schema)

is an implementation label.

The canonical classification remains the governed Constitutional Object Type represented by the node.

22.150. Constitutional Edges​

A Constitutional Edge is a graph projection of a Constitutional Relationship.

Every edge SHALL preserve:

  • Relationship Identifier;
  • Relationship Type;
  • participating objects;
  • endpoint roles;
  • directionality;
  • cardinality;
  • assertion status;
  • provenance;
  • temporal validity;
  • governance;
  • context;
  • validation state.

An edge SHALL NOT be treated merely as an unqualified connection.

22.150.1. Edge Identity​

Every constitutionally significant edge SHALL possess stable identity.

This permits:

  • edge-level governance;
  • edge-level provenance;
  • edge-level evidence;
  • edge-level lifecycle;
  • edge-level versioning;
  • edge-level validation;
  • relationships to relationships.

Where a graph technology does not support first-class edge identity, the compiler SHALL generate an equivalent reified representation.

22.150.2. Relationships as Graph Subjects​

A Constitutional Relationship MAY itself participate in another Constitutional Relationship.

Example:

Architecture Council
        approves
[Schema A extends Schema B]

In this example, the approval governs the relationship assertion rather than either Schema independently.

The graph architecture SHALL therefore support relationship-level subjects.

22.151. Constitutional Assertions​

A Constitutional Assertion establishes that a Constitutional Relationship or constitutional state is claimed to apply.

Assertions SHALL distinguish the proposition from the relationship type.

Conceptually:

Relationship Type

governs

↓

Assertion

Architecture Council governs Schema Registry

Every assertion SHALL preserve:

  • asserting authority or agent;
  • assertion timestamp;
  • applicable context;
  • validity interval;
  • evidence;
  • provenance;
  • confidence where applicable;
  • validation status;
  • activation status.

22.151.1. Assertion Classifications​

Assertions MAY be classified as:

  • explicit;
  • imported;
  • inferred;
  • computed;
  • resolved;
  • AI-proposed;
  • disputed;
  • historical;
  • future;
  • revoked.

These classifications SHALL remain constitutionally distinct.

22.151.2. Explicit Assertions​

Explicit assertions are directly established by an authorised source.

They SHALL preserve the establishing authority and evidence.

22.151.3. Inferred Assertions​

Inferred assertions are produced through governed reasoning rules.

They SHALL preserve:

  • inference rule;
  • source assertions;
  • reasoning engine version;
  • reasoning timestamp;
  • applicable context.

An inferred assertion SHALL never be indistinguishable from an explicit assertion.

22.151.4. Computed Assertions​

Computed assertions are generated by a governed computation.

They SHALL preserve computational provenance sufficient for reproducibility.

22.151.5. AI-Proposed Assertions​

AI-proposed assertions SHALL remain non-authoritative until validated and activated through governed workflows.

They SHALL preserve:

  • proposing model or agent;
  • model version;
  • prompt or task context where permitted;
  • confidence;
  • supporting evidence;
  • human or automated review outcome.

AI proposal SHALL never equal constitutional truth.

22.152. Hyperedges and N-ary Relationships​

The graph architecture SHALL support relationships involving more than two participants.

Examples include:

  • assurance engagements;
  • delegations;
  • contractual obligations;
  • allocation decisions;
  • multi-input calculations;
  • regulatory applicability;
  • materiality determinations.

Example:

Assurance Engagement
│
├── assured by → Assurance Provider
├── concerns → Sustainability Statement
├── performed for → Reporting Organisation
├── applies standard → Assurance Standard
└── effective during → Assurance Period

The canonical model SHALL preserve the complete n-ary relationship.

Binary edges generated for Neo4j, RDF, GraphQL or relational implementations SHALL be compiler projections.

They SHALL NOT replace the canonical multi-party meaning.

22.153. Graph Layers​

The Constitutional Knowledge Graph SHALL be logically organised into graph layers.

Recommended layers include:

Constitutional Knowledge Graph
│
├── Identity Layer
├── Structural Layer
├── Semantic Layer
├── Governance Layer
├── Temporal Layer
├── Provenance Layer
├── Resolution Layer
├── Validation Layer
├── Operational Projection Layer
└── Intelligence Layer

22.153.1. Identity Layer​

The Identity Layer establishes stable constitutional identity.

It includes:

  • Constitutional Identifiers;
  • aliases;
  • version identities;
  • external identifiers;
  • equivalence mappings;
  • namespace assignments.

22.153.2. Structural Layer​

The Structural Layer represents architectural organisation.

It includes:

  • parentage;
  • composition;
  • aggregation;
  • containment;
  • membership;
  • inheritance;
  • extension;
  • packaging.

22.153.3. Semantic Layer​

The Semantic Layer represents meaning.

It includes:

  • defines;
  • represents;
  • describes;
  • computes;
  • validates;
  • publishes;
  • derives from;
  • compatible with.

22.153.4. Governance Layer​

The Governance Layer represents authority and accountability.

It includes:

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

22.153.5. Temporal Layer​

The Temporal Layer represents chronology and applicability.

It includes:

  • effective during;
  • valid during;
  • succeeds;
  • supersedes;
  • precedes;
  • becomes active;
  • becomes inactive.

22.153.6. Provenance Layer​

The Provenance Layer represents origin, evidence and custody.

It includes:

  • originates from;
  • derived from;
  • supported by;
  • authored by;
  • issued by;
  • imported from;
  • verified by.

22.153.7. Resolution Layer​

The Resolution Layer represents context-specific applicability and selection.

It includes:

  • resolves to;
  • selects;
  • prefers;
  • overrides;
  • falls back to;
  • excludes;
  • resolves conflict.

22.153.8. Validation Layer​

The Validation Layer represents constitutional conformance.

It includes:

  • validation results;
  • violation objects;
  • warning objects;
  • applicable HECATE rules;
  • validation evidence;
  • remediation status.

22.153.9. Intelligence Layer​

The Intelligence Layer MAY include:

  • derived insights;
  • materiality signals;
  • anomaly detections;
  • inferred risks;
  • AI-generated proposals;
  • similarity relationships;
  • graph embeddings;
  • predictive relationships.

Intelligence-layer outputs SHALL remain distinguishable from canonical assertions.

22.154. Graph Views​

A Graph View is a governed projection of the Constitutional Knowledge Graph for a defined purpose.

Examples include:

  • governance view;
  • provenance view;
  • regulatory view;
  • tenant view;
  • materiality view;
  • supply-chain view;
  • Digital Product Passport view;
  • assurance view;
  • computation lineage view;
  • public transparency view.

A Graph View SHALL specify:

  • source graph scope;
  • included object types;
  • included relationship types;
  • applicable context;
  • temporal point or interval;
  • security policy;
  • derivation policy;
  • redaction policy;
  • publication profile.

A Graph View SHALL NOT create a separate constitutional truth.

22.155. Graph Partitions​

The CKG MAY be physically or logically partitioned for scalability, security, sovereignty or operational performance.

Partitioning strategies MAY include:

  • Module partitioning;
  • Component partitioning;
  • tenant partitioning;
  • jurisdiction partitioning;
  • security-domain partitioning;
  • temporal partitioning;
  • registry partitioning;
  • hot and cold storage partitioning.

Partitioning SHALL NOT break constitutional identity or lineage.

22.155.1. Cross-Partition Relationships​

Cross-partition relationships SHALL preserve:

  • endpoint identity;
  • endpoint location;
  • authority;
  • resolution policy;
  • consistency policy;
  • availability status;
  • provenance.

A cross-partition relationship SHALL remain constitutionally valid even where an endpoint is temporarily unavailable.

22.155.2. Module and Component Lineage​

Every graph partition and projection SHOULD preserve both:

  • top-level Module lineage;
  • subordinate Component lineage.

No component-level assertion SHALL become detached from its Module context.

This requirement is particularly important for Pergamum Pulse, architectural impact analysis and white-label deployment lineage.

22.156. Federated Constitutional Graph​

The Constitutional Knowledge Graph MAY federate with external or tenant-controlled graphs.

Federated graphs MAY include:

  • regulatory knowledge graphs;
  • customer knowledge graphs;
  • supplier networks;
  • product passport networks;
  • scientific datasets;
  • public registries;
  • assurance provider graphs.

Federation SHALL preserve constitutional boundaries.

22.156.1. Federated Identity​

Federated objects SHALL be represented using governed identity mappings.

The graph SHALL distinguish:

  • canonical internal identity;
  • external identity;
  • equivalence;
  • representation;
  • proxy;
  • unresolved external reference.

External identifiers SHALL NOT automatically become Constitutional Identifiers.

22.156.2. Federation Trust​

Every federated source SHALL possess a governed trust profile.

The profile MAY include:

  • source authority;
  • authentication method;
  • data quality;
  • update frequency;
  • jurisdiction;
  • licensing;
  • assurance status;
  • historical reliability.

Federated assertions SHALL preserve their source provenance.

22.156.3. Federation Consistency​

Federated graphs MAY operate under:

  • strong consistency;
  • bounded staleness;
  • eventual consistency;
  • snapshot consistency;
  • event-driven synchronization.

The applicable consistency model SHALL be explicit.

Constitutional truth SHALL not depend on an undocumented consistency assumption.

22.157. Graph Namespaces​

Graph Namespaces SHALL prevent identity collision and clarify constitutional scope.

Namespaces MAY correspond to:

  • ZAYAZ Core;
  • Modules;
  • Components;
  • tenants;
  • jurisdictions;
  • standards;
  • regulatory authorities;
  • external providers;
  • white-label deployments.

Every namespace SHALL possess:

  • namespace identifier;
  • governing authority;
  • scope;
  • naming policy;
  • lifecycle;
  • collision policy.

Namespace membership SHALL NOT by itself imply governance or ownership.

22.158. Graph Traversal​

Graph traversal SHALL be governed rather than unrestricted.

Every traversal policy SHOULD define:

  • starting object;
  • permitted Relationship Types;
  • direction;
  • depth;
  • temporal context;
  • resolution context;
  • security context;
  • inference policy;
  • termination conditions;
  • result ordering.

Example:

Metric
    derived from*
Measurement

The asterisk represents governed transitive traversal, not unrestricted recursion.

22.158.1. Traversal Profiles​

Reusable traversal profiles MAY include:

  • governance-chain traversal;
  • provenance-chain traversal;
  • dependency-impact traversal;
  • version-lineage traversal;
  • ownership traversal;
  • evidence-chain traversal;
  • report-to-source traversal;
  • module-to-component traversal.

Traversal Profiles SHOULD be first-class Constitutional Objects.

22.158.2. Traversal Safety​

The graph runtime SHALL protect against:

  • infinite recursion;
  • uncontrolled fan-out;
  • prohibited path exposure;
  • cyclic path amplification;
  • cross-tenant leakage;
  • context loss;
  • temporal inconsistency;
  • inference explosion.

22.159. Graph Paths​

A Constitutional Path is an ordered sequence of Constitutional Objects and Constitutional Relationships.

A path MAY itself be constitutionally significant.

Examples include:

  • authority path;
  • provenance path;
  • dependency path;
  • approval path;
  • regulatory applicability path;
  • computation lineage path.

A significant path SHOULD preserve:

  • path identifier;
  • start object;
  • terminal object;
  • traversed relationships;
  • applicable context;
  • temporal validity;
  • derivation method;
  • validation status.

22.159.1. Path Explainability​

Every path used to support a constitutional decision SHALL be explainable.

The explanation SHALL identify:

  • why each edge was traversed;
  • which policies permitted traversal;
  • which alternatives were excluded;
  • which inferred edges were introduced;
  • which context applied;
  • which temporal state was evaluated.

22.160. Subgraphs​

A Constitutional Subgraph is a governed subset of the CKG.

Subgraphs MAY be created for:

  • tenant isolation;
  • regulatory packages;
  • assurance engagements;
  • reporting periods;
  • product passports;
  • investigations;
  • simulations;
  • public disclosure;
  • AI reasoning tasks.

Each subgraph SHALL preserve lineage to the canonical graph.

22.160.1. Snapshot Subgraphs​

A Snapshot Subgraph represents the graph as resolved at a particular constitutional time and context.

It SHALL preserve:

  • snapshot timestamp;
  • valid-time boundary;
  • transaction-time boundary;
  • context;
  • included versions;
  • resolution outcomes;
  • compiler version;
  • integrity fingerprint.

Snapshots SHALL support regulatory replay and audit reproduction.

22.160.2. Working Subgraphs​

A Working Subgraph MAY contain proposed, draft or unvalidated knowledge.

Working Subgraphs SHALL remain isolated from active constitutional knowledge until approved.

22.161. Graph State​

The graph SHALL distinguish at least the following states:

  • draft;
  • proposed;
  • validated;
  • approved;
  • active;
  • suspended;
  • deprecated;
  • superseded;
  • historical;
  • rejected;
  • revoked.

State MAY apply to:

  • nodes;
  • edges;
  • assertions;
  • contexts;
  • subgraphs;
  • resolution outcomes.

State transitions SHALL be governed and auditable.

22.162. Graph Integrity​

Graph Integrity defines the conditions under which the CKG remains constitutionally coherent.

Integrity rules SHALL include:

  • identifier uniqueness;
  • endpoint existence;
  • type eligibility;
  • domain and range conformance;
  • cardinality;
  • temporal consistency;
  • provenance completeness;
  • governance authority;
  • context validity;
  • lifecycle compatibility;
  • partition consistency;
  • security isolation;
  • resolution determinism.

HECATE SHALL validate Graph Integrity.

22.162.1. Referential Integrity​

Constitutional references SHALL not silently disappear.

Where an endpoint becomes unavailable or inactive, the relationship SHALL transition into an explicit state such as:

  • unresolved;
  • degraded;
  • historical;
  • suspended;
  • invalid.

22.162.2. Semantic Integrity​

A technically valid edge MAY still be constitutionally invalid where its semantics are incorrect.

Graph validation SHALL therefore operate at both:

  • structural integrity level;
  • semantic integrity level.

22.163. Graph Constraints​

Graph Constraints are governed Constitutional Objects defining permissible graph structures.

Constraints MAY include:

  • permitted endpoint types;
  • prohibited relationship combinations;
  • maximum traversal depth;
  • cycle restrictions;
  • mandatory provenance;
  • authority requirements;
  • exclusivity;
  • uniqueness;
  • separation of duties;
  • context requirements.

Constraint implementations MAY be compiled into:

  • SHACL;
  • OWL restrictions;
  • SQL constraints;
  • graph database constraints;
  • JSON Schema;
  • TypeScript validators;
  • HECATE rules.

The implementation SHALL not replace the canonical constraint.

22.164. Cycles​

Cycles SHALL be evaluated according to relationship semantics.

Cycles MAY be:

  • prohibited;
  • permitted;
  • expected;
  • conditionally permitted.

Examples:

RelationshipTypical Cycle Policy
ParentProhibited
CompositionProhibited
SupersedesProhibited
DelegatesUsually prohibited
Depends UponRestricted
Associated WithPermitted
Compatible WithPermitted
Synchronised WithPermitted

HECATE SHALL classify cycles by Relationship Type rather than treating all cycles identically.

22.165. Graph Reasoning​

Graph Reasoning derives constitutional knowledge from governed rules and existing assertions.

Reasoning MAY include:

  • transitive inference;
  • inverse relationship generation;
  • inheritance;
  • classification;
  • temporal reasoning;
  • provenance reasoning;
  • authority propagation;
  • dependency impact;
  • equivalence reasoning;
  • contextual applicability;
  • conflict detection.

Reasoning rules SHALL themselves be Constitutional Objects.

22.165.1. Reasoning Profiles​

Different contexts MAY require different reasoning profiles.

Examples:

  • strict regulatory reasoning;
  • exploratory AI reasoning;
  • assurance reasoning;
  • tenant-specific reasoning;
  • public publication reasoning.

A reasoning profile SHALL define:

  • permitted rules;
  • inference depth;
  • confidence requirements;
  • context;
  • validation requirements;
  • materialization policy.

22.165.2. Open-World and Closed-World Semantics​

The Constitution SHALL explicitly govern whether a graph operation uses:

  • open-world semantics;
  • closed-world semantics;
  • locally closed-world semantics.

The absence of a relationship SHALL not automatically imply that the relationship is false unless the applicable policy declares the relevant scope complete.

This distinction is essential for:

  • regulatory completeness;
  • evidence analysis;
  • supply-chain gaps;
  • AI reasoning;
  • materiality assessments.

22.165.3. Monotonic and Non-Monotonic Reasoning​

The graph architecture MAY support:

  • monotonic reasoning, where new knowledge does not invalidate previous conclusions;
  • non-monotonic reasoning, where new evidence or context may change a conclusion.

Non-monotonic conclusions SHALL preserve the reason for revision and the superseded reasoning outcome.

22.166. Materialized and Virtual Relationships​

A derived relationship MAY be represented as:

  • materialized;
  • virtual;
  • cached;
  • computed on demand.

The representation strategy SHALL NOT change its constitutional classification.

Materialized derived relationships SHALL preserve:

  • derivation rule;
  • source assertions;
  • context;
  • generation time;
  • invalidation policy.

22.167. Graph Query Architecture​

Queries against the CKG SHALL operate through governed query semantics.

A constitutional query SHOULD specify:

  • target graph or view;
  • context;
  • temporal boundary;
  • relationship scope;
  • inference profile;
  • security principal;
  • resolution policy;
  • result provenance requirements.

The same constitutional query SHOULD produce equivalent results across compliant implementations, subject to declared consistency and freshness policies.

22.167.1. Query Explainability​

For constitutionally significant queries, the system SHALL be capable of returning:

  • evaluated graph scope;
  • applicable context;
  • traversed paths;
  • inferred relationships;
  • resolution decisions;
  • excluded knowledge;
  • source provenance;
  • validation warnings.

22.167.2. Query Result Identity​

Query results referencing Constitutional Objects or Relationships SHALL preserve their Constitutional Identifiers.

Temporary database identifiers SHALL not be exposed as canonical identities.

22.168. Security Graph​

Security and access control MAY be represented through a governed Security Graph.

It MAY include:

  • principals;
  • roles;
  • permissions;
  • policies;
  • resources;
  • delegations;
  • restrictions;
  • jurisdictions;
  • data classifications.

Security decisions MAY traverse Governance Relationships but SHALL remain distinct from governance semantics.

22.168.1. Relationship-Level Access Control​

Access policy MAY apply to:

  • nodes;
  • edges;
  • properties;
  • paths;
  • subgraphs;
  • graph views;
  • inferred knowledge;
  • provenance;
  • evidence.

An authorised user may be permitted to view an object while being prohibited from viewing a sensitive relationship attached to it.

22.168.2. Inference Leakage​

The Security Graph SHALL protect against inference leakage.

A user SHALL NOT be permitted to infer restricted constitutional knowledge through:

  • path counts;
  • hidden-node connectivity;
  • graph topology;
  • error messages;
  • aggregate results;
  • AI-generated explanations.

22.169. Multi-Tenant Graph Architecture​

White-label and tenant deployments SHALL preserve constitutional isolation while retaining lineage to ZAYAZ Core.

Conceptually:

ZAYAZ Core Graph
│
├── White-label Base Graph
│   ├── Tenant A Overlay
│   ├── Tenant B Overlay
│   └── Tenant C Overlay

A tenant graph MAY:

  • extend Core objects;
  • specialise permitted concepts;
  • add tenant objects;
  • establish local relationships;
  • override permitted defaults;
  • define local contexts.

It SHALL NOT silently modify canonical Core knowledge.

22.169.1. Tenant Overlays​

Tenant customisation SHOULD be implemented as governed overlays rather than forks.

An overlay SHALL preserve:

  • source Core version;
  • added objects;
  • added relationships;
  • permitted overrides;
  • compatibility status;
  • upgrade impact;
  • provenance.

22.169.2. Cross-Tenant Relationships​

Cross-tenant relationships SHALL be prohibited by default.

Where explicitly permitted, they SHALL require:

  • mutual authority;
  • purpose limitation;
  • data-sharing policy;
  • identity mapping;
  • provenance;
  • temporal validity;
  • revocation capability.

22.170. Graph Versioning​

Graph Versioning SHALL preserve the evolution of:

  • nodes;
  • edges;
  • schemas;
  • constraints;
  • contexts;
  • reasoning rules;
  • resolution policies;
  • graph views.

Graph versioning SHALL support:

  • object-level versions;
  • relationship-level versions;
  • subgraph versions;
  • snapshot versions;
  • release versions.

A graph release SHALL possess a deterministic manifest.

22.170.1. Graph Manifest​

A Graph Manifest SHOULD include:

  • release identifier;
  • included object versions;
  • included relationship versions;
  • applicable constraints;
  • reasoning profile;
  • resolution policy versions;
  • compiler version;
  • integrity fingerprint;
  • release authority;
  • publication time.

22.170.2. Graph Diffs​

The architecture SHALL support semantic graph differences.

A graph diff SHOULD identify:

  • added nodes;
  • removed nodes;
  • modified objects;
  • added relationships;
  • retired relationships;
  • changed semantics;
  • changed governance;
  • changed validity;
  • changed provenance;
  • changed resolution outcomes.

A semantic diff SHALL not be limited to serialized text comparison.

22.171. Graph Events​

Changes to the CKG MAY emit governed Graph Events.

Examples include:

  • ObjectCreated;
  • RelationshipAsserted;
  • RelationshipRevoked;
  • ContextActivated;
  • GovernanceTransferred;
  • VersionSuperseded;
  • ResolutionChanged;
  • ValidationFailed;
  • ProvenanceUpdated.

Every Graph Event SHALL preserve:

  • event identity;
  • actor;
  • authority;
  • event time;
  • affected objects;
  • affected relationships;
  • previous state;
  • resulting state;
  • provenance.

Graph Events MAY support event sourcing but SHALL not themselves replace the canonical graph state.

22.172. Graph Consistency​

The graph architecture SHALL declare applicable consistency guarantees.

Consistency MAY include:

  • constitutional consistency;
  • transactional consistency;
  • referential consistency;
  • temporal consistency;
  • resolution consistency;
  • projection consistency;
  • federation consistency.

A projection MAY be temporarily stale without changing canonical constitutional truth.

The system SHALL expose projection freshness where material.

22.173. Graph Performance and Scale​

Graph architecture SHALL support growth across:

  • billions of assertions;
  • long temporal histories;
  • multi-tenant overlays;
  • supply-chain networks;
  • regulatory knowledge;
  • high-frequency evidence ingestion;
  • AI reasoning workloads.

Performance strategies MAY include:

  • partitioning;
  • adjacency indexes;
  • path indexes;
  • materialized views;
  • temporal indexes;
  • context indexes;
  • provenance compression;
  • graph summaries;
  • relationship-type indexes;
  • vector-assisted retrieval.

Optimisation SHALL not remove canonical semantics or provenance.

22.173.1. Hot and Cold Graph Tiers​

The system MAY distinguish:

  • active operational graph;
  • historical graph;
  • evidential archive;
  • analytical graph;
  • public graph;
  • AI retrieval graph.

Every tier SHALL preserve lineage to canonical knowledge.

22.173.2. Graph Cache​

Cached graph outcomes SHALL include invalidation dependencies.

A cache entry SHOULD be invalidated when relevant:

  • objects change;
  • relationships change;
  • context changes;
  • resolution policies change;
  • temporal boundaries change;
  • reasoning rules change;
  • validation status changes.

22.174. Graph Embeddings and Vector Projections​

The Intelligence Layer MAY generate embeddings or vector representations of graph knowledge.

Embeddings MAY support:

  • semantic discovery;
  • similarity;
  • anomaly detection;
  • AI retrieval;
  • entity resolution;
  • recommendation.

Embeddings SHALL be treated as derived artefacts.

They SHALL preserve lineage to:

  • source graph scope;
  • source versions;
  • embedding model;
  • model version;
  • generation context;
  • timestamp.

Similarity in vector space SHALL NOT establish constitutional equivalence.

22.175. Graph Validation​

HECATE SHALL validate Graph Architecture for:

  • node identity;
  • edge identity;
  • endpoint integrity;
  • relationship semantics;
  • domain and range;
  • cardinality;
  • cycle policy;
  • context completeness;
  • temporal consistency;
  • governance authority;
  • provenance completeness;
  • resolution determinism;
  • tenant isolation;
  • security leakage;
  • projection consistency.

Invalid graph assertions SHALL not become constitutionally active.

22.176. Graph Resolution​

Graph Resolution determines which nodes, edges, assertions and contexts apply to a constitutional operation.

Resolution MAY determine:

  • applicable graph view;
  • active version;
  • active relationship;
  • applicable tenant overlay;
  • jurisdictional subgraph;
  • reasoning profile;
  • temporal snapshot;
  • authoritative provenance source.

CRP SHALL perform Graph Resolution deterministically.

22.177. Graph Provenance​

Every graph projection SHALL preserve provenance sufficient to trace its elements back to canonical sources.

Graph provenance SHALL include:

  • source Constitutional Objects;
  • source Constitutional Relationships;
  • compiler or transformation;
  • projection time;
  • source versions;
  • applicable context;
  • integrity fingerprint.

A projected edge without traceable origin SHALL not be treated as canonical constitutional knowledge.

22.178. Constitutional Graph Compiler​

The Constitutional Graph Compiler SHALL transform the canonical graph model into implementation-specific artefacts.

Compiler targets MAY include:

  • RDF;
  • RDF-star;
  • OWL;
  • SHACL;
  • Neo4j;
  • JanusGraph;
  • Amazon Neptune;
  • SQL adjacency models;
  • document graph projections;
  • GraphQL;
  • OpenAPI;
  • JSON-LD;
  • TypeScript models;
  • search indexes;
  • vector indexes.

The compiler SHALL preserve:

  • Constitutional Identifiers;
  • Relationship Types;
  • endpoint roles;
  • n-ary semantics;
  • context;
  • temporal validity;
  • provenance;
  • governance;
  • validation status.

22.178.1. Projection Profiles​

Each compiler target SHALL use a governed Projection Profile.

A Projection Profile SHALL define:

  • target technology;
  • node mapping;
  • edge mapping;
  • reification strategy;
  • identifier mapping;
  • datatype mapping;
  • temporal mapping;
  • provenance mapping;
  • constraint mapping;
  • unsupported-feature handling.

22.178.2. Loss Analysis​

Every projection SHOULD generate a loss analysis.

The analysis SHALL identify:

  • fully preserved semantics;
  • approximated semantics;
  • omitted semantics;
  • reified relationships;
  • unsupported constraints;
  • external enforcement requirements.

A lossy projection SHALL not be presented as a complete constitutional representation.

22.178.3. Round-Trip Integrity​

Where a projection supports bidirectional transformation, the compiler SHOULD test round-trip integrity.

Conceptually:

Canonical Graph

↓

Implementation Projection

↓

Reconstructed Canonical Graph

Material semantic differences SHALL be reported.

22.179. Graph APIs​

Graph APIs SHALL expose constitutional semantics rather than raw database topology.

An API MAY provide:

  • object retrieval;
  • relationship retrieval;
  • context resolution;
  • path traversal;
  • provenance tracing;
  • temporal reconstruction;
  • impact analysis;
  • graph diff;
  • validation;
  • explanation.

APIs SHALL preserve stable identifiers and applicable context.

22.180. Graph Observability​

The graph runtime SHALL provide observability across:

  • ingestion;
  • assertion activation;
  • validation;
  • resolution;
  • traversal;
  • reasoning;
  • federation;
  • projection;
  • cache behaviour;
  • compiler output.

Observability SHOULD include:

  • graph size;
  • relationship counts;
  • invalid assertions;
  • unresolved references;
  • orphaned objects;
  • cycle violations;
  • stale projections;
  • resolution ambiguity;
  • provenance gaps;
  • reasoning latency;
  • traversal cost.

Operational metrics SHALL not redefine constitutional meaning.

22.181. Graph Impact Analysis​

The CKG SHALL support deterministic impact analysis.

Impact analysis MAY evaluate:

  • downstream dependencies;
  • affected reports;
  • affected disclosures;
  • affected calculations;
  • affected schemas;
  • affected tenants;
  • affected jurisdictions;
  • affected APIs;
  • affected AI agents;
  • affected governance authorities.

Example:

Regulatory Requirement changes
        │
        ▼
Disclosure Requirements
        │
        ▼
Schemas and Properties
        │
        ▼
Calculations and Metrics
        │
        ▼
Reports and Publications

Impact results SHALL preserve traversed paths and applicable context.

22.182. Constitutional Graph Digital Twin​

The CKG MAY operate as a constitutional digital twin of the ZAYAZ platform.

The graph may represent:

  • intended architecture;
  • implemented architecture;
  • deployed architecture;
  • observed runtime architecture;
  • governed architecture.

Differences among these states SHALL be explicitly represented.

Example:

Constitutional Design
        compared with
Implemented System
        compared with
Observed Runtime

This enables architectural drift detection.

22.183. Pergamum Pulse Integration​

Pergamum Pulse SHOULD consume the CKG as a lineage-preserving intelligence source.

It SHALL preserve:

  • Module lineage;
  • Component lineage;
  • relationship family;
  • constitutional identity;
  • source provenance;
  • context;
  • temporal validity;
  • assertion classification.

Pergamum Pulse MAY derive:

  • architectural health signals;
  • governance gaps;
  • provenance gaps;
  • dependency concentration;
  • orphaned components;
  • ungoverned relationships;
  • cross-module coupling;
  • constitutional drift.

Pulse-derived findings SHALL remain Intelligence Layer assertions until governed activation.

22.184. Foundational Principle​

The Constitutional Knowledge Graph is the canonical, implementation-independent architecture of interconnected constitutional knowledge within ZAYAZ.

It consists of Constitutional Objects, Constitutional Relationships, Constitutional Contexts and governed assertions whose identity, semantics, lifecycle, provenance, temporal validity, governance and validation are explicitly preserved.

The graph SHALL not be reduced to nodes and edges without constitutional meaning. Every graph element SHALL remain traceable to its governing definitions and authoritative sources. Database schemas, RDF triples, property graphs, GraphQL models, search indexes and vector representations are compiler-generated projections of the canonical graph and SHALL never silently redefine it.

By establishing Graph Architecture as a constitutional capability, ZAYAZ gains a unified foundation for governance traversal, temporal reconstruction, provenance tracing, deterministic resolution, regulatory impact analysis, AI reasoning, white-label overlays and cross-platform interoperability.

22.184.1. Architectural synthesis​

Part IX unifies the preceding relationship families into one constitutional operating model:

                         Constitutional Context
                                  │
                                  ▼
Constitutional Object ── Constitutional Relationship ── Constitutional Object
                                  │
          ┌───────────────────────┼────────────────────────┐
          │                       │                        │
       Temporal               Provenance              Governance
          │                       │                        │
          └───────────────────────┼────────────────────────┘
                                  │
                              Resolution
                                  │
                              Validation
                                  │
                           Compiler Projections

The complete architecture now answers:

Constitutional DimensionQuestion
Core StructureHow is the relationship formed?
SemanticsWhat does it mean?
GovernanceWho is responsible?
StructureHow are objects organised?
TimeWhen does it apply?
ProvenanceWhere did it come from, and why is it trusted?
ResolutionWhich knowledge applies in this context?
Graph ArchitectureHow is all constitutional knowledge interconnected, queried and projected?

Constitutional Context as a first-class object.

Context now becomes the common execution frame for resolution, validation, reasoning, traversal, computation and publication. That gives ZAYAZ deterministic replay across tenants, jurisdictions, reporting periods, regulatory versions and white-label deployments while preserving one coherent constitutional foundation.



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