Skip to main content

Constitutional Value Providers

18. Constitutional Value Providers (CVP)​

18.1. Introduction​

Constitutional Value Providers (CVP) are the governed constitutional mechanisms through which controlled, authoritative and contextually valid values are supplied to Constitutional Metadata Definitions, Constitutional Objects, policies, registries, workflows and runtime systems.

A Constitutional Value Provider defines where permitted values originate, how they are governed, under which conditions they apply and how they are resolved.

The CVP architecture separates:

  • metadata meaning;
  • permitted values;
  • value authority;
  • value resolution;
  • implementation storage.

The Constitutional Metadata Dictionary defines a metadata field.

The Constitutional Value Provider supplies or resolves the values that may be used for that field.

For example:

Metadata Definition:
    lifecycleStatus

Constitutional Value Provider:
    Constitutional Lifecycle State Provider

Permitted values:
    Draft
    Proposed
    Approved
    Active
    Deprecated
    Superseded
    Retired
    Archived

A CVP is not merely:

  • an enumeration;
  • a database table;
  • a dropdown list;
  • an API endpoint;
  • a code list;
  • a lookup file;
  • a validation array;
  • a user-interface control.

Those may be implementation representations of a CVP.

The CVP itself is the governed constitutional source through which values become recognised, resolvable and valid.

18.2. Purpose​

The purpose of Constitutional Value Providers is to establish a consistent, traceable and authoritative mechanism for supplying values used throughout the ZAYAZ constitutional ecosystem.

The CVP architecture provides:

  • value authority;
  • controlled vocabularies;
  • value identity;
  • value-set governance;
  • applicability;
  • jurisdictional specialisation;
  • temporal validity;
  • multilingual representation;
  • external value integration;
  • value mapping;
  • validation;
  • versioning;
  • provenance;
  • traceability;
  • deterministic resolution.

CVPs prevent Constitutional Objects from relying on undocumented literals, implementation-specific enumerations or ungoverned external code lists.

18.3. Constitutional Principle​

Every controlled value having constitutional significance SHALL originate from, or be validated through, a recognised Constitutional Value Provider.

Constitutional Objects SHALL NOT independently define controlled values where an authoritative CVP exists.

Values SHALL remain distinguishable from:

  • metadata definitions;
  • value representations;
  • value labels;
  • value sources;
  • provider implementations;
  • validation logic.

A value MAY have multiple representations.

It SHALL have one stable constitutional identity within its governed value domain.

18.4. Constitutional Position​

The CVP operates between metadata semantics and value usage.

Constitutional Metadata Dictionary
        │
        │ defines metadata semantics
        ▼
Metadata Definition
        │
        │ references
        ▼
Constitutional Value Provider
        │
        │ supplies or resolves
        ▼
Constitutional Value
        │
        │ used by
        ▼
Constitutional Object

The complete resolution chain may be represented as:

Value Requirement
        │
        ▼
Metadata Definition
        │
        ▼
CVP Identifier
        │
        ▼
CRG
        │
        ▼
CRP
        │
        ▼
Constitutional Value Provider
        │
        ▼
Value Set or Resolution Source
        │
        ▼
Constitutional Value
        │
        ▼
HECATE Validation

18.5. Constitutional Value Provider as a Constitutional Object​

Every Constitutional Value Provider SHALL be represented as a specialised Constitutional Object.

Each CVP SHALL possess:

  • Constitutional Identifier;
  • canonical name;
  • semantic definition;
  • provider classification;
  • governed value domain;
  • governing authority;
  • source authority;
  • applicability;
  • jurisdiction;
  • lifecycle;
  • version;
  • provenance;
  • relationships;
  • resolution behaviour;
  • validation requirements;
  • publication profile.

A CVP SHALL remain identifiable independently of its storage mechanism or service implementation.

18.6. Constitutional Value Provider Registry​

Constitutional Value Providers SHALL be governed through a specialised Constitutional Registry.

The Constitutional Value Provider Registry SHALL govern:

  • CVP identities;
  • provider classifications;
  • value domains;
  • provider authority;
  • provider relationships;
  • resolution endpoints;
  • source references;
  • lifecycle;
  • provenance;
  • versioning;
  • validation status.

Every CVP referenced by the constitutional ecosystem SHALL be defined within, or resolvable through, the Constitutional Value Provider Registry.

18.7. Constitutional Value​

A Constitutional Value is a governed value recognised for use within a defined constitutional context.

A Constitutional Value MAY represent:

  • a lifecycle state;
  • an authority type;
  • a role classification;
  • a jurisdiction;
  • a country;
  • a unit;
  • a currency;
  • a language;
  • a reporting standard;
  • a metric type;
  • a validation state;
  • an assurance level;
  • a relationship type;
  • an approval level;
  • an asset classification;
  • a disclosure category;
  • a calculation method;
  • a regulatory status.

A Constitutional Value SHALL possess sufficient identity and provenance to distinguish it from a mere literal.

18.8. Value Identity​

Every constitutionally significant value SHALL possess stable identity.

Value identity SHALL remain independent of:

  • display label;
  • translation;
  • abbreviation;
  • code representation;
  • API representation;
  • database key;
  • source-system identifier;
  • white-label presentation.

For example:

Constitutional Value:
    Active

Possible representations:
    active
    ACTIVE
    Actif
    Aktiv
    1
    lifecycle.active

These representations SHALL NOT create separate constitutional values unless their semantics differ.

18.9. Value Literal and Constitutional Value​

A value literal is a representation.

A Constitutional Value is a governed semantic object.

Literal:
    "active"

Constitutional Value:
    lifecycle-state:active

The literal MAY change.

The Constitutional Value identity SHALL remain stable.

