Skip to main content

ZYZ-STD-CORE - Specialised Constitutional Registries

15. Constitutional Metadata Dictionary (CMD)

15.1. Introduction

The Constitutional Metadata Dictionary (CMD) is the authoritative Constitutional Registry governing all metadata used throughout the ZAYAZ constitutional ecosystem.

The CMD establishes the constitutional meaning, identity, structure, constraints and governance of metadata independently of implementation technologies.

Every metadata element used by Constitutional Objects SHALL be defined by the CMD.

By centralising metadata governance, the CMD ensures that all Constitutional Objects describe themselves using a common constitutional vocabulary.


15.2. Purpose

The purpose of the Constitutional Metadata Dictionary is to establish a single constitutional authority for metadata semantics.

The CMD provides:

  • metadata definitions;
  • metadata identity;
  • metadata semantics;
  • metadata classification;
  • metadata constraints;
  • metadata inheritance;
  • metadata relationships;
  • metadata governance;
  • metadata versioning;
  • metadata lifecycle;
  • metadata traceability;
  • metadata interoperability.

The CMD SHALL eliminate ambiguity regarding the interpretation of metadata throughout the constitutional ecosystem.


15.3. Constitutional Principle

Every metadata element having constitutional significance SHALL be defined within the Constitutional Metadata Dictionary.

Constitutional Objects SHALL reference CMD definitions rather than creating implementation-specific metadata.

Metadata SHALL therefore possess constitutional identity independent of schemas, databases, APIs or programming languages.


15.4. Constitutional Position

The CMD provides the metadata vocabulary used throughout the constitutional ecosystem.

Constitutional Object


Metadata Field


Constitutional Metadata Dictionary


Metadata Definition


Metadata Value

The CMD defines metadata.

Constitutional Value Providers define many of the permitted values.


15.5. Constitutional Metadata Definition

Each metadata field SHALL be represented as a Constitutional Metadata Definition.

A Metadata Definition is itself a Constitutional Object.

Every Metadata Definition SHALL possess:

  • constitutional identity;
  • metadata identifier;
  • canonical name;
  • semantic definition;
  • metadata classification;
  • data type;
  • cardinality;
  • value constraints;
  • governance;
  • lifecycle;
  • provenance;
  • relationships.

15.6. Metadata Identity

Every Metadata Definition SHALL possess a globally unique Constitutional Identifier.

Identity SHALL remain stable throughout:

  • implementation changes;
  • schema evolution;
  • storage migration;
  • API redesign;
  • publication changes.

Renaming a metadata field SHALL NOT alter its constitutional identity.


15.7. Metadata Classification

Metadata SHALL be classified according to its constitutional purpose.

Typical classifications include:

Identity Metadata

  • Identifier
  • UUID
  • Namespace
  • Registry

Governance Metadata

  • Authority
  • Steward
  • Owner
  • Approver
  • Reviewer

Lifecycle Metadata

  • Status
  • Version
  • Effective Date
  • Approval Date
  • Publication Date

Structural Metadata

  • Object Type
  • Asset Type
  • Module
  • Component
  • Domain

Semantic Metadata

  • Name
  • Description
  • Definition
  • Context
  • Scope

Relationship Metadata

  • References
  • Dependencies
  • Parent
  • Child
  • Related Object

Validation Metadata

  • Validation Status
  • Integrity
  • Confidence
  • Evidence

Publication Metadata

  • Audience
  • Visibility
  • Publication Profile
  • Language

Additional classifications MAY be introduced through constitutional governance.


15.8. Metadata Domains

Metadata SHALL belong to defined Metadata Domains.

Examples include:

  • Constitutional Identity
  • Governance
  • Lifecycle
  • Semantic Description
  • Relationships
  • Provenance
  • Validation
  • Publication
  • Resolution
  • Security
  • AI
  • Runtime
  • Computation

Metadata Domains provide organisational structure without altering metadata identity.


15.9. Metadata Types

Every Metadata Definition SHALL declare its constitutional data type.

Supported types MAY include:

  • String
  • Boolean
  • Integer
  • Decimal
  • Date
  • DateTime
  • Duration
  • Identifier
  • URI
  • Enumeration
  • Reference
  • Collection
  • Structured Object
  • Expression
  • Formula

Complex metadata SHALL be explicitly defined.


15.10. Cardinality

Every Metadata Definition SHALL specify its permitted cardinality.

Examples include:

  • Mandatory
  • Optional
  • Single Value
  • Multiple Values
  • Exactly One
  • Zero or More
  • One or More

Cardinality SHALL be validated by HECATE.


15.11. Metadata Constraints

Metadata Definitions MAY define constitutional constraints.

Constraints MAY include:

  • required values;
  • permitted values;
  • regular expressions;
  • length limits;
  • numerical ranges;
  • uniqueness;
  • referential integrity;
  • dependency rules;
  • temporal constraints.

Constraint definitions SHALL remain implementation independent.


15.12. Controlled Values

Where metadata values require controlled vocabularies, the CMD SHALL reference Constitutional Value Providers.

Examples include:

  • Lifecycle States
  • Asset Types
  • Authority Types
  • Object Types
  • Relationship Types
  • Publication Profiles

The CMD defines the field.

The CVP defines the permitted values.


15.13. Metadata Relationships

Metadata Definitions MAY reference other Metadata Definitions.

Examples include:

Publication Date

└── depends upon


Publication Status

Effective Date

└── relates to


Lifecycle State

Relationships SHALL remain explicit.


15.14. Metadata Applicability

Every Metadata Definition SHALL declare its applicability.

Applicability MAY specify:

  • Constitutional Object Types;
  • Registry Types;
  • Asset Types;
  • Modules;
  • Components;
  • Jurisdictions;
  • Runtime contexts.

Metadata SHALL NOT be applied outside its declared scope.


15.15. Metadata Inheritance

Metadata MAY be inherited through Constitutional Object relationships.

Inherited metadata SHALL preserve:

  • originating definition;
  • inheritance path;
  • override rules;
  • authority;
  • provenance.

Silent inheritance SHALL NOT occur.


15.16. Metadata Overrides

Overrides SHALL be explicitly governed.

Overrides MAY be permitted for:

  • customer deployments;
  • white-label deployments;
  • localisation;
  • jurisdictional specialisation.