Where literals are used in implementations, they SHALL remain traceable to the Constitutional Value from which they were compiled.

18.10. Value Domain​

Every CVP SHALL govern a defined Value Domain.

A Value Domain describes the semantic area within which the provider supplies valid values.

Examples include:

  • lifecycle states;
  • authority types;
  • role classifications;
  • approval levels;
  • assurance levels;
  • countries;
  • languages;
  • currencies;
  • units;
  • reporting frameworks;
  • relationship types;
  • metadata types;
  • publication profiles;
  • confidentiality classifications;
  • validation outcomes;
  • evidence types.

A CVP SHALL NOT supply values outside its declared Value Domain unless explicitly authorised.

18.11. Value Set​

A Value Set is a governed collection of Constitutional Values intended for a defined use.

A Value Set SHALL define:

  • identity;
  • name;
  • semantic purpose;
  • included values;
  • ordering where relevant;
  • applicability;
  • exclusions;
  • governance;
  • version;
  • lifecycle;
  • provenance.

A CVP MAY provide one or more Value Sets.

For example:

Constitutional Value Provider:
    Governance State Provider

Value Sets:
    Constitutional Object Lifecycle States
    Authority Lifecycle States
    Assignment Lifecycle States

18.12. Closed and Open Value Sets​

Value Sets MAY be classified as closed or open.

Closed Value Set

A Closed Value Set permits only explicitly defined values.

Examples include:

  • lifecycle states;
  • validation outcomes;
  • role classifications;
  • approval levels.

Values outside the set SHALL be invalid unless a governed extension exists.

Open Value Set

An Open Value Set permits additional values subject to declared governance rules.

Examples MAY include:

  • external organisations;
  • product identifiers;
  • supplier identifiers;
  • scientific references.

Open Value Sets SHALL still define:

  • namespace requirements;
  • authority requirements;
  • validation requirements;
  • provenance requirements;
  • extension rules.

Open SHALL NOT mean ungoverned.

18.13. Static and Dynamic Value Providers​

A CVP MAY be static or dynamic.

Static Value Provider

A Static Value Provider supplies a governed set of values published as a controlled version.

Examples include:

  • lifecycle states;
  • role categories;
  • evidence types;
  • assurance levels.

Dynamic Value Provider

A Dynamic Value Provider resolves values from a governed source whose contents may evolve independently.

Examples include:

  • current countries;
  • regulatory authorities;
  • currency codes;
  • emission factors;
  • market classifications;
  • active standards;
  • supplier registries.

Dynamic providers SHALL preserve reproducibility through:

  • effective dates;
  • snapshots;
  • source versions;
  • retrieval evidence;
  • temporal identifiers.

18.14. Internal and External Value Providers​

CVPs MAY be internally or externally sourced.

Internal CVP

An Internal CVP is constitutionally governed within ZAYAZ.

Examples include:

  • Constitutional Lifecycle State Provider;
  • Constitutional Role Classification Provider;
  • Approval Level Provider;
  • Publication Profile Provider.

External CVP

An External CVP obtains authoritative values from an external source.

Examples include:

  • ISO country codes;
  • official currency codes;
  • NACE classifications;
  • recognised regulatory taxonomies;
  • governmental code lists;
  • standards-body vocabularies.

External CVPs SHALL preserve the distinction between:

  • external source authority;
  • ZAYAZ recognition;
  • imported value;
  • mapped constitutional representation.

18.15. Authoritative and Derived Value Providers​

A CVP SHALL declare whether it supplies authoritative or derived values.

Authoritative Value Provider​

Supplies values recognised as primary within the governed domain.

Derived Value Provider​

Supplies values calculated, transformed, aggregated or inferred from authoritative values.

Examples include:

  • regional groupings derived from countries;
  • risk bands derived from scores;
  • materiality categories derived from thresholds;
  • reporting applicability derived from entity characteristics.

Derived values SHALL preserve lineage to the authoritative inputs and derivation rules.

18.16. Enumerated Value Providers​

An Enumerated Value Provider supplies a finite, governed list of values.

Examples include:

  • lifecycle status;
  • authority type;
  • role classification;
  • assignment status;
  • validation outcome;
  • publication state;
  • evidence classification.

Enumerated values SHALL NOT be duplicated in implementation code without traceable compilation from the CVP.

18.17. Reference Value Providers​

A Reference Value Provider supplies governed reference entities.

Examples include:

  • countries;
  • currencies;
  • languages;
  • units;
  • jurisdictions;
  • industry classifications;
  • legal entity types.

Reference values MAY themselves be full Constitutional Objects maintained within specialised Constitutional Registries.

In such cases, the CVP provides the governed mechanism through which those Registry Entries are selected as values.

18.18. Computational Value Providers​

A Computational Value Provider supplies values produced through governed computation.

Examples include:

  • calculated risk levels;
  • probability bands;
  • materiality thresholds;
  • financial impact classifications;
  • confidence levels;
  • scenario classifications;
  • carbon-intensity bands.

A Computational Value Provider SHALL define:

  • input requirements;
  • algorithm identity;
  • algorithm version;
  • calculation rules;
  • precision;
  • rounding;
  • uncertainty;
  • thresholds;
  • validation requirements;
  • provenance.

The algorithm MAY be maintained in the Computational Domain Registry.

The CVP governs how its outputs become recognised constitutional values.

18.19. Contextual Value Providers​

A Contextual Value Provider supplies values dependent upon Resolution Context.

Context MAY include:

  • jurisdiction;
  • reporting year;
  • regulatory framework;
  • customer;
  • white-label deployment;
  • industry;
  • asset type;
  • module;
  • component;
  • language;
  • effective date.

For example:

Metadata:
    reportingStandard

Context:
    jurisdiction = European Union
    reportingPeriod = 2028

Resolved values:
    applicable standards valid for that jurisdiction and period

Contextual resolution SHALL be governed by Constitutional Resolution Policies.

18.20. Composite Value Providers​

A Composite Value Provider combines values from multiple underlying providers.

Composite Provider
        │
        ├── Internal Value Provider
        ├── External Regulatory Provider
        ├── Customer Extension Provider
        └── Jurisdictional Overlay Provider

A Composite CVP SHALL define:

  • included providers;
  • provider precedence;
  • conflict handling;
  • duplicate handling;
  • namespace rules;
  • filtering;
  • provenance preservation;
  • deterministic ordering.

Composition SHALL NOT obscure the original value authority.

18.21. Federated Value Providers​

A Federated Value Provider resolves values across organisational or technical boundaries.

Federation MAY include:

  • ZAYAZ-managed providers;
  • customer providers;
  • governmental providers;
  • standards-body providers;
  • partner providers;
  • sector-specific providers.

Federation SHALL preserve:

  • value identity;
  • source authority;
  • namespace;
  • provenance;
  • jurisdiction;
  • temporal validity;
  • trust status;
  • resolution evidence.

18.22. CVP Provider Classification​

Every CVP SHALL declare its Provider Classification.

Typical classifications MAY include:

  • Enumerated;
  • Reference;
  • Regulatory;
  • Taxonomy;
  • External;
  • Internal;
  • Computational;
  • Derived;
  • Contextual;
  • Composite;
  • Federated;
  • Customer;
  • White-label;
  • Temporal;
  • Multilingual.

A CVP MAY possess more than one classification where constitutionally valid.

Provider classifications SHALL themselves originate from a governed CVP.

18.23. Value Authority​

Every CVP SHALL identify the Constitutional Authority responsible for recognising and governing the values it provides.

The CVP SHALL distinguish:

  • source authority;
  • recognition authority;
  • stewardship authority;
  • publication authority;
  • validation authority.

For example:

Source authority:
    Standards body

Recognition authority:
    ZAYAZ Governance Council

Steward:
    Reference Data Steward

Publisher:
    Constitutional Compiler

The organisation hosting an API SHALL NOT automatically be treated as the constitutional authority for the values supplied through it.

18.24. Source of Value Authority​

Every authoritative CVP SHALL identify its Source of Value Authority.

Sources MAY include:

  • law;
  • regulation;
  • standard;
  • official registry;
  • constitutional policy;
  • approved taxonomy;
  • scientific authority;
  • contractual framework;
  • internal governance decision.

The Source of Value Authority SHALL be represented by, or linked to, a resolvable Constitutional Object where practicable.

18.25. Value Applicability​

Each CVP and Value Set SHALL declare its applicability.

Applicability MAY include:

  • Constitutional Object Types;
  • metadata definitions;
  • modules;
  • components;
  • jurisdictions;
  • reporting frameworks;
  • customers;
  • industries;
  • lifecycle stages;
  • publication profiles;
  • calculation contexts;
  • reporting periods.

A value SHALL NOT be treated as valid outside its declared applicability.

18.26. Metadata Binding​

A Metadata Binding connects a Metadata Definition to one or more CVPs.

A Metadata Binding SHALL define:

  • Metadata Definition identifier;
  • CVP identifier;
  • Value Set identifier where applicable;
  • applicability;
  • cardinality;
  • default behaviour;
  • fallback behaviour;
  • extension rules;
  • validation rules;
  • effective period.

Example:

metadata_binding:
  metadata_definition: lifecycleStatus
  value_provider: constitutional-lifecycle-provider
  value_set: constitutional-object-lifecycle
  cardinality: exactly-one
  extensions: prohibited

The binding SHALL remain separate from the Metadata Definition and the CVP.

18.27. Role and Authority Value Support​

CVPs SHALL provide controlled values required by the Constitutional Authority and Constitutional Role models.

Typical providers MAY include:

Authority Type Provider

Values such as:

  • Institutional;
  • Role-based;
  • Personal;
  • Collective;
  • Delegated;
  • External;
  • Automated.

Authority Competence Provider

Values such as:

  • Create;
  • Review;
  • Approve;
  • Validate;
  • Publish;
  • Interpret;
  • Audit;
  • Delegate;
  • Suspend;
  • Retire.

Role Classification Provider

Values such as:

  • Accountability;
  • Stewardship;
  • Authoring;
  • Review;
  • Decision;
  • Assurance;
  • Interpretation;
  • Publication;
  • Operational;
  • Oversight.

Assignment State Provider

Values such as:

  • Proposed;
  • Active;
  • Suspended;
  • Expired;
  • Revoked;
  • Superseded.

The CVP supplies the controlled values.

The CA and CRR define how those values are constitutionally used.

18.28. Approval Level Provider​

Approval levels SHALL be governed through a CVP rather than defined as Constitutional Roles.

A possible Approval Level Value Set MAY include:

L0 — Automated
L1 — Steward
L2 — Owner
L3 — Domain Authority
L4 — Executive Authority
L5 — Constitutional Authority

Each level SHALL define:

  • semantic meaning;
  • minimum authority characteristics;
  • required role participation;
  • assurance requirements;
  • escalation conditions;
  • permitted object risk;
  • permitted decision impact.

Approval levels SHALL NOT independently grant authority.

They specify governance requirements that applicable authorities and roles must satisfy.

18.29. Value Semantics​

Every Constitutional Value SHALL possess an explicit semantic definition.

A value definition SHALL describe:

  • what the value means;
  • what it does not mean;
  • where it applies;
  • relationships to other values;
  • lifecycle;
  • authority;
  • provenance.

Values with identical labels but different meanings SHALL possess different constitutional identities.