An override SHALL preserve the identity of the originating Metadata Definition.


15.17. Metadata Governance

Every Metadata Definition SHALL identify:

  • governing Constitutional Authority;
  • steward;
  • approving authority;
  • publication authority;
  • retirement authority.

Only authorised governance MAY alter metadata semantics.


15.18. Metadata Lifecycle

Metadata Definitions SHALL participate in constitutional lifecycle management.

Typical lifecycle states include:

  • Draft
  • Proposed
  • Approved
  • Active
  • Deprecated
  • Superseded
  • Archived

Lifecycle values SHALL originate from Constitutional Value Providers.


15.19. Metadata Versioning

Versioning SHALL distinguish between:

  • editorial corrections;
  • documentation improvements;
  • compatible additions;
  • semantic changes;
  • breaking changes.

Metadata identity SHALL remain stable across versions.


15.20. Metadata Provenance

Every Metadata Definition SHALL preserve provenance.

Provenance SHALL include:

  • origin;
  • governing authority;
  • approval history;
  • publication history;
  • migration history;
  • supersession history.

15.21. Metadata Traceability

Traceability SHALL enable determination of:

  • where metadata is used;
  • which Constitutional Objects reference it;
  • which Registry defines it;
  • which versions exist;
  • which validation rules apply.

Complete metadata lineage SHALL be preserved.


15.22. Metadata Resolution

Metadata SHALL be resolved through the Constitutional Resolution Architecture.

Resolution SHALL involve:

Metadata Identifier


CRG


CRP


CMD


Metadata Definition

Consumers SHALL resolve metadata through constitutional identifiers rather than implementation-specific names.


15.23. Metadata Validation

HECATE SHALL validate metadata definitions.

Validation SHALL include:

  • identifier uniqueness;
  • semantic completeness;
  • type consistency;
  • cardinality;
  • constraints;
  • references;
  • lifecycle;
  • governance;
  • provenance.

Invalid Metadata Definitions SHALL NOT become authoritative.


15.24. Metadata Interoperability

Metadata SHALL be implementation independent.

Implementations MAY expose metadata through:

  • JSON Schema;
  • XML Schema;
  • OpenAPI;
  • GraphQL;
  • RDF;
  • SQL;
  • Knowledge Graphs;
  • APIs.

The constitutional semantics SHALL remain invariant.


15.25. Metadata Compilation

The Constitutional Compiler MAY compile Metadata Definitions into:

  • database schemas;
  • API specifications;
  • JSON schemas;
  • GraphQL types;
  • RDF vocabularies;
  • validation rules;
  • documentation;
  • SDKs;
  • AI context packages.

Compiled artefacts SHALL preserve metadata identity and semantics.


15.26. Metadata Publication

Metadata MAY be published for:

  • developers;
  • regulators;
  • customers;
  • white-label platforms;
  • AI systems;
  • public documentation.

Publication SHALL preserve constitutional meaning.


15.27. Metadata Localisation

Metadata labels and descriptions MAY be localised.

Localisation SHALL preserve:

  • metadata identity;
  • semantic definition;
  • governing authority.

Translations SHALL NOT create new Metadata Definitions.


15.28. Metadata Security

Metadata MAY possess access restrictions.

Restrictions MAY apply to:

  • visibility;
  • editing;
  • approval;
  • publication;
  • governance.

Security SHALL NOT alter constitutional semantics.


15.29. Metadata Determinism

Given identical:

  • Metadata Identifier;
  • CMD Version;
  • Resolution Policy;
  • Resolution Context;

resolution SHALL produce an identical Metadata Definition.

Determinism is a constitutional requirement.


15.30. Metadata Technology Independence

The CMD SHALL remain independent of:

  • database technology;
  • programming language;
  • schema language;
  • API style;
  • cloud platform;
  • storage mechanism.

Technology implements metadata.

Technology SHALL NOT define metadata.


15.31. Metadata Conformance

A Metadata Definition conforms where it:

  1. is represented as a Constitutional Object;
  2. possesses stable constitutional identity;
  3. defines explicit semantics;
  4. declares data type and cardinality;
  5. identifies governing authority;
  6. defines applicable constraints;
  7. participates in lifecycle management;
  8. preserves provenance;
  9. supports HECATE validation;
  10. remains implementation independent.

15.32. Relationship to Other Constitutional Components

The Constitutional Metadata Dictionary establishes the common semantic vocabulary used to describe every Constitutional Object.

Its relationship to other constitutional components is as follows:

  • the Constitutional Object System requires Constitutional Objects to use CMD-governed metadata;
  • the Constitutional Knowledge Model provides the semantic concepts that metadata definitions describe;
  • the Constitutional Knowledge Assets use CMD definitions to describe identity, governance, lifecycle, provenance and publication;
  • Constitutional Registries reference CMD definitions for all registry and Registry Entry metadata;
  • the Constitutional Registry Registry uses CMD-governed metadata to describe registries and resolvers;
  • Constitutional Resolution Policies use CMD definitions for policy scope, applicability, precedence and evidence;
  • Constitutional Value Providers define the controlled vocabularies and enumerations referenced by CMD metadata fields;
  • Constitutional Authorities govern ownership, stewardship and approval of Metadata Definitions;
  • Authoritative Validation Sources may validate externally governed metadata values;
  • HECATE validates Metadata Definitions and their use across the constitutional ecosystem;
  • the Constitutional Compiler transforms Metadata Definitions into implementation-specific schemas, APIs, documentation and AI context packages.

The CMD therefore provides the authoritative semantic language through which all constitutional artefacts describe themselves.


15.33. Foundational Principle

The Constitutional Metadata Dictionary is the authoritative Constitutional Registry governing all metadata used throughout the ZAYAZ constitutional ecosystem.

Every constitutionally significant metadata element SHALL be represented as a governed Constitutional Object possessing stable identity, explicit semantics, defined type, cardinality, constraints, governance, provenance and lifecycle.

Constitutional Objects SHALL reference Metadata Definitions rather than implementation-specific field names or schema constructs. Controlled metadata values SHALL be supplied through Constitutional Value Providers, while metadata semantics SHALL remain under the governance of the Constitutional Metadata Dictionary.

By separating metadata semantics from implementation technology and controlled values, the CMD establishes a consistent, technology-independent and evolvable foundation for interoperability, validation, compilation and constitutional governance across the entire platform.