18.30. Value Codes​

A Constitutional Value MAY have one or more codes.

Examples include:

  • internal canonical code;
  • external source code;
  • API code;
  • display code;
  • legacy code;
  • jurisdictional code.

Each code SHALL define:

  • code system;
  • issuer;
  • version;
  • applicability;
  • effective period;
  • mapping status.

A code SHALL NOT replace the Constitutional Identifier.

18.31. Canonical Value Code​

A CVP MAY define a canonical code for implementation convenience.

The canonical code SHALL:

  • be stable within a declared versioning policy;
  • remain unique within its value domain;
  • resolve to one Constitutional Value;
  • preserve case-sensitivity rules;
  • avoid hidden semantic meaning where practicable.

Canonical codes SHALL be compiled from constitutional definitions rather than invented independently by consuming systems.

18.32. Value Labels​

A Constitutional Value MAY possess multiple labels.

Labels MAY include:

  • canonical label;
  • short label;
  • legal label;
  • technical label;
  • public label;
  • white-label label;
  • translated labels.

Labels SHALL remain separate from value identity.

Changes to labels SHALL NOT alter value identity unless the semantic meaning also changes.

18.33. Multilingual Values​

CVPs MAY provide multilingual value representations.

Each translation SHALL preserve:

  • value identity;
  • semantic equivalence;
  • source language;
  • translation authority;
  • translation status;
  • version;
  • provenance.

Official translations SHOULD be distinguished from:

  • approved translations;
  • machine translations;
  • customer translations;
  • provisional translations.

Language resolution SHALL be governed by CRP.

18.34. Value Synonyms and Aliases​

CVPs MAY define synonyms and aliases.

An alias SHALL specify:

  • target Constitutional Value;
  • alias type;
  • language;
  • source;
  • validity;
  • deprecation state;
  • ambiguity rules.

Aliases MAY support:

  • search;
  • migration;
  • legacy compatibility;
  • external mappings;
  • user input normalisation.

An alias SHALL NOT create a new value unless it expresses a distinct meaning.

18.35. Value Hierarchies​

Values MAY participate in hierarchical relationships.

Examples include:

Europe
    └── European Union
            └── Denmark

or:

Assurance Role
    ├── Validator
    ├── Verifier
    ├── Auditor
    └── Certifier

Hierarchical relationships SHALL define their semantics explicitly.

A parent-child relationship SHALL NOT automatically imply:

  • inheritance;
  • substitutability;
  • broader applicability;
  • authority precedence.

Those behaviours SHALL be governed separately.

18.36. Value Relationships​

Constitutional Values MAY participate in governed relationships.

Typical relationships include:

  • broader-than;
  • narrower-than;
  • equivalent-to;
  • supersedes;
  • replaced-by;
  • compatible-with;
  • incompatible-with;
  • maps-to;
  • derived-from;
  • valid-for;
  • excluded-by;
  • requires;
  • precedes.

Relationship types SHALL originate from the Relationship Registry or another recognised CVP.

18.37. Value Mapping​

Value Mapping connects values across code systems, providers or semantic domains.

A Value Mapping SHALL define:

  • source value;
  • target value;
  • mapping type;
  • mapping confidence;
  • authority;
  • jurisdiction;
  • effective period;
  • transformation requirements;
  • provenance.

Mapping types MAY include:

  • exact;
  • equivalent;
  • broader;
  • narrower;
  • approximate;
  • conditional;
  • no-match;
  • deprecated.

Mappings SHALL NOT be treated as exact unless explicitly classified as exact.

18.38. Crosswalks​

A Crosswalk is a governed collection of Value Mappings between two or more value systems.

Examples include:

  • NACE to ISIC;
  • internal sector classification to NACE;
  • customer lifecycle state to constitutional lifecycle state;
  • external assurance classification to ZAYAZ assurance level.

Crosswalks SHALL preserve:

  • source system;
  • target system;
  • versions;
  • mapping authority;
  • assumptions;
  • coverage;
  • unmapped values;
  • ambiguity;
  • temporal applicability.

18.39. Jurisdictional Values​

A value MAY be valid only within one or more jurisdictions.

Jurisdictional validity SHALL define:

  • jurisdiction;
  • legal basis;
  • effective date;
  • expiry;
  • supersession;
  • exceptions;
  • authority.

A globally recognised value SHALL NOT automatically be legally applicable in every jurisdiction.

18.40. Temporal Values​

Values MAY possess temporal validity.

Temporal metadata MAY include:

  • valid from;
  • valid to;
  • published at;
  • withdrawn at;
  • superseded at;
  • transaction time;
  • source retrieval time.

A value valid in one reporting period MAY be invalid in another.

Historical value resolution SHALL use the version and validity state applicable to the requested time.

18.41. Versioned Values​

A CVP SHALL distinguish between provider version, Value Set version and individual value version.

CVP Version
        │
        ├── Value Set Version
        │       └── Value Version
        │
        └── Resolver Version

Changes MAY include:

  • label correction;
  • metadata enrichment;
  • code change;
  • semantic clarification;
  • value addition;
  • value deprecation;
  • value replacement;
  • scope change;
  • breaking semantic change.

Material semantic change MAY require a new Constitutional Value identity.

18.42. Value Lifecycle​

Every CVP, Value Set and Constitutional Value SHALL participate in governed lifecycle management.

Typical lifecycle states MAY include:

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

A deprecated value MAY remain available for historical interpretation.

A withdrawn value SHALL NOT normally be used for new assignments.

18.43. Value Deprecation​

Deprecation SHALL preserve:

  • value identity;
  • historical usage;
  • deprecation reason;
  • deprecation date;
  • replacement value where applicable;
  • migration guidance;
  • affected bindings;
  • provenance.