16. Constitutional Authorities (CA)

16.1. Introduction

Constitutional Authorities (CA) are the governed Constitutional Objects that establish who or what possesses recognised constitutional authority within the ZAYAZ ecosystem.

A Constitutional Authority defines the legitimate source of constitutional power for decisions concerning:

  • ownership;
  • stewardship;
  • approval;
  • interpretation;
  • validation;
  • publication;
  • delegation;
  • activation;
  • suspension;
  • supersession;
  • retirement;
  • dispute resolution.

Constitutional Authorities are maintained within the Constitutional Authority Registry.

The Constitutional Authority Registry is a specialised Constitutional Registry governing the identity, classification, mandate, scope, jurisdiction, relationships and lifecycle of all authorities recognised by the constitutional ecosystem.

An authority is not merely a person, organisation or role.

It is the governed constitutional representation of a recognised mandate.


16.2. Purpose

The purpose of Constitutional Authorities is to ensure that every material constitutional action can be traced to an explicitly recognised source of authority.

The CA model provides:

  • authority identity;
  • authority classification;
  • mandate definition;
  • authority scope;
  • jurisdiction;
  • delegated authority;
  • authority precedence;
  • responsibility assignment;
  • approval competence;
  • interpretation competence;
  • publication competence;
  • validation competence;
  • temporal applicability;
  • conflict handling;
  • provenance;
  • traceability.

The CA model prevents constitutional governance from depending upon informal organisational assumptions, application permissions or undocumented approval practices.


16.3. Constitutional Principle

Every material constitutional decision SHALL be attributable to a recognised Constitutional Authority.

A Constitutional Authority SHALL possess:

  • stable constitutional identity;
  • explicit mandate;
  • defined scope;
  • defined jurisdiction;
  • defined competence;
  • governed lifecycle;
  • provenance;
  • traceable relationships.

Authority SHALL NOT be inferred solely from:

  • system access;
  • employment position;
  • technical ownership;
  • repository permissions;
  • database ownership;
  • application roles;
  • operational control.

Technical permission MAY enable an action.

It does not by itself establish constitutional authority.


16.4. Constitutional Position

Constitutional Authorities provide the governance foundation for all constitutional artefacts.

Constitutional Authority

├── governs Constitutional Objects
├── approves Constitutional Knowledge Assets
├── owns Constitutional Registries
├── authorises Constitutional Resolution Policies
├── validates governance competence
└── delegates authority

The authority model applies across:

  • Constitutional Knowledge Assets;
  • Constitutional Registries;
  • Registry Entries;
  • Constitutional Resolution Policies;
  • Metadata Definitions;
  • Value Providers;
  • Validation Sources;
  • compiler outputs;
  • runtime entities;
  • publications.

16.5. Constitutional Authority as a Constitutional Object

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

Accordingly, each authority SHALL possess:

  • Constitutional Identifier;
  • authority type;
  • canonical name;
  • mandate;
  • scope;
  • jurisdiction;
  • competence;
  • governance;
  • lifecycle;
  • provenance;
  • relationships;
  • delegation state;
  • validation status;
  • publication profile.

Authority identity SHALL remain independent of implementation systems and identity providers.


16.6. Constitutional Authority Registry

The Constitutional Authority Registry is the authoritative Constitutional Registry governing all recognised Constitutional Authorities.

It SHALL govern:

  • authority identities;
  • authority classifications;
  • mandates;
  • jurisdiction;
  • competence;
  • delegation;
  • precedence;
  • relationships;
  • lifecycle;
  • provenance;
  • authority evidence.

Every Constitutional Authority used by the constitutional ecosystem SHALL be registered within, or resolvable through, the Constitutional Authority Registry.


16.7. Authority Identity

Every Constitutional Authority SHALL possess a globally unique Constitutional Identifier.

Authority identity SHALL remain stable across:

  • organisational restructuring;
  • personnel changes;
  • technical migrations;
  • identity-provider changes;
  • system replacements;
  • name changes;
  • branding changes;
  • repository changes.

A change in the person occupying a role SHALL NOT necessarily change the identity of the role authority.

A change in the legal entity holding a mandate MAY require a new authority identity, depending upon the constitutional nature of the mandate.


16.8. Authority Types

A Constitutional Authority SHALL declare its authority type.

Typical authority types MAY include:

Institutional Authority

An authority vested in an organisation, institution or legal entity.

Examples include:

  • European Commission;
  • EFRAG;
  • national regulator;
  • standards organisation;
  • Viroway Ltd;
  • customer legal entity.

Role Authority

An authority vested in a defined role rather than a specific individual.

Examples include:

  • Constitutional Architect;
  • Registry Steward;
  • Policy Approver;
  • Data Protection Officer;
  • Validation Authority.

Personal Authority

An authority vested in a specifically identified person.

Personal Authority SHOULD be used only where the mandate legally or constitutionally attaches to the individual.

Collective Authority

An authority vested in a committee, board, council or panel.

Examples include:

  • Architecture Review Board;
  • Governance Council;
  • Validation Committee;
  • Ethics Committee.

Delegated Authority

An authority operating under an explicit delegation from another Constitutional Authority.

External Authority

An authority originating outside the ZAYAZ ecosystem but recognised for constitutional purposes.

Automated Authority

A narrowly scoped authority exercised by a governed automated system.

Automated Authority SHALL NOT be presumed.

It SHALL be explicitly created, bounded and governed.

Additional authority types MAY be introduced through constitutional governance.


16.9. Authority Mandate

Every Constitutional Authority SHALL possess an explicit mandate.

The mandate defines why the authority is constitutionally recognised and what it is empowered to do.

A mandate SHALL define, as applicable:

  • source of authority;
  • purpose;
  • competence;
  • scope;
  • jurisdiction;
  • permitted actions;
  • prohibited actions;
  • delegation rights;
  • escalation requirements;
  • effective period;
  • evidence requirements.

A mandate SHALL be sufficiently precise to determine whether a particular action falls within the authority’s competence.


16.10. Source of Authority

Every Constitutional Authority SHALL declare its Source of Authority.

A Source of Authority MAY include:

  • legislation;
  • regulation;
  • standard;
  • contract;
  • corporate governance instrument;
  • constitutional appointment;
  • board resolution;
  • delegated mandate;
  • approved policy;
  • recognised institutional competence;
  • ZAYAZ constitutional specification.

The Source of Authority SHALL itself be represented by, or reference, a resolvable Constitutional Object where practicable.

An authority without a valid Source of Authority SHALL NOT exercise constitutional power.


16.11. Authority Scope

Every Constitutional Authority SHALL declare its scope.

Scope MAY include:

  • platform-wide authority;
  • module authority;
  • component authority;
  • registry authority;
  • object-type authority;
  • policy authority;
  • metadata authority;
  • validation authority;
  • publication authority;
  • jurisdictional authority;
  • customer authority;
  • white-label authority;
  • temporal authority;
  • reporting-framework authority.

An authority SHALL NOT exercise competence outside its declared scope.


16.12. Module and Component Authority

Authority SHALL preserve both module and component lineage.

An authority assignment MAY apply to:

  • one module;
  • multiple modules;
  • one component;
  • multiple components;
  • a defined component family;
  • the complete platform.

Where component-level authority is assigned, the parent module lineage SHALL remain explicit.

Where module-level authority is assigned, component applicability SHALL be derived only where constitutionally permitted.

Pergamum Pulse and related governance intelligence SHALL be able to determine:

  • which authority governs a module;
  • which authority governs a component;
  • where authority overlaps;
  • where authority is missing;
  • where authority has been delegated.

16.13. Jurisdiction

A Constitutional Authority MAY possess one or more jurisdictions.

Jurisdiction MAY be:

  • legal;
  • regulatory;
  • organisational;
  • geographic;
  • contractual;
  • operational;
  • semantic;
  • technical;
  • publication-specific.

Examples include:

  • European Union;
  • EEA;
  • a specific country;
  • a customer organisation;
  • a regulated reporting entity;
  • a white-label deployment;
  • an internal ZAYAZ governance domain.

Authority jurisdiction SHALL be explicit where it affects applicability or precedence.


16.14. Authority Competence

Competence defines the classes of constitutional action an authority is permitted to perform.

Competence MAY include:

  • create;
  • propose;
  • review;
  • approve;
  • reject;
  • interpret;
  • validate;
  • certify;
  • publish;
  • activate;
  • suspend;
  • withdraw;
  • supersede;
  • archive;
  • delegate;
  • audit;
  • resolve disputes.

Competence SHALL be represented through controlled values governed by a Constitutional Value Provider.

Possession of one competence SHALL NOT imply possession of another.

For example, an authority permitted to review an object SHALL NOT automatically be permitted to approve it.


16.15. Authority Assignments

A Constitutional Authority exercises its constitutional competence through one or more Constitutional Role Assignments.

A Constitutional Authority MAY participate in one or more governance roles.

Typical roles MAY include:

  • Owner;
  • Steward;
  • Custodian;
  • Author;
  • Reviewer;
  • Approver;
  • Publisher;
  • Validator;
  • Interpreter;
  • Auditor;
  • Delegate;
  • Escalation Authority;
  • Retirement Authority.

Roles describe participation in governance.

Competence determines the actions the authority is permitted to perform.

The two concepts SHALL remain distinct.


16.16. Authority Assignment

Authority Assignment establishes the relationship between a Constitutional Authority and a governed Constitutional Object or domain.

An Authority Assignment SHALL define:

  • authority identifier;
  • governed object or scope;
  • assigned role;
  • competence;
  • effective period;
  • jurisdiction;
  • conditions;
  • delegation status;
  • approval status;
  • provenance.

Authority Assignments SHALL be explicit and independently traceable.

An object SHALL NOT be treated as governed merely because an authority appears in descriptive metadata without a valid Authority Assignment.


16.17. Authority Relationship Types

Constitutional Authorities MAY participate in governed relationships.

Typical relationships include:

  • governs;
  • owns;
  • stewards;
  • approves;
  • validates;
  • interprets;
  • delegates-to;
  • delegated-by;
  • supervises;
  • audits;
  • appoints;
  • represents;
  • succeeds;
  • supersedes;
  • escalates-to;
  • recognises;
  • disputes;
  • resolves-for.

Relationship types SHALL originate from a governed Constitutional Value Provider or Relationship Registry.


16.18. Authority Hierarchy

Authorities MAY participate in hierarchical governance structures.

Constitutional Authority

├── Supervisory Authority
│ └── Delegated Authority
│ └── Operational Authority

└── Escalation Authority

A hierarchy SHALL NOT imply unlimited authority inheritance.

Each authority SHALL retain its own:

  • mandate;
  • scope;
  • competence;
  • jurisdiction;
  • lifecycle;
  • evidence.

Authority hierarchy SHALL support governance navigation without replacing explicit delegation or assignment.


16.19. Authority Precedence

Where multiple Constitutional Authorities apply, the applicable precedence SHALL be explicitly governed.

Precedence MAY consider:

  • legal authority;
  • regulatory authority;
  • constitutional authority;
  • jurisdiction;
  • mandate specificity;
  • delegated competence;
  • effective date;
  • object scope;
  • approval status;
  • emergency status.

A more specific authority SHALL NOT override a higher-order legal or regulatory authority unless such specialisation is permitted by the governing framework.

Authority precedence SHALL be deterministic.


16.20. Authority Equality

Two authorities MAY possess equal constitutional rank within a defined scope.

Where authorities have equal precedence, the governance model SHALL define:

  • joint approval;
  • majority decision;
  • unanimous decision;
  • quorum;
  • escalation;
  • tie-breaking;
  • dispute resolution.

Technical execution order SHALL NOT resolve equal-authority conflicts.


16.21. Delegation

A Constitutional Authority MAY delegate some or all of its competence where constitutionally permitted.

Every delegation SHALL be represented as a governed Constitutional Object or Relationship Entity.

A delegation SHALL define:

  • delegating authority;
  • delegated authority;
  • delegated competence;
  • scope;
  • jurisdiction;
  • effective date;
  • expiry date;
  • conditions;
  • restrictions;
  • revocation rights;
  • evidence;
  • approval.

Delegation SHALL NOT transfer authority beyond the delegator’s own competence.


16.22. Subdelegation

Subdelegation MAY be permitted only where explicitly authorised.