Deprecation SHALL NOT silently rewrite historical Constitutional Objects.

18.44. Value Supersession​

Where one value replaces another, a governed supersession relationship SHALL be established.

Supersession SHALL define:

  • predecessor;
  • successor;
  • effective date;
  • compatibility;
  • migration rules;
  • exceptions;
  • historical treatment.

One value MAY be superseded by multiple values where the original concept has been split.

Multiple values MAY be superseded by one value where concepts have been consolidated.

18.45. Value Extensions​

A CVP MAY permit governed extensions.

Extension types MAY include:

  • customer extension;
  • jurisdictional extension;
  • industry extension;
  • partner extension;
  • experimental extension;
  • white-label extension.

Every extension SHALL define:

  • extension authority;
  • namespace;
  • parent provider;
  • applicability;
  • precedence;
  • lifecycle;
  • publication scope;
  • compatibility;
  • provenance.

Extensions SHALL NOT alter canonical values owned by another authority.

18.46. Customer Value Providers​

Customers MAY operate customer-specific CVPs for values that belong to their governed domain.

Examples include:

  • internal business units;
  • internal facility types;
  • custom risk classes;
  • internal approval categories;
  • supplier segmentation;
  • customer-specific asset classifications.

Customer CVPs SHALL NOT override higher-order constitutional, legal or regulatory values unless explicit delegation permits it.

Customer values SHALL preserve tenant and authority lineage.

18.47. White-Label Value Providers​

White-label deployments MAY provide localised or branded value representations.

White-label CVPs MAY govern:

  • display labels;
  • customer terminology;
  • local navigation classifications;
  • internal categories;
  • publication labels.

White-label overlays SHALL preserve:

  • canonical value identity;
  • source provider;
  • original semantics;
  • jurisdictional applicability;
  • provenance.

A white-label label change SHALL NOT create a new constitutional meaning.

18.48. Default Values​

A Metadata Binding MAY identify a default value.

A default SHALL define:

  • applicable context;
  • authority;
  • justification;
  • effective period;
  • override rules;
  • whether explicit confirmation is required.

A default value SHALL NOT be interpreted as evidence that the value was factually observed.

Defaults used for inference, convenience or configuration SHALL remain distinguishable.

18.49. Unknown, Not Applicable and Not Available​

The CVP architecture SHALL distinguish semantically different absence states.

Examples include:

  • Unknown;
  • Not Known;
  • Not Provided;
  • Not Available;
  • Not Applicable;
  • Not Assessed;
  • Withheld;
  • Pending;
  • Not Disclosed.

These states SHALL NOT be represented by a single null value where their distinction has constitutional or reporting significance.

Each absence state SHOULD be governed as a Constitutional Value where applicable.

18.50. Nullability​

Nullability is a structural metadata rule.

Absence-state values are semantic values.

The two SHALL remain distinct.

Null:
    no value is present

Not Applicable:
    a governed value states that the field does not apply

HECATE SHALL distinguish structural absence from governed absence-state values.

18.51. Value Constraints​

A CVP or Metadata Binding MAY define value constraints.

Constraints MAY include:

  • permitted values;
  • prohibited values;
  • contextual validity;
  • mutual exclusion;
  • dependency;
  • temporal validity;
  • jurisdictional validity;
  • role restrictions;
  • authority restrictions;
  • minimum assurance;
  • cardinality.

Constraints SHALL remain machine-interpretable where practicable.

18.52. Conditional Values​

A value MAY be permitted only when defined conditions are satisfied.

Example:

Value:
    Approved

Condition:
    required Approval Authority has approved
    required HECATE validations have passed
    effective date has been reached

Conditional validity SHALL be evaluated against Resolution Context and supporting evidence.

18.53. Value Precedence​

Where multiple providers or values apply, precedence SHALL be governed explicitly.

Precedence MAY consider:

  • legal authority;
  • regulatory authority;
  • source authority;
  • jurisdiction;
  • specificity;
  • effective date;
  • customer scope;
  • white-label scope;
  • provider trust level;
  • policy priority.

Storage order, API order or configuration order SHALL NOT determine constitutional precedence.

18.54. Value Conflicts​

A Value Conflict occurs where multiple applicable sources produce incompatible values.

Conflict types MAY include:

  • semantic conflict;
  • code conflict;
  • jurisdiction conflict;
  • temporal conflict;
  • source conflict;
  • mapping conflict;
  • version conflict;
  • customer overlay conflict.

Value conflicts SHALL be resolved through applicable Constitutional Resolution Policies.

18.55. Value Conflict Resolution​

Conflict resolution MAY use:

  • authority precedence;
  • jurisdictional applicability;
  • temporal applicability;
  • source specificity;
  • explicit mapping;
  • trusted-source priority;
  • manual review;
  • escalation;
  • rejection.

Conflict resolution SHALL produce evidence explaining:

  • conflicting candidates;
  • selected value;
  • rejected values;
  • applicable policy;
  • deciding authority;
  • confidence;
  • timestamp.

18.56. Value Resolution​

Values SHALL be resolved through the Constitutional Resolution Architecture.

Value Requirement
        │
        ▼
Metadata Binding
        │
        ▼
CVP Identifier
        │
        ▼
CRG
        │
        ▼
CRP
        │
        ▼
Constitutional Value Provider
        │
        ▼
Candidate Values
        │
        ▼
Context and Precedence Evaluation
        │
        ▼
Resolved Constitutional Value

The resolution result SHALL preserve the complete evidence chain.

18.57. Value Resolution Context​

Value resolution MAY consider:

  • requesting Constitutional Object;
  • Metadata Definition;
  • module;
  • component;
  • jurisdiction;
  • reporting framework;
  • effective date;
  • transaction date;
  • customer;
  • white-label deployment;
  • language;
  • authority;
  • role;
  • lifecycle state;
  • publication profile;
  • security context.