Where subdelegation is permitted, the constitutional lineage SHALL preserve:

Originating Authority


Primary Delegation


Delegated Authority


Subdelegation


Subdelegated Authority

The complete delegation chain SHALL remain resolvable and validatable.

A broken or expired delegation chain SHALL invalidate dependent authority actions unless an applicable constitutional rule provides otherwise.


16.23. Delegation Limits

Delegation MAY be restricted by:

  • competence;
  • object type;
  • module;
  • component;
  • registry;
  • jurisdiction;
  • value threshold;
  • risk classification;
  • time period;
  • publication profile;
  • customer;
  • reporting framework;
  • validation level.

Delegation limits SHALL be machine-interpretable where practicable.

A delegate SHALL NOT expand its delegated authority through internal policy or technical configuration.


16.24. Authority Conditions

Authority MAY be conditional.

Conditions MAY include:

  • successful HECATE validation;
  • dual approval;
  • quorum;
  • completion of review;
  • evidence availability;
  • regulatory applicability;
  • customer consent;
  • active certification;
  • absence of conflict of interest;
  • effective lifecycle state;
  • emergency activation.

An action performed without satisfying mandatory conditions SHALL NOT constitute a valid constitutional action.


16.25. Segregation of Duties

The CA model SHOULD support segregation of duties.

Examples include:

  • author SHALL NOT be sole approver;
  • implementer SHALL NOT be sole validator;
  • registry provider SHALL NOT be sole authority auditor;
  • policy drafter SHALL NOT unilaterally activate a high-impact policy;
  • automated authority SHALL NOT approve its own mandate.

Segregation rules SHALL be defined as Constitutional Policies or validation rules.

HECATE SHOULD validate segregation-of-duty requirements before constitutional actions become effective.


16.26. Collective Authorities

A Collective Authority SHALL define its decision model.

The decision model MAY specify:

  • membership;
  • chair;
  • voting rights;
  • quorum;
  • majority threshold;
  • unanimity requirements;
  • abstention rules;
  • conflict-of-interest rules;
  • delegation rights;
  • tie-breaking process;
  • meeting evidence.

Membership changes SHALL NOT alter the identity of the Collective Authority unless the governing mandate itself changes.


16.27. Membership

Where an authority is collective, institutional or role-based, membership or office-holder relationships SHALL be explicit.

Membership SHALL define:

  • member identity;
  • authority relationship;
  • role;
  • effective period;
  • voting status;
  • competence;
  • appointment source;
  • termination reason.

A person’s membership in an authority SHALL NOT imply authority outside the collective mandate.


16.28. Representation

An individual or service MAY act as a representative of a Constitutional Authority.

Representation SHALL be distinct from authority identity.

A Representation Assignment SHALL define:

  • represented authority;
  • representative;
  • permitted actions;
  • authentication requirements;
  • effective period;
  • constraints;
  • evidence;
  • revocation status.

The representative performs an action.

The Constitutional Authority remains the source of constitutional competence.


16.29. Automated Authorities

An automated system MAY be recognised as a Constitutional Authority only within a narrowly defined mandate.

Automated Authority MAY be permitted to:

  • validate;
  • classify;
  • approve low-risk changes;
  • activate pre-approved rules;
  • reject structurally invalid submissions;
  • generate governed evidence;
  • suspend compromised artefacts.

Automated Authority SHALL define:

  • algorithm or service identity;
  • approved version;
  • training or rule basis where relevant;
  • scope;
  • confidence requirements;
  • human escalation;
  • auditability;
  • revocation mechanism;
  • prohibited actions.

An AI system SHALL NOT derive constitutional authority merely from capability or deployment.


16.30. Human Oversight

Authorities involving automated or AI-supported action SHALL define human oversight requirements.

Oversight MAY include:

  • mandatory human approval;
  • post-action review;
  • exception review;
  • confidence thresholds;
  • escalation;
  • sampling;
  • audit;
  • periodic recertification.

Human oversight SHALL be proportionate to:

  • constitutional impact;
  • regulatory relevance;
  • reversibility;
  • uncertainty;
  • affected stakeholders;
  • systemic risk.

16.31. Authority Lifecycle

Every Constitutional Authority SHALL participate in a governed lifecycle.

Typical states MAY include:

  • Proposed;
  • Nominated;
  • Under Review;
  • Approved;
  • Active;
  • Suspended;
  • Restricted;
  • Expired;
  • Revoked;
  • Superseded;
  • Retired;
  • Archived.

Only authorities in constitutionally permitted states SHALL exercise authority.

A suspended authority MAY remain resolvable for historical traceability.


16.32. Authority Activation

An authority SHALL become active only through a governed activation process.

Activation SHALL verify:

  • identity;
  • mandate;
  • Source of Authority;
  • scope;
  • jurisdiction;
  • competence;
  • evidence;
  • required approvals;
  • lifecycle state;
  • conflicts;
  • effective date.

Authority activation SHALL be traceable.

Technical account creation SHALL NOT constitute constitutional activation.


16.33. Authority Suspension

An authority MAY be suspended where:

  • its mandate is under review;
  • required evidence has expired;
  • a security incident has occurred;
  • a conflict of interest exists;
  • the authority has exceeded its competence;
  • the Source of Authority has become invalid;
  • governance investigation is pending.

Suspension SHALL define:

  • reason;
  • effective time;
  • affected scope;
  • temporary replacement;
  • review authority;
  • reinstatement conditions.

Actions performed after suspension SHALL be treated according to the applicable constitutional policy.


16.34. Authority Revocation

Authority revocation permanently removes the competence granted by a mandate or delegation.

Revocation SHALL preserve:

  • historical identity;
  • prior assignments;
  • prior decisions;
  • effective revocation time;
  • revoking authority;
  • reason;
  • evidence;
  • successor authority where applicable.

Revocation SHALL NOT erase prior valid constitutional actions.


16.35. Authority Expiry

An authority or delegation MAY expire automatically.

Expiry SHALL be governed by:

  • explicit expiry date;
  • termination of office;
  • end of contract;
  • completion of mandate;
  • regulatory change;
  • supersession;
  • withdrawal of Source of Authority.

Expired authority SHALL NOT be used for new constitutional actions.


16.36. Authority Succession

Where one authority replaces another, a governed succession relationship SHALL be established.