Identical literals MAY resolve differently under different contexts where the applicable policies permit.

18.58. Value Resolution Result​

A Value Resolution Result SHOULD contain:

  • requested metadata;
  • CVP identifier;
  • CVP version;
  • Value Set identifier;
  • resolved value identifier;
  • canonical code;
  • selected representation;
  • source authority;
  • provenance;
  • applicability;
  • validity period;
  • confidence where relevant;
  • policy identifier;
  • resolution timestamp;
  • validation status;
  • rejected candidates;
  • warnings.

The result SHALL distinguish value resolution from value validation.

18.59. Deterministic Value Resolution​

Given identical:

  • Metadata Definition;
  • Metadata Binding;
  • CVP;
  • CVP version;
  • Value Set version;
  • Resolution Context;
  • CRP;
  • source state;
  • resolver version;

resolution SHALL produce the same Constitutional Value or the same governed failure.

Undocumented selection behaviour SHALL be prohibited.

18.60. Reproducibility​

The CVP architecture SHALL support historical reproduction.

Reproduction MAY require:

  • CVP version;
  • Value Set version;
  • value version;
  • source snapshot;
  • external source version;
  • retrieval timestamp;
  • CRP version;
  • Resolution Context;
  • mapping version;
  • resolver version.

A current value SHALL NOT be substituted for a historical value during audit unless an explicit policy requires such reinterpretation.

18.61. External Source Synchronisation​

External CVPs SHALL define synchronisation behaviour.

Synchronisation SHALL specify:

  • source endpoint;
  • source identifier;
  • source version;
  • polling or event mechanism;
  • retrieval frequency;
  • integrity verification;
  • change detection;
  • approval process;
  • publication delay;
  • fallback;
  • snapshotting;
  • failure handling.

Automatic ingestion SHALL NOT automatically constitute constitutional activation.

18.62. External Source Change Control​

Changes received from external sources SHALL be classified.

Change classifications MAY include:

  • editorial;
  • code addition;
  • code deletion;
  • code replacement;
  • semantic change;
  • authority change;
  • structural change;
  • breaking change.

Material changes SHOULD trigger:

  • impact analysis;
  • HECATE validation;
  • governance review;
  • dependent-object analysis;
  • migration planning;
  • controlled activation.

18.63. Value Provenance​

Every CVP and Constitutional Value SHALL preserve provenance.

Provenance SHALL include, as applicable:

  • originating source;
  • source authority;
  • recognition authority;
  • ingestion event;
  • transformation history;
  • mapping history;
  • approval history;
  • publication history;
  • version history;
  • supersession history;
  • stewardship history.

Derived values SHALL preserve lineage to all material inputs.

18.64. Value Evidence​

Value resolution MAY require supporting evidence.

Evidence MAY include:

  • official publication;
  • registry extract;
  • source API response;
  • signed dataset;
  • regulatory document;
  • classification decision;
  • calculation record;
  • mapping approval;
  • customer governance decision.

Evidence SHALL be represented by, or linked to, governed Constitutional Objects where practicable.

18.65. Value Traceability​

It SHALL be possible to determine:

  • which CVP supplied a value;
  • which Value Set contained it;
  • which version applied;
  • which authority governed it;
  • which source originated it;
  • which Metadata Definition referenced it;
  • which Constitutional Objects used it;
  • which mapping transformed it;
  • which policy selected it;
  • which validation confirmed it.

Value lineage SHALL be preserved end to end.

18.66. HECATE Validation​

HECATE SHALL validate CVPs, Value Sets, values and bindings.

Validation SHALL include, as applicable:

  • identifier uniqueness;
  • semantic completeness;
  • provider classification;
  • value-domain consistency;
  • authority;
  • source validity;
  • lifecycle;
  • version compatibility;
  • applicability;
  • jurisdiction;
  • temporal validity;
  • duplicate values;
  • code uniqueness;
  • mapping integrity;
  • provenance;
  • relationship integrity;
  • binding compatibility;
  • conflict rules;
  • extension rules.

Invalid values SHALL NOT become constitutionally authoritative.

18.67. Value Usage Validation​

HECATE SHALL validate whether a value is valid for a particular use.

Usage validation SHALL determine:

  • whether the value exists;
  • whether the provider is authoritative;
  • whether the Value Set permits it;
  • whether the value was active;
  • whether the context applies;
  • whether jurisdiction applies;
  • whether temporal validity applies;
  • whether cardinality is satisfied;
  • whether dependent conditions are satisfied;
  • whether evidence requirements are met.

A valid Constitutional Value MAY still be invalid in a particular context.

18.68. Trust​

External and federated CVPs SHALL possess explicit trust classifications.

Trust MAY consider:

  • source authority;
  • legal recognition;
  • accreditation;
  • technical integrity;
  • signature validation;
  • publication controls;
  • update reliability;
  • governance maturity;
  • historical quality.

Trust classifications SHALL originate from a governed CVP.

Trust SHALL influence resolution only through explicit CRPs.

18.69. Assurance Levels​

CVPs MAY govern assurance levels used for values, providers or resolution results.

Assurance MAY express confidence in:

  • source identity;
  • value authenticity;
  • semantic accuracy;
  • mapping quality;
  • computational derivation;
  • temporal currency;
  • evidence completeness.

Assurance levels SHALL NOT be confused with probabilistic confidence unless explicitly defined as such.

18.70. Security​

CVPs SHALL apply security controls proportionate to value sensitivity and constitutional impact.