Succession SHALL define:

  • predecessor;
  • successor;
  • transferred competence;
  • transferred scope;
  • effective date;
  • excluded responsibilities;
  • treatment of pending decisions;
  • archival obligations.

Succession SHALL NOT be inferred solely from organisational naming or personnel replacement.


16.37. Authority Versioning

Authority versioning SHALL distinguish between:

  • editorial changes;
  • metadata changes;
  • office-holder changes;
  • membership changes;
  • mandate clarifications;
  • scope changes;
  • competence changes;
  • jurisdiction changes;
  • delegation changes;
  • breaking governance changes.

A material change to mandate, scope or competence MAY require a new authority version or a new Constitutional Authority identity, depending upon whether constitutional continuity remains valid.


16.38. Temporal Authority

Authority SHALL be evaluated against time.

Temporal authority MAY consider:

  • valid-from date;
  • valid-to date;
  • appointment date;
  • activation date;
  • suspension period;
  • delegation period;
  • revocation time;
  • transaction time;
  • decision time.

A constitutional decision SHALL be validated against the authority state applicable when the decision occurred.

Current authority status SHALL NOT be substituted for historical authority status during audit or reproduction.


16.39. Authority Provenance

Every Constitutional Authority SHALL preserve provenance.

Provenance SHALL include:

  • authority origin;
  • Source of Authority;
  • creation;
  • nomination;
  • appointment;
  • approval;
  • activation;
  • delegation;
  • modification;
  • suspension;
  • revocation;
  • succession;
  • archival.

Authority provenance SHALL be sufficient to establish why the authority was recognised at any relevant point in time.


16.40. Authority Evidence

A Constitutional Authority MAY require supporting evidence.

Evidence MAY include:

  • legislation;
  • regulatory mandate;
  • corporate resolution;
  • appointment instrument;
  • board decision;
  • contract;
  • delegation instrument;
  • certification;
  • role assignment;
  • identity verification;
  • digital signature;
  • meeting record.

Evidence SHALL be referenced through governed identifiers where practicable.

Evidence access MAY be restricted without removing the constitutional fact that the evidence exists.


16.41. Authority Traceability

It SHALL be possible to determine:

  • which authority governed an object;
  • which authority approved a change;
  • which authority activated a policy;
  • which authority published an asset;
  • which authority delegated competence;
  • which representative performed the action;
  • which authority version was applicable;
  • which evidence supported the authority;
  • which module and component were affected;
  • which validation confirmed the action.

Authority lineage SHALL be preserved end to end.


16.42. Authority Resolution

Authorities SHALL be resolved through the Constitutional Resolution Architecture.

Authority Identifier


Constitutional Registry Registry


Constitutional Resolution Policy


Constitutional Authority Registry


Authority Definition


Mandate and Competence Evaluation


HECATE Validation

Consumers SHALL reference authorities through Constitutional Identifiers rather than implementation-specific user IDs, email addresses or role names.


16.43. Authority Validation

HECATE SHALL validate Constitutional Authorities and Authority Assignments.

Validation SHALL include, as applicable:

  • identity;
  • authority type;
  • mandate;
  • Source of Authority;
  • scope;
  • jurisdiction;
  • competence;
  • delegation chain;
  • lifecycle;
  • temporal applicability;
  • evidence;
  • representation;
  • precedence;
  • segregation of duties;
  • conflicts of interest;
  • provenance;
  • integrity.

An authority failing mandatory validation SHALL NOT exercise constitutional competence.


16.44. Decision Validation

A constitutional decision SHALL be validated against the authority applicable to that decision.

Decision validation SHALL determine:

  • whether the authority was active;
  • whether the action was within scope;
  • whether the authority possessed the required competence;
  • whether jurisdiction applied;
  • whether delegation was valid;
  • whether conditions were satisfied;
  • whether required co-authorities participated;
  • whether segregation rules were satisfied;
  • whether the decision evidence is complete.

A technically successful action MAY still be constitutionally invalid.


16.45. Authority Conflicts

An Authority Conflict occurs where two or more authorities assert incompatible competence over the same constitutional matter.

Conflict types MAY include:

  • jurisdiction conflict;
  • mandate conflict;
  • precedence conflict;
  • delegation conflict;
  • temporal conflict;
  • interpretation conflict;
  • approval conflict;
  • role conflict;
  • conflict of interest.

Authority conflicts SHALL NOT be resolved through implementation order or administrative privilege.


16.46. Conflict Resolution

Authority conflicts SHALL be resolved through governed rules.

Permitted mechanisms MAY include:

  • legal precedence;
  • regulatory precedence;
  • mandate specificity;
  • temporal applicability;
  • jurisdictional applicability;
  • designated escalation authority;
  • joint decision;
  • governance review;
  • arbitration;
  • suspension of action.

The conflict and its resolution SHALL remain traceable.


16.47. Conflict of Interest

The CA model SHOULD support conflict-of-interest declarations and controls.

A conflict of interest MAY arise where an authority or representative:

  • benefits from the decision;
  • governs and validates the same matter;
  • approves its own delegation;
  • evaluates its own performance;
  • controls both evidence and approval;
  • represents competing authorities.

Applicable policies SHALL define disclosure, recusal, replacement and escalation requirements.


16.48. Emergency Authority

Emergency Authority MAY be established for exceptional circumstances.

Emergency Authority SHALL be:

  • explicitly defined;
  • narrowly scoped;
  • time-limited;
  • independently auditable;
  • activated through a governed process;
  • subject to post-event review.

Emergency Authority MAY permit actions otherwise unavailable, but SHALL NOT remove traceability, evidence or accountability requirements.


16.49. Authority Assurance Level

A Constitutional Authority MAY possess an Authority Assurance Level.

The assurance level MAY reflect:

  • identity assurance;
  • mandate evidence;
  • certification;
  • appointment verification;
  • signature assurance;
  • system attestation;
  • delegation integrity;
  • governance maturity.

High-impact constitutional actions MAY require minimum Authority Assurance Levels.

Assurance levels SHALL originate from a Constitutional Value Provider.


16.50. Digital Identity and Constitutional Authority

Digital identity supports authentication.

Constitutional Authority supports governance legitimacy.

The two SHALL remain distinct.

Digital Identity

│ proves who or what is acting

Representative or Service

│ acts on behalf of

Constitutional Authority

│ supplies legitimate competence

Constitutional Action

Identity systems MAY include:

  • enterprise identity providers;
  • service identities;
  • digital certificates;
  • decentralised identifiers;
  • government identities;
  • cryptographic keys.

These systems authenticate actors.

They do not independently define constitutional authority.


16.51. Access Control

Access control SHALL be derived from, but SHALL NOT replace, constitutional authority.

Authorisation decisions MAY consider:

  • Authority Assignment;
  • competence;
  • scope;
  • lifecycle;
  • jurisdiction;
  • representation;
  • delegation;
  • assurance level;
  • security classification.

A user MAY have technical access without constitutional competence.

An authority MAY possess constitutional competence while temporarily lacking technical access.

These conditions SHALL be distinguishable.


16.52. White-Label Authorities

White-label deployments MAY define customer-specific authorities.

Customer authorities MAY govern:

  • customer-owned content;
  • internal extensions;
  • local publication;
  • internal workflows;
  • local terminology;
  • customer-specific evidence;
  • customer approvals.

Customer authorities SHALL NOT override:

  • applicable law;
  • regulatory authority;
  • ZAYAZ constitutional invariants;
  • platform security requirements;
  • non-delegated platform governance.

Authority lineage SHALL preserve both customer and platform authority.


16.53. External Authorities

External authorities MAY be recognised within the CA model.

Examples include:

  • regulators;
  • legislators;
  • standards bodies;
  • certification organisations;
  • accredited verifiers;
  • scientific institutions;
  • governmental agencies.

External recognition SHALL define:

  • authority identity;
  • recognised mandate;
  • jurisdiction;
  • source;
  • effective period;
  • trust requirements;
  • update mechanism;
  • validation source.

Recognition of an external authority SHALL NOT imply unrestricted applicability to all constitutional domains.


16.54. Regulatory Authorities

Regulatory Authorities SHALL be represented with sufficient precision to distinguish:

  • issuing authority;
  • supervisory authority;
  • enforcement authority;
  • interpretive authority;
  • delegated national authority;
  • competent authority;
  • accreditation authority.

A regulation and the authority responsible for it SHALL remain separate Constitutional Objects connected through governed relationships.


16.55. Verification and Assurance Authorities

Verification and assurance authorities MAY include:

  • statutory auditors;
  • independent assurance providers;
  • accredited verifiers;
  • certification bodies;
  • technical assessors;
  • internal audit functions.

Their authority SHALL define:

  • assurance scope;
  • assurance standard;
  • accreditation;
  • independence requirements;
  • jurisdiction;
  • permitted opinions;
  • validity period.

Verification output SHALL remain traceable to the authority and mandate under which it was produced.


16.56. Publication Authority

Publication Authority defines competence to release constitutional content to a defined audience.

Publication competence MAY differ for:

  • internal publication;
  • customer publication;
  • regulator publication;
  • verifier publication;
  • public publication;
  • AI publication;
  • white-label publication.

Approval authority and publication authority SHALL remain distinct unless explicitly combined.


16.57. Interpretation Authority

Interpretation Authority defines competence to issue governed interpretations of constitutional knowledge.

Interpretations MAY include:

  • regulatory interpretation;
  • semantic interpretation;
  • implementation guidance;
  • applicability determination;
  • conflict resolution;
  • exception determination.

An interpretation SHALL NOT silently modify the source Constitutional Object.

Interpretations SHALL be represented as separate governed Constitutional Objects linked to the interpreted source.


16.58. Validation Authority

Validation Authority defines competence to determine whether an object, policy, registry or action conforms to applicable constitutional requirements.

Validation Authority MAY be:

  • human;
  • institutional;
  • collective;
  • automated;
  • delegated.

Validation authority SHALL define:

  • validation domain;
  • validator competence;
  • accepted evidence;
  • assurance level;
  • expiry;
  • independence requirements.

HECATE executes validation logic but SHALL NOT be assumed to possess constitutional validation authority unless explicitly designated.


16.59. Approval Authority

Approval Authority defines competence to move an artefact or action into an approved constitutional state.

Approval SHALL specify:

  • approving authority;
  • approved object;
  • approved version;
  • scope;
  • conditions;
  • effective date;
  • evidence;
  • expiry where applicable.

Approval of one version SHALL NOT automatically approve later semantic versions.


16.60. Stewardship Authority

Stewardship Authority governs ongoing maintenance without necessarily possessing approval competence.

A steward MAY be responsible for:

  • quality;
  • completeness;
  • update proposals;
  • issue triage;
  • provenance maintenance;
  • relationship maintenance;
  • lifecycle monitoring;
  • stakeholder coordination.

Stewardship SHALL NOT imply ownership or final approval unless explicitly assigned.


16.61. Ownership Authority

Ownership Authority carries constitutional accountability for a governed domain or artefact.

Ownership MAY include responsibility for:

  • strategic direction;
  • governance model;
  • resource allocation;
  • risk acceptance;
  • escalation;
  • authority delegation;
  • retirement decisions.

Ownership SHALL remain distinct from technical custody and day-to-day stewardship.


16.62. Custodial Authority

Custodial Authority governs the operational care of constitutional artefacts or registry implementations.

Custody MAY include:

  • storage;
  • backup;
  • access management;
  • integrity monitoring;
  • operational availability;
  • migration;
  • recovery.

Custodial Authority SHALL NOT alter constitutional semantics without the required governance authority.


16.63. Authority Publication

Authority definitions MAY be published for:

  • governance participants;
  • developers;
  • auditors;
  • regulators;
  • customers;
  • verifiers;
  • AI systems;
  • public transparency.

Publication profiles MAY expose different metadata subsets.

Restricted evidence MAY remain protected while the authority identity, mandate and status remain discoverable.


16.64. Authority Localisation

Authority names, descriptions and titles MAY be localised.

Localisation SHALL preserve:

  • authority identity;
  • mandate;
  • jurisdiction;
  • competence;
  • source;
  • authority relationships.

Translations SHALL NOT create new authorities.

Official legal names SHOULD be preserved alongside localised display names.


16.65. Authority Security

Authority records SHALL receive security controls proportionate to their constitutional impact.