Controls MAY include:

  • access restrictions;
  • signed releases;
  • integrity hashes;
  • approval workflows;
  • immutable audit;
  • source authentication;
  • encryption;
  • tenant isolation;
  • tamper detection;
  • privileged-change monitoring.

Security controls SHALL NOT alter value semantics.

18.71. Data Residency​

A CVP MAY define data-residency constraints.

Residency rules MAY apply to:

  • source retrieval;
  • cache location;
  • publication;
  • customer extensions;
  • personal data;
  • jurisdictionally restricted values;
  • proprietary code lists.

CRPs SHALL govern how residency affects provider selection and value resolution.

18.72. Availability​

CVPs SHOULD define availability requirements.

Availability mechanisms MAY include:

  • mirrored providers;
  • governed caches;
  • signed snapshots;
  • offline bundles;
  • fallback providers;
  • delayed synchronisation.

Availability SHALL NOT override authority, integrity or temporal correctness.

18.73. Caching​

CVP caching SHALL be governed.

Cache policies SHALL define:

  • permitted content;
  • time to live;
  • source version;
  • invalidation rules;
  • integrity verification;
  • jurisdiction;
  • data residency;
  • stale-value behaviour;
  • offline behaviour.

A cached value SHALL retain provenance to the original provider.

18.74. Offline Value Resolution​

CVPs MAY support offline value resolution.

Offline bundles SHALL preserve:

  • CVP identity;
  • CVP version;
  • Value Set versions;
  • value identities;
  • source snapshots;
  • signatures;
  • validity periods;
  • mappings;
  • applicable CRPs;
  • compiler version.

Offline resolution SHALL indicate that the result was produced from an offline snapshot.

18.75. Failure Behaviour​

CVPs SHALL define governed failure behaviour.

Failure types MAY include:

  • provider unavailable;
  • value not found;
  • ambiguous value;
  • invalid context;
  • expired value;
  • unauthorised provider;
  • source integrity failure;
  • mapping conflict;
  • unsupported version;
  • policy conflict.

A failed resolution SHALL NOT silently substitute an arbitrary literal.

18.76. Fallback​

Fallback MAY be permitted only through CRP.

Fallback options MAY include:

  • previous approved provider version;
  • governed cache;
  • historical snapshot;
  • alternate recognised provider;
  • manual review;
  • explicit unknown value;
  • resolution failure.

Fallback SHALL preserve evidence that the primary resolution path failed.

18.77. Performance​

CVP implementations SHOULD support efficient:

  • identifier resolution;
  • code lookup;
  • label lookup;
  • contextual filtering;
  • multilingual retrieval;
  • historical lookup;
  • mapping lookup;
  • dependency traversal;
  • bulk validation.

Performance optimisation SHALL NOT change constitutional selection behaviour.

18.78. Bulk Value Resolution​

CVPs MAY support bulk resolution for:

  • reporting datasets;
  • registry ingestion;
  • metadata migration;
  • supply-chain imports;
  • classification mapping;
  • assurance validation.

Bulk operations SHALL preserve per-value evidence and validation outcomes.

A batch success status SHALL NOT obscure individual value failures.

A CVP MAY support search.

Search MAY consider:

  • canonical label;
  • alias;
  • code;
  • language;
  • semantic similarity;
  • provider;
  • jurisdiction;
  • lifecycle;
  • effective date.

Search results SHALL be treated as candidates.

Search SHALL NOT itself constitute authoritative resolution.

18.80. AI Participation​

AI systems MAY assist with:

  • value discovery;
  • classification suggestions;
  • mapping proposals;
  • duplicate detection;
  • translation;
  • anomaly detection;
  • change impact analysis;
  • semantic comparison.

AI systems SHALL NOT autonomously create authoritative values unless explicitly designated as an Automated Authority within a bounded mandate.

AI-generated value mappings or classifications SHALL preserve:

  • model identity;
  • model version;
  • input context;
  • confidence;
  • evidence;
  • review status;
  • approving authority.

18.81. Value Recommendations​

A value recommendation is not a resolved Constitutional Value.

Recommendations SHALL be distinguishable from:

  • approved values;
  • authoritative mappings;
  • validated classifications;
  • active Value Set membership.

A recommended value MAY become authoritative only through the applicable governance process.

18.82. Technology Independence​

The CVP architecture SHALL remain independent of:

  • programming language;
  • database;
  • API style;
  • schema language;
  • cloud provider;
  • storage format;
  • user-interface framework;
  • identity provider.

CVPs MAY be implemented through:

  • relational databases;
  • graph databases;
  • RDF;
  • JSON;
  • YAML;
  • XML;
  • APIs;
  • files;
  • event streams;
  • knowledge graphs;
  • external registries.

Technology implements value provision.

Technology SHALL NOT define constitutional value authority.

18.83. CVP Compilation​

The Constitutional Compiler MAY compile CVPs into:

  • enumerations;
  • lookup tables;
  • dropdown options;
  • API schemas;
  • JSON Schema constraints;
  • GraphQL enums;
  • SDK constants;
  • database reference tables;
  • RDF vocabularies;
  • validation rules;
  • search indexes;
  • mapping tables;
  • localisation bundles;
  • AI context packages;
  • offline value bundles.

Compiled artefacts SHALL preserve:

  • CVP identity;
  • Value Set identity;
  • value identity;
  • provider version;
  • source authority;
  • lifecycle;
  • applicability;
  • provenance.

18.84. Runtime Representation​

At runtime, a Constitutional Value SHOULD be represented with sufficient information to preserve identity and traceability.

A runtime representation MAY include:

value:
  id: "zyz:value:lifecycle:active"
  code: "active"
  label: "Active"
  provider: "zyz:cvp:constitutional-lifecycle"
  value_set: "zyz:valueset:constitutional-object-lifecycle"
  version: "1.0.0"
  valid_from: "2026-01-01"

The exact syntax is implementation-specific.

The constitutional identity and semantics are not.

18.85. Publication​

CVPs MAY publish values for:

  • internal governance;
  • developers;
  • customers;
  • regulators;
  • assurance providers;
  • white-label platforms;
  • public reference;
  • AI systems.

Publication profiles MAY expose different:

  • labels;
  • descriptions;
  • codes;
  • provenance detail;
  • evidence;
  • source links;
  • lifecycle information.

Publication SHALL NOT alter value meaning.

18.86. Change Impact Analysis​

Material CVP changes SHOULD undergo impact analysis.

Impact analysis SHOULD identify:

  • affected Metadata Definitions;
  • affected Constitutional Objects;
  • affected registries;
  • affected CKAs;
  • affected CRPs;
  • affected authority assignments;
  • affected role assignments;
  • affected validation rules;
  • affected APIs;
  • affected compiler outputs;
  • affected modules;
  • affected components;
  • affected customers;
  • affected white-label deployments;
  • affected reporting periods;
  • affected historical reproductions.

Value removal, semantic change and mapping change SHOULD be treated as high-impact operations.

18.87. Governance​

Every CVP SHALL identify:

  • owner;
  • steward;
  • approving authority;
  • validation authority;
  • publication authority;
  • retirement authority.

Governance participation SHALL reference Constitutional Authorities and Constitutional Roles.

For example:

Authority:
    ZAYAZ Governance Council

Role:
    Owner

Object:
    Constitutional Lifecycle State Provider

CVPs SHALL NOT govern themselves through undocumented implementation ownership.

18.88. Activation​

A CVP or CVP version SHALL become active only after governed activation.

Activation SHALL verify:

  • identity;
  • semantic completeness;
  • authority;
  • source;
  • provider classification;
  • value-domain scope;
  • lifecycle;
  • Value Set integrity;
  • mapping integrity;
  • version compatibility;
  • HECATE validation;
  • required approvals;
  • publication readiness.

Deployment alone SHALL NOT constitute constitutional activation.

18.89. Suspension and Withdrawal​

A CVP MAY be suspended or withdrawn where:

  • source integrity is compromised;
  • authority is invalid;
  • values are materially incorrect;
  • mappings are unreliable;
  • security is compromised;
  • legal applicability changes;
  • required evidence expires.

Suspension SHALL define:

  • affected values;
  • effective time;
  • fallback behaviour;
  • replacement provider;
  • review authority;
  • reinstatement conditions.

Historical traceability SHALL be preserved.

18.90. Conformance​

A Constitutional Value Provider conforms where it:

  1. is represented as a Constitutional Object;
  2. possesses stable constitutional identity;
  3. declares a governed Value Domain;
  4. identifies governing and source authorities;
  5. defines provider classification;
  6. supplies identifiable Constitutional Values;
  7. preserves value-set and value versioning;
  8. declares applicability and jurisdiction;
  9. preserves temporal validity;
  10. supports provenance and traceability;
  11. supports deterministic resolution;
  12. supports HECATE validation;
  13. preserves external-source lineage where applicable;
  14. supports governed extension and federation;
  15. remains independent of implementation technology.

A literal, code list or API SHALL NOT be considered a conforming CVP merely because it supplies selectable values.

18.91. Relationship to Other Constitutional Components​

Constitutional Value Providers supply the governed values used throughout the constitutional ecosystem.

Their relationship to other constitutional components is as follows:

  • the Constitutional Knowledge Model defines the concepts represented by values;
  • the Constitutional Object System defines CVPs, Value Sets and significant values as specialised Constitutional Objects;
  • the Constitutional Metadata Dictionary defines metadata fields and binds them to applicable CVPs;
  • Constitutional Authorities govern value ownership, recognition, approval, publication and retirement;
  • the Constitutional Role Registry defines the governance roles through which authorities participate in CVP governance;
  • Authority and Role Assignments connect authorities and roles to CVPs, Value Sets and values;
  • the Constitutional Registry Registry identifies the Constitutional Value Provider Registry and related value registries;
  • Constitutional Resolution Policies govern provider selection, precedence, context, fallback and conflict handling;
  • Constitutional Registries may act as sources of reference values consumed through CVPs;
  • Constitutional Knowledge Assets reference CVPs for controlled metadata values;
  • Authoritative Validation Sources provide evidence for external or regulated values;
  • HECATE validates providers, values, mappings, bindings and contextual usage;
  • the Constitutional Compiler transforms CVPs into schemas, enumerations, lookup structures, APIs, validation logic and runtime artefacts;
  • runtime systems consume compiled values without redefining their constitutional meaning.

CVPs therefore form the controlled-value layer connecting constitutional semantics to valid operational data.

18.92. Foundational Principle​

A Constitutional Value Provider is the governed constitutional mechanism through which controlled, authoritative and contextually valid values are supplied to the ZAYAZ ecosystem.

The Constitutional Metadata Dictionary defines what a metadata field means. A Constitutional Value Provider defines which values may satisfy that field, where those values originate, under which authority they are recognised and how they are resolved within a given context.

Constitutional Values SHALL possess stable identity, explicit semantics, authority, applicability, lifecycle, versioning, provenance and traceability. They SHALL remain distinguishable from labels, codes, literals, implementation enumerations and user-interface representations.

External, internal, computational, contextual, composite and federated providers MAY participate in value resolution, but every material selection decision SHALL remain governed, deterministic, reproducible and validatable.

By separating value authority from metadata structure and implementation technology, ZAYAZ establishes a consistent and evolvable foundation for controlled vocabularies, classifications, reference data, regulatory code lists, computational outcomes and semantic interoperability across the entire constitutional ecosystem.



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