Controls MAY include:

  • digital signatures;
  • tamper-evident records;
  • multi-party approval;
  • immutable audit;
  • privileged-access monitoring;
  • cryptographic integrity;
  • separation of duties;
  • key rotation;
  • recovery controls.

Compromise of an implementation account SHALL NOT automatically alter the constitutional authority definition.


16.66. Authority Integrity

Authority integrity SHALL protect against:

  • unauthorised mandate changes;
  • forged delegations;
  • expired appointments;
  • hidden revocations;
  • identity substitution;
  • privilege escalation;
  • retroactive modification;
  • broken delegation chains.

Integrity evidence MAY include:

  • signed authority manifests;
  • hash chains;
  • timestamping;
  • approval records;
  • append-only audit events;
  • externally verifiable certificates.

16.67. Deterministic Authority Evaluation

Given identical:

  • authority identifier;
  • authority version;
  • authority state;
  • Source of Authority;
  • Authority Assignment;
  • delegation chain;
  • Resolution Context;
  • applicable policy;
  • evaluation time;

the authority evaluation SHALL produce the same competence determination.

Authority evaluation SHALL NOT depend upon undocumented organisational convention.


16.68. Historical Reproducibility

The CA model SHALL support historical reproduction of governance decisions.

Historical reproduction MAY require:

  • authority version;
  • lifecycle state;
  • mandate version;
  • office-holder or representative;
  • delegation state;
  • Source of Authority;
  • applicable policy;
  • evidence;
  • decision timestamp.

It SHALL be possible to determine whether an authority possessed valid competence at the time of a historical action.


16.69. Authority Compilation

The Constitutional Compiler MAY compile Constitutional Authorities into implementation-specific entities.

Compiled outputs MAY include:

  • access-control policies;
  • approval workflows;
  • responsibility matrices;
  • digital-signature policies;
  • governance dashboards;
  • delegation graphs;
  • escalation routes;
  • audit rules;
  • API authorisation claims;
  • AI governance context;
  • publication manifests.

Compiled entities SHALL preserve:

  • authority identity;
  • authority version;
  • mandate;
  • scope;
  • competence;
  • jurisdiction;
  • lifecycle;
  • delegation lineage;
  • provenance.

Compiled access roles SHALL remain traceable to the Constitutional Authority definitions from which they were generated.


16.70. Authority Monitoring

Operational monitoring SHOULD identify:

  • expired authorities;
  • suspended authorities;
  • invalid delegations;
  • missing authority assignments;
  • authority conflicts;
  • orphaned objects;
  • excessive concentration of authority;
  • segregation-of-duty violations;
  • unverified representatives;
  • high-impact actions;
  • unauthorised overrides.

Monitoring MAY trigger governance review.

Monitoring SHALL NOT autonomously redefine authority.


16.71. Authority Impact Analysis

Changes to authority definitions SHOULD undergo constitutional impact analysis.

Impact analysis SHOULD identify:

  • affected Constitutional Objects;
  • affected registries;
  • affected CKAs;
  • affected CRPs;
  • affected metadata definitions;
  • affected validators;
  • affected compiler outputs;
  • affected modules;
  • affected components;
  • affected customers;
  • affected white-label deployments;
  • affected regulatory processes;
  • affected historical reproducibility.

A change to mandate, competence or precedence SHOULD be treated as high impact.


16.72. Authority Conformance

A Constitutional Authority conforms where it:

  1. is represented as a Constitutional Object;
  2. possesses stable constitutional identity;
  3. declares its authority type;
  4. identifies a valid Source of Authority;
  5. defines explicit mandate;
  6. defines scope and jurisdiction;
  7. declares permitted competence;
  8. participates in governed lifecycle management;
  9. preserves provenance and evidence;
  10. supports delegation and representation where applicable;
  11. supports temporal evaluation;
  12. supports deterministic authority evaluation;
  13. preserves module and component lineage;
  14. supports HECATE validation;
  15. remains independent of implementation-specific permissions.

An action SHALL NOT be considered constitutionally authorised merely because it was technically permitted.


16.73. Relationship to Other Constitutional Components

Constitutional Authorities provide the governance legitimacy through which the constitutional ecosystem operates.

Their relationship to other constitutional components is as follows:

  • the Constitutional Knowledge Model defines the semantic concepts used to describe authority, mandate, competence and governance;
  • the Constitutional Object System defines Constitutional Authorities as specialised Constitutional Objects;
  • the Constitutional Knowledge Base contains the authority definitions and their governance relationships;
  • Constitutional Knowledge Assets identify the authorities responsible for ownership, stewardship, approval, publication and retirement;
  • the Constitutional Registry Registry identifies the Constitutional Authority Registry;
  • Constitutional Resolution Policies govern how authorities and their applicable versions are resolved;
  • Constitutional Registries identify their governing, stewardship and publication authorities;
  • the Constitutional Metadata Dictionary defines authority-related metadata;
  • Constitutional Value Providers supply controlled values for authority types, roles, competence, lifecycle and assurance levels;
  • Authoritative Validation Sources provide external evidence supporting authority recognition;
  • HECATE validates authority identity, mandate, delegation, competence and decision legitimacy;
  • the Constitutional Compiler transforms authority definitions into workflows, access policies, responsibility structures and runtime controls;
  • runtime systems authenticate representatives and execute authority-derived controls without redefining constitutional competence.

Constitutional Authorities therefore establish the explicit governance chain connecting constitutional meaning to legitimate constitutional action.


16.74. Foundational Principle

A Constitutional Authority is the governed Constitutional Object that defines a recognised source of constitutional mandate, competence and accountability.

Every material constitutional action SHALL be attributable to an authority possessing valid identity, mandate, scope, jurisdiction, competence, lifecycle state and provenance.

Constitutional authority SHALL remain distinct from technical access, operational control, identity authentication and organisational convention. Technical systems MAY enforce authority-derived permissions, but SHALL NOT independently create constitutional legitimacy.

Authority may be institutional, role-based, personal, collective, delegated, external or automated, but every form SHALL be explicit, bounded, traceable and validatable.

By governing authority as constitutional data rather than implicit organisational practice, ZAYAZ establishes a deterministic, auditable and federated foundation for ownership, stewardship, approval, interpretation, validation, publication and accountability across the entire constitutional ecosystem.




GitHub RepoRequest for Change (RFC)