Skip to main content

Chapter 23 — Constitutional Runtime Framework

Part III — Context and Resolution Runtime​

Context and Resolution Runtime defines how the Constitutional Runtime Framework constructs the conditions under which constitutional knowledge is interpreted and how it deterministically determines which Constitutional Objects, Relationships, policies, versions, methodologies, Value Providers, evidence sources, schemas and runtime capabilities apply.

A runtime SHALL NOT treat context as an ungoverned parameter map.

A runtime SHALL NOT treat resolution as an implementation lookup.

Every authoritative runtime decision SHALL occur within an explicit Constitutional Context and SHALL be produced through governed Constitutional Resolution Policies.

Conceptually:

Execution Request
        │
        ▼
Context Sources
        │
        ├── Tenant
        ├── Organisation
        ├── Jurisdiction
        ├── Reporting Framework
        ├── Reporting Period
        ├── Assurance Profile
        ├── Deployment
        ├── Security Profile
        └── Runtime Bundle
        │
        ▼
Context Assembly
        │
        ▼
Context Validation
        │
        ▼
Context Fingerprint
        │
        ▼
Resolution Request
        │
        ▼
Candidate Discovery
        │
        ▼
CRP Evaluation
        │
        ├── Applicability
        ├── Precedence
        ├── Specificity
        ├── Authority
        ├── Temporal Validity
        ├── Compatibility
        ├── Evidence Quality
        └── Fallback
        │
        ▼
Resolved Constitutional Outcome
        │
        ▼
Resolution Explanation and Provenance

The Context and Resolution Runtime SHALL ensure that the same constitutionally relevant context, candidate set, Resolution Policies and runtime artefacts produce the same resolved outcome.

23.23. Context Assembly​

Context Assembly is the governed process through which the Constitutional Runtime Framework constructs the effective Runtime Context for an execution.

Context Assembly SHALL combine context dimensions from approved sources according to explicit composition, precedence, inheritance and conflict-resolution rules.

The result SHALL be a complete, immutable and fingerprinted Runtime Context suitable for deterministic execution.

23.23.1. Assembly Purpose​

Context Assembly SHALL determine the conditions under which constitutional knowledge is:

  • interpreted;
  • resolved;
  • validated;
  • reasoned upon;
  • computed;
  • governed;
  • published;
  • assured;
  • retained;
  • secured.

The assembled context SHALL constrain every later phase of execution.

A Runtime Component SHALL NOT silently introduce additional context dimensions after the context has been sealed.

23.23.2. Context Sources​

Context MAY be assembled from sources including:

  • explicit Execution Request context;
  • tenant context;
  • white-label base context;
  • organisation context;
  • legal-entity context;
  • jurisdiction context;
  • reporting-framework context;
  • reporting-period context;
  • product context;
  • facility context;
  • supply-chain context;
  • assessment-boundary context;
  • assurance context;
  • security context;
  • workflow context;
  • actor context;
  • deployment context;
  • Runtime Bundle context;
  • constitutional-release context;
  • governed defaults.

Every context source SHALL possess identity, provenance, lifecycle state and temporal validity where constitutionally relevant.

23.23.3. Context Dimensions​

A Runtime Context MAY include dimensions such as:

Context DimensionConstitutional Purpose
TenantEstablishes white-label and data-isolation scope
OrganisationIdentifies the governed organisational domain
Legal EntityEstablishes legal reporting and authority scope
JurisdictionDetermines applicable legal and regulatory rules
Reporting FrameworkDetermines applicable reporting architecture
Reporting PeriodDefines the reporting or assessment interval
Fiscal PeriodDefines financial and organisational time boundaries
Constitutional ReleaseIdentifies applicable constitutional knowledge
Runtime BundleIdentifies executable constitutional artefacts
LanguageDetermines governed localisation
CurrencyDetermines monetary representation and conversion
Unit SystemDetermines measurement representation
MethodologyDetermines permitted calculation or assessment method
Assurance LevelDetermines evidence and validation requirements
Publication ProfileDetermines publication eligibility and representation
Security ProfileDetermines access, handling and disclosure constraints
ScenarioDistinguishes actual, forecast, stress and simulation contexts
ProductEstablishes product-specific scope
FacilityEstablishes site-specific scope
Supply-Chain BoundaryEstablishes upstream and downstream inclusion
Data ResidencyDetermines approved processing and storage locations
Execution ModeDistinguishes authoritative, advisory, simulation and replay execution

Context dimensions SHALL originate from Constitutional Schemas and governed Constitutional Value Providers.

23.23.4. Explicit Context​

Context supplied directly by the Execution Request SHALL be classified as Explicit Request Context.

Explicit context SHALL:

  • identify its source;
  • identify the actor supplying it;
  • conform to the applicable Constitutional Schema;
  • preserve provenance;
  • remain within the actor’s authority;
  • remain subject to validation and resolution.

Explicit context SHALL NOT automatically override constitutional or jurisdictional context.

23.23.5. Derived Context​

Context MAY be derived from other constitutional knowledge.

Examples include:

Registered Office
        derives
Applicable Jurisdiction
Reporting Date
        derives
Reporting Period
Product Classification
        derives
Applicable Product Passport Profile

Derived context SHALL preserve:

  • derivation rule;
  • source objects;
  • reasoning profile;
  • confidence where applicable;
  • temporal boundary;
  • provenance.

Derived context SHALL remain distinguishable from explicitly asserted context.

23.23.6. Resolved Context​

Context selected through Constitutional Resolution Policies SHALL be classified as Resolved Context.

Examples include:

  • resolved jurisdiction;
  • resolved regulatory version;
  • resolved reporting profile;
  • resolved assurance level;
  • resolved methodology;
  • resolved Value Provider;
  • resolved language variant.

Every Resolved Context dimension SHALL preserve the candidate set, governing CRP and resolution explanation.

23.23.7. Default Context​

A governed default MAY supply a missing context dimension only where:

  • a Constitutional Resolution Policy permits defaulting;
  • the default is explicit and versioned;
  • the default’s scope is defined;
  • its authority is known;
  • its temporal validity is known;
  • its use is recorded in the context provenance.

A hidden application default SHALL NOT become constitutional context.

23.23.8. Context Composition​

Context Composition combines multiple subordinate Constitutional Contexts into one effective Runtime Context.

Example:

Effective Runtime Context
│
├── Core Constitutional Context
├── Tenant Context
├── Organisation Context
├── Jurisdiction Context
├── Reporting Framework Context
├── Reporting Period Context
├── Assurance Context
├── Security Context
└── Execution Context

Composition SHALL define:

  • source order;
  • permissible inheritance;
  • permissible override;
  • conflict treatment;
  • mandatory dimensions;
  • excluded dimensions;
  • provenance merging;
  • temporal intersection.

23.23.9. Context Precedence​

Where two context sources supply the same dimension, precedence SHALL be resolved through a governed Context Resolution Policy.

Precedence MAY consider:

  • constitutional authority;
  • legal authority;
  • tenant specificity;
  • organisational specificity;
  • temporal specificity;
  • explicitness;
  • evidence quality;
  • lifecycle state;
  • approval status;
  • security classification.

Source order in an implementation configuration file SHALL NOT establish constitutional precedence.

23.23.10. Context Merge​

A context merge SHALL classify each dimension as:

  • accepted;
  • inherited;
  • overridden;
  • resolved;
  • excluded;
  • conflicting;
  • unresolved;
  • defaulted.

The merge result SHALL preserve the source of every accepted value.

23.23.11. Context Intersection​

Where multiple contexts constrain the same execution, the effective context SHOULD normally be the constitutionally valid intersection of those constraints.

Examples include:

  • the narrower of two permitted data scopes;
  • the stricter of two assurance requirements;
  • the intersection of two temporal intervals;
  • the common set of permitted jurisdictions;
  • the lowest common set of authorised side effects.

Context intersection SHALL NOT silently broaden authority or access.

23.23.12. Context Expansion​

Context Assembly SHALL NOT expand context beyond:

  • the Execution Request;
  • applicable Constitutional Contexts;
  • resolved authority;
  • approved defaults;
  • permitted derivations.

Context expansion after execution planning SHALL require:

  • an explicit need;
  • sufficient authority;
  • reassembly;
  • revalidation;
  • a new Context Fingerprint;
  • plan re-evaluation;
  • provenance.

23.23.13. Context Sealing​

After successful assembly and validation, the Runtime Context SHALL be sealed.

A sealed Runtime Context SHALL be immutable for the applicable execution version.

Sealing SHALL record:

  • Context Identifier;
  • Context Fingerprint;
  • context dimensions;
  • source contexts;
  • assembly policy;
  • resolution decisions;
  • validation outcome;
  • seal timestamp;
  • sealing Component;
  • provenance.

23.23.14. Context Assembly Failure​

Context Assembly SHALL fail where:

  • a mandatory dimension cannot be established;
  • incompatible dimensions cannot be resolved;
  • a source lacks authority;
  • a source is temporally invalid;
  • tenant boundaries conflict;
  • a context reference is unresolved;
  • a required Value Provider is unavailable;
  • a derived context lacks sufficient evidence;
  • a security restriction prohibits assembly.

Failure SHALL produce an explicit Context Assembly Diagnostic.

23.24. Context Inheritance​

Context Inheritance is the governed mechanism through which one Constitutional Context receives dimensions from another Constitutional Context.

Inheritance SHALL reduce duplication without creating hidden runtime behaviour.

Context Inheritance SHALL remain distinct from override, aggregation and composition.

23.24.1. Parent Context​

A Parent Context is a Constitutional Context from which one or more dimensions may be inherited.

Examples include:

ZAYAZ Core Context
        │
        ▼
White-label Base Context
        │
        ▼
Tenant Context
        │
        ▼
Organisation Runtime Context
Global Reporting Context
        │
        ▼
EU Reporting Context
        │
        ▼
Norwegian Reporting Context

Parent Context identity SHALL remain visible in the effective Runtime Context.

23.24.2. Inheritance Types​

Context Inheritance MAY be:

  • full inheritance;
  • selective inheritance;
  • dimension-specific inheritance;
  • conditional inheritance;
  • temporal inheritance;
  • jurisdictional inheritance;
  • tenant inheritance;
  • profile inheritance.

The inheritance type SHALL be explicit.

23.24.3. Inheritable Dimensions​

Each Context Schema SHALL declare which dimensions are:

  • inheritable;
  • non-inheritable;
  • inheritable with approval;
  • inheritable only within a tenant;
  • inheritable only within a jurisdiction;
  • inheritable only within a defined temporal interval.

Sensitive dimensions such as actor identity, emergency authority and personal consent SHOULD NOT be inherited unless explicitly permitted.

23.24.4. Inheritance Conditions​

Inheritance MAY depend upon conditions including:

  • tenant compatibility;
  • jurisdiction compatibility;
  • framework compatibility;
  • lifecycle state;
  • temporal validity;
  • authority;
  • security classification;
  • schema compatibility;
  • Runtime Bundle compatibility.

A failed condition SHALL prevent inheritance of the affected dimension.

23.24.5. Inheritance Order​

Where multiple parent contexts exist, inheritance order SHALL be deterministic.

Order MAY be governed by:

  • explicit parent priority;
  • constitutional authority;
  • specificity;
  • tenant overlay order;
  • jurisdictional hierarchy;
  • framework hierarchy;
  • temporal recency;
  • approved composition policy.

Graph traversal order SHALL NOT determine constitutional inheritance order.

23.24.6. Multiple Inheritance​

A Runtime Context MAY inherit from multiple Parent Contexts.

Multiple inheritance SHALL preserve:

  • all Parent Context identities;
  • inherited dimensions;
  • source-specific provenance;
  • conflict resolution;
  • final effective values.

Ambiguous multiple inheritance SHALL be resolved through a Constitutional Resolution Policy.

23.24.7. Context Override​

A child context MAY override an inherited dimension only where:

  • the dimension permits override;
  • the child possesses override authority;
  • the override remains within constitutional scope;
  • the override’s temporal validity is defined;
  • the override is compatible with higher-order mandatory constraints;
  • the override is recorded.

Override SHALL not erase the inherited value from history.

23.24.8. Prohibited Override​

An override SHALL be prohibited where it would:

  • weaken mandatory legal requirements;
  • bypass tenant isolation;
  • reduce required assurance without authority;
  • alter immutable Constitutional Identity;
  • substitute an invalid regulatory version;
  • broaden data access;
  • weaken evidence requirements;
  • disable mandatory HECATE validation.

23.24.9. Inheritance Cycles​

Context inheritance cycles SHALL be prohibited.

HECATE SHALL detect:

  • direct cycles;
  • indirect cycles;
  • conditional cycles;
  • cycles introduced through tenant overlays;
  • cycles introduced through federated contexts.

A context participating in an unresolved inheritance cycle SHALL NOT be activated.

23.24.10. Inheritance Provenance​

Every inherited dimension SHALL preserve:

  • source Parent Context;
  • inheritance relationship;
  • inheritance policy;
  • inherited value;
  • child context;
  • any transformation applied;
  • temporal interval;
  • validation status;
  • provenance.

23.24.11. Inheritance Versioning​

Context inheritance SHALL be version-aware.

A child context SHALL identify the parent context version or governed version range from which it inherits.

Activation of a new parent version SHALL NOT silently alter an active child context unless the inheritance policy explicitly permits dynamic resolution.

23.24.12. White-label Inheritance​

White-label inheritance SHALL follow the governed overlay order:

ZAYAZ Core
        │
        ▼
White-label Base
        │
        ▼
Tenant Overlay
        │
        ▼
Organisation Overlay
        │
        ▼
Execution Context

Each layer MAY extend or specialise permitted context dimensions.

No layer SHALL silently modify the constitutional meaning of the layer above it.

23.25. Context Validation​

Context Validation determines whether an assembled Runtime Context is complete, coherent, authorised, temporally applicable and safe for its intended execution.

HECATE SHALL validate every authoritative Runtime Context before it is sealed.

23.25.1. Validation Dimensions​

Context Validation SHALL evaluate:

  • identity;
  • schema conformance;
  • mandatory dimensions;
  • dimension types;
  • source authority;
  • inheritance validity;
  • composition validity;
  • override validity;
  • temporal applicability;
  • tenant isolation;
  • jurisdiction consistency;
  • framework compatibility;
  • Runtime Bundle compatibility;
  • security constraints;
  • assurance requirements;
  • provenance completeness;
  • fingerprint reproducibility.

23.25.2. Completeness Validation​

A context is complete where every dimension required by the applicable:

  • Execution Request;
  • Runtime Profile;
  • Runtime Bundle;
  • Execution Plan;
  • Component Contract;
  • Constitutional Resolution Policy;
  • HECATE rule;
  • jurisdictional rule;
  • security policy;
  • assurance profile

is present or deterministically resolvable.

Completeness SHALL be assessed relative to purpose.

A context sufficient for an advisory query MAY be insufficient for publication or assurance.

23.25.3. Coherence Validation​

A context is coherent where its dimensions do not create unresolved constitutional contradiction.

Examples of incoherence include:

  • a reporting period outside the applicable framework version;
  • a jurisdiction incompatible with the selected regulation;
  • a tenant context combined with another tenant’s security profile;
  • an assurance level unsupported by the evidence policy;
  • a Runtime Bundle incompatible with the constitutional release;
  • a currency inconsistent with a locked reporting profile;
  • a product context inconsistent with the selected classification.

23.25.4. Authority Validation​

Every context source, inheritance and override SHALL possess sufficient authority.

Authority validation SHALL determine:

  • who asserted the dimension;
  • who approved it;
  • whether delegation applies;
  • whether authority is still valid;
  • whether scope permits the dimension;
  • whether separation-of-duties rules apply.

23.25.5. Temporal Validation​

Context Validation SHALL evaluate all applicable time dimensions.

The validation SHALL distinguish:

  • effective time;
  • valid time;
  • transaction time;
  • reporting period;
  • observation time;
  • publication time;
  • regulatory issuance time.

A context combining temporally incompatible elements SHALL fail or be explicitly qualified.

23.25.6. Tenant Validation​

Tenant validation SHALL confirm that:

  • all tenant-bound context sources belong to the same permitted tenant boundary;
  • overlays are applied in approved order;
  • cross-tenant references possess explicit authority;
  • shared Core context does not expose tenant-specific knowledge;
  • caches and fingerprints are tenant-scoped where necessary.

Cross-tenant context leakage SHALL be classified as a critical integrity failure.

23.25.7. Jurisdiction Validation​

Jurisdiction validation SHALL confirm:

  • the jurisdiction’s identity;
  • legal applicability;
  • regulatory applicability;
  • contractual applicability;
  • reporting applicability;
  • temporal validity;
  • governing authority;
  • compatibility with the organisation and activity scope.

Deployment location SHALL NOT be treated as sufficient jurisdiction evidence.

23.25.8. Security Validation​

Security validation SHALL evaluate:

  • access profile;
  • data classification;
  • purpose limitation;
  • residency requirements;
  • consent where applicable;
  • encryption requirements;
  • confidentiality restrictions;
  • prohibited combinations;
  • disclosure restrictions.

A context that would cause unauthorised inference or disclosure SHALL not be sealed.

23.25.9. Validation Severity​

Context Validation findings SHALL use governed severities, including:

  • Information;
  • Recommendation;
  • Warning;
  • Error;
  • Critical Error.

Errors and Critical Errors SHALL prevent authoritative context sealing unless an explicit constitutional exception applies.

23.25.10. Conditional Validity​

A context MAY be conditionally valid where:

  • an optional dimension is unavailable;
  • a provisional source is permitted;
  • a simulation explicitly uses assumptions;
  • an assurance limitation is disclosed;
  • a controlled fallback applies.

Conditional validity SHALL identify:

  • the condition;
  • affected dimensions;
  • permitted purposes;
  • prohibited purposes;
  • expiration;
  • required remediation.

23.25.11. Context Qualification​

A validated context MAY require qualification.

Qualifications MAY state that the context is:

  • advisory only;
  • simulation only;
  • incomplete for assurance;
  • incomplete for publication;
  • based on provisional jurisdiction;
  • based on estimated reporting period;
  • based on fallback methodology;
  • dependent upon unverified evidence.

Qualifications SHALL propagate to downstream Runtime Outcomes.

23.25.12. Context Validation Result​

Every validation SHALL produce a Context Validation Result containing:

  • Context Identifier;
  • Context Fingerprint candidate;
  • validation profile;
  • evaluated rules;
  • passed rules;
  • failed rules;
  • warnings;
  • qualifications;
  • validator identity;
  • HECATE version;
  • timestamp;
  • provenance.

23.25.13. Revalidation​

A sealed Runtime Context SHALL be revalidated where:

  • a source context changes;
  • a parent context changes;
  • a governing CRP changes;
  • the Runtime Bundle changes;
  • authority expires;
  • the execution purpose changes;
  • a material temporal boundary is crossed;
  • an evidence source is revoked;
  • a security policy changes;
  • runtime drift is detected.

23.26. Context Fingerprints​

A Context Fingerprint is the deterministic cryptographic or canonical semantic representation of the constitutionally relevant content of a Runtime Context.

The Context Fingerprint enables replay, cache safety, audit correlation, distributed consistency and comparison.

23.26.1. Fingerprint Purpose​

The Context Fingerprint SHALL allow the runtime to determine whether two Runtime Contexts are constitutionally equivalent for a defined purpose.

A fingerprint SHALL NOT merely hash a serialized parameter object.

It SHALL represent normalized constitutional meaning.

23.26.2. Fingerprint Inputs​

Fingerprint inputs SHALL include, where relevant:

  • Context Identifier;
  • context type;
  • normalized dimension values;
  • source context identities;
  • source context versions;
  • inheritance relationships;
  • applied overrides;
  • applied defaults;
  • resolution outcomes;
  • temporal boundaries;
  • tenant identity;
  • jurisdiction identity;
  • constitutional release;
  • Runtime Bundle identity;
  • validation profile;
  • context qualifications.

23.26.3. Excluded Inputs​

Fingerprint inputs SHOULD exclude data that does not affect constitutional behaviour, such as:

  • transport identifiers;
  • request routing metadata;
  • memory addresses;
  • hostnames where deployment location is irrelevant;
  • serialization order;
  • whitespace;
  • logging correlation values;
  • display-only labels.

An excluded value that later becomes constitutionally relevant SHALL require a new fingerprint profile version.

23.26.4. Canonicalization​

Context fingerprinting SHALL use a governed canonicalization process.

Canonicalization SHALL define:

  • field ordering;
  • Unicode normalization;
  • identifier normalization;
  • date and time normalization;
  • unit normalization;
  • currency normalization;
  • null and missing-value treatment;
  • list ordering;
  • graph ordering;
  • relationship representation;
  • numeric precision.

Equivalent constitutional contexts SHALL produce equivalent canonical forms.

23.26.5. Fingerprint Profile​

The fingerprint algorithm and canonicalization rules SHALL be governed through a Context Fingerprint Profile.

The profile SHALL define:

  • profile identity;
  • algorithm;
  • canonicalization version;
  • included dimensions;
  • excluded dimensions;
  • purpose;
  • compatibility rules;
  • security classification.

23.26.6. Semantic Fingerprint​

A Semantic Context Fingerprint MAY represent equivalence independent of source serialization.

It SHOULD normalize:

  • aliases to Constitutional Identifiers;
  • equivalent units;
  • equivalent currencies under a fixed conversion context;
  • inherited and explicitly repeated values;
  • ordered and unordered collections according to schema;
  • equivalent context compositions.

23.26.7. Source Fingerprint​

A Source Context Fingerprint MAY additionally preserve exact source composition.

Two contexts MAY possess the same Semantic Fingerprint but different Source Fingerprints where they derive the same meaning from different sources.

Both MAY be required for assurance.

23.26.8. Fingerprint Scope​

A fingerprint SHALL declare its scope.

Examples include:

  • resolution scope;
  • validation scope;
  • computation scope;
  • publication scope;
  • assurance scope;
  • security scope;
  • cache scope.

A fingerprint valid for one scope SHALL NOT automatically be reused for another.

23.26.9. Collision Handling​

Fingerprint collisions SHALL be treated as critical integrity events.

The runtime SHALL preserve the canonical source form needed to verify equality rather than trusting the fingerprint alone.

23.26.10. Fingerprint Versioning​

Fingerprint Profiles SHALL be versioned.

A profile change SHALL NOT silently reinterpret existing fingerprints.

Cross-version comparison SHALL use an explicit compatibility or migration rule.

23.26.11. Distributed Context Verification​

Distributed Runtime Components SHALL verify that they are operating under the same required Context Fingerprint.

A mismatch SHALL:

  • stop the affected Plan Step;
  • prevent authoritative side effects;
  • produce a diagnostic;
  • preserve both fingerprints;
  • trigger context reconciliation.

23.26.12. Fingerprint Provenance​

Every Context Fingerprint SHALL preserve:

  • profile identity;
  • profile version;
  • algorithm;
  • creation timestamp;
  • generating Component;
  • Runtime Bundle;
  • source context identities;
  • validation result;
  • provenance.

23.27. Runtime Resolution​

Runtime Resolution is the governed process through which the Constitutional Runtime Framework determines which constitutional knowledge applies within a sealed Runtime Context.

Runtime Resolution SHALL consume:

  • a Resolution Request;
  • a sealed Runtime Context;
  • one or more candidate sets;
  • applicable Constitutional Resolution Policies;
  • temporal state;
  • governance and authority;
  • evidence and provenance;
  • compatibility constraints;
  • Runtime Bundle capabilities.

Runtime Resolution SHALL produce a deterministic Resolution Outcome.

23.27.1. Resolution Targets​

Runtime Resolution MAY select:

  • Constitutional Object;
  • Constitutional Relationship;
  • Constitutional Assertion;
  • schema;
  • schema version;
  • property definition;
  • Value Provider;
  • Value Set;
  • validation rule;
  • Resolution Policy;
  • reporting profile;
  • methodology;
  • emission factor;
  • calculation model;
  • evidence source;
  • authority;
  • workflow;
  • Runtime Component;
  • Runtime Bundle;
  • publication profile;
  • localisation;
  • AI model or agent profile.

23.27.2. Resolution Request​

Every runtime resolution SHALL originate from a Resolution Request.

The request SHALL identify:

  • Resolution Request Identifier;
  • resolution target type;
  • initiating Execution Identifier;
  • Runtime Context;
  • target scope;
  • required outcome cardinality;
  • permitted strategies;
  • required assurance level;
  • required confidence;
  • fallback permission;
  • explanation requirements;
  • provenance.

23.27.3. Resolution Outcome​

A Resolution Outcome SHALL include:

  • Resolution Outcome Identifier;
  • selected candidate or candidates;
  • candidate set identity;
  • applicable CRPs;
  • strategy;
  • precedence evaluation;
  • excluded candidates;
  • rejected candidates;
  • unresolved candidates;
  • fallback status;
  • conflict status;
  • confidence where applicable;
  • qualifications;
  • Context Fingerprint;
  • temporal boundary;
  • resolver identity;
  • timestamp;
  • provenance.

23.27.4. Resolution Cardinality​

Resolution SHALL declare expected cardinality.

Supported cardinalities MAY include:

  • exactly one;
  • zero or one;
  • one or more;
  • zero or more;
  • ordered set;
  • ranked set;
  • complete partition.

A resolution producing cardinality outside the declared constraint SHALL fail validation.

23.27.5. Resolution Strategies​

Runtime Resolution MAY use strategies including:

  • exact match;
  • hierarchical resolution;
  • inheritance resolution;
  • specificity resolution;
  • precedence resolution;
  • jurisdictional resolution;
  • temporal resolution;
  • version resolution;
  • profile resolution;
  • authority resolution;
  • evidence-quality resolution;
  • compatibility resolution;
  • weighted resolution;
  • governed fallback.

The applicable strategy SHALL be selected by a Constitutional Resolution Policy.

23.27.6. Resolution Determinism​

Equivalent Resolution Requests, candidate sets, Runtime Contexts and CRP versions SHALL produce semantically equivalent Resolution Outcomes.

A resolution SHALL NOT depend on:

  • database row order;
  • graph traversal order;
  • hash-map ordering;
  • service response race;
  • undocumented scoring;
  • hidden application configuration;
  • unversioned AI judgement.

23.27.7. Resolution Lifecycle​

A Resolution Outcome MAY progress through states including:

Requested
        │
        ▼
Candidates Discovered
        │
        ▼
Policies Applied
        │
        ▼
Provisional
        │
        ├──► Conflicted
        │
        ├──► Unresolved
        │
        ▼
Validated
        │
        ▼
Final
        │
        ▼
Superseded

The lifecycle SHALL preserve all prior outcomes.

23.27.8. Provisional Resolution​

A Resolution Outcome MAY be provisional where:

  • evidence is incomplete;
  • an authority decision is pending;
  • a provisional source is permitted;
  • a fallback is temporary;
  • the context is conditionally valid;
  • a simulation profile applies.

Provisional resolution SHALL NOT be represented as final.

23.27.9. Resolution Reuse​

A prior Resolution Outcome MAY be reused only where:

  • the Context Fingerprint remains compatible;
  • the candidate set has not materially changed;
  • applicable CRPs are unchanged;
  • temporal validity remains satisfied;
  • no relevant authority or evidence has been revoked;
  • the reuse policy permits caching.

23.27.10. Resolution Invalidation​

A Resolution Outcome SHALL be invalidated where:

  • the Context Fingerprint changes materially;
  • a selected candidate is revoked or superseded;
  • a governing CRP changes;
  • temporal validity expires;
  • evidence is withdrawn;
  • a conflict is discovered;
  • authority changes;
  • the candidate set changes materially;
  • a security policy prohibits continued use.

Invalidation SHALL preserve historical traceability.

23.28. CRP Evaluation​

CRP Evaluation is the runtime execution of one or more Constitutional Resolution Policies.

CRPs SHALL determine how candidate knowledge is matched, filtered, ranked, selected, excluded, overridden or used as fallback.

A CRP SHALL itself be a governed Constitutional Object.

23.28.1. CRP Identity​

Every CRP SHALL possess:

  • Constitutional Identifier;
  • canonical name;
  • semantic definition;
  • policy type;
  • policy version;
  • governing authority;
  • applicability;
  • lifecycle;
  • temporal validity;
  • input contract;
  • output contract;
  • strategy;
  • precedence rules;
  • tie-breaking rules;
  • fallback rules;
  • validation rules;
  • provenance.

23.28.2. CRP Applicability​

Before evaluation, the runtime SHALL determine whether a CRP applies.

Applicability MAY depend upon:

  • target type;
  • tenant;
  • jurisdiction;
  • reporting framework;
  • reporting period;
  • constitutional release;
  • Runtime Bundle;
  • assurance level;
  • execution mode;
  • product classification;
  • organisation type;
  • workflow state;
  • authority.

An inapplicable CRP SHALL not influence the outcome.

23.28.3. CRP Composition​

Multiple CRPs MAY apply to one Resolution Request.

CRP Composition SHALL define:

  • evaluation order;
  • mandatory policies;
  • optional policies;
  • policy dependencies;
  • policy conflicts;
  • policy precedence;
  • aggregation method;
  • termination rules.

23.28.4. Policy Phases​

A CRP evaluation MAY contain phases such as:

Applicability
        │
        ▼
Candidate Filtering
        │
        ▼
Compatibility Evaluation
        │
        ▼
Authority Evaluation
        │
        ▼
Temporal Evaluation
        │
        ▼
Evidence Evaluation
        │
        ▼
Precedence and Specificity
        │
        ▼
Tie-breaking
        │
        ▼
Fallback
        │
        ▼
Outcome Validation

Every phase SHALL remain explainable.

23.28.5. Mandatory and Advisory CRPs​

A CRP MAY be:

  • mandatory;
  • constraining;
  • ranking;
  • advisory;
  • fallback-only;
  • simulation-only.

Advisory policies SHALL NOT override mandatory constitutional constraints.

23.28.6. CRP Inputs​

CRP inputs MAY include:

  • Runtime Context dimensions;
  • candidate metadata;
  • candidate lifecycle;
  • candidate provenance;
  • candidate authority;
  • temporal state;
  • compatibility declarations;
  • confidence;
  • evidence quality;
  • trust score;
  • tenant overlay;
  • jurisdictional hierarchy;
  • prior Resolution Outcomes.

Every input SHALL be typed and traceable.

23.28.7. CRP Output​

CRP output MAY include:

  • included candidates;
  • excluded candidates;
  • candidate scores;
  • candidate ranking;
  • selected candidate;
  • unresolved conflict;
  • fallback instruction;
  • required human decision;
  • required evidence;
  • qualification;
  • rejection.

23.28.8. Tie-breaking​

Every CRP capable of producing equal-ranked candidates SHALL define deterministic tie-breaking.

Tie-breaking MAY use:

  • greater specificity;
  • higher authority;
  • later approved version;
  • closer jurisdictional fit;
  • stronger evidence;
  • higher assurance;
  • canonical identifier ordering as final technical tie-breaker.

Canonical identifier ordering MAY be used only after all constitutional criteria are exhausted.

23.28.9. Weighted Resolution​

A weighted CRP MAY combine multiple governed criteria.

The policy SHALL define:

  • criteria;
  • weights;
  • normalization;
  • minimum thresholds;
  • missing-value treatment;
  • tie-breaking;
  • interpretability;
  • versioning.

Weighted resolution SHALL remain explainable.

A hidden machine-learning score SHALL NOT substitute for a governed weighted CRP.

23.28.10. AI-Assisted CRP Evaluation​

AI MAY assist with:

  • candidate classification;
  • similarity discovery;
  • evidence summarization;
  • anomaly detection;
  • proposed ranking;
  • conflict explanation.

AI output SHALL remain advisory unless:

  • the CRP explicitly permits AI participation;
  • the model and prompt artefacts are identified;
  • confidence and uncertainty are preserved;
  • HECATE validation applies;
  • human or constitutional approval applies where required.

23.28.11. CRP Versioning​

CRP evaluation SHALL identify the exact CRP version used.

A CRP update SHALL NOT silently alter a historical Resolution Outcome.

Historical replay SHALL use the historical CRP version unless a comparative replay explicitly requests another version.

23.28.12. CRP Validation​

HECATE SHALL validate CRPs for:

  • identity;
  • completeness;
  • deterministic behaviour;
  • unsupported inputs;
  • circular policy dependencies;
  • conflicting precedence;
  • missing tie-breaking;
  • unsafe fallback;
  • authority;
  • temporal validity;
  • tenant isolation;
  • explainability;
  • provenance.

23.29. Candidate Evaluation​

Candidate Evaluation determines which potential constitutional alternatives are eligible, compatible and sufficiently governed to participate in resolution.

A candidate SHALL NOT be selected merely because it is discoverable.

23.29.1. Candidate Set​

A Candidate Set is the governed collection of alternatives considered for a Resolution Request.

Every Candidate Set SHALL possess:

  • Candidate Set Identifier;
  • target type;
  • discovery rule;
  • scope;
  • Runtime Context;
  • creation timestamp;
  • source registries or graphs;
  • candidate identities;
  • completeness status;
  • provenance.

23.29.2. Candidate Discovery​

Candidate discovery MAY use:

  • explicit identifiers;
  • Constitutional Registries;
  • Constitutional Knowledge Graph traversal;
  • schema compatibility;
  • classification;
  • contextual matching;
  • temporal filtering;
  • authority relationships;
  • federated registries;
  • approved search indexes;
  • vector retrieval for advisory discovery.

Discovery mechanisms SHALL preserve source and scope.

Vector similarity SHALL NOT establish constitutional applicability.

23.29.3. Candidate Completeness​

The runtime SHALL determine whether the Candidate Set is:

  • complete;
  • complete within declared registries;
  • complete within tenant scope;
  • sampled;
  • federated and partially available;
  • incomplete;
  • unknown.

An incomplete Candidate Set SHALL not produce an unqualified claim that the selected candidate is globally optimal or uniquely applicable.

23.29.4. Eligibility Evaluation​

Candidate eligibility SHALL evaluate:

  • lifecycle state;
  • temporal validity;
  • tenant applicability;
  • jurisdiction applicability;
  • authority;
  • schema compatibility;
  • target-type compatibility;
  • security classification;
  • required assurance;
  • required evidence;
  • deprecation status;
  • revocation status;
  • licensing or usage restrictions.

23.29.5. Candidate Match​

A candidate MAY be matched against the Runtime Context using:

  • exact dimension equality;
  • hierarchical membership;
  • classification compatibility;
  • jurisdictional containment;
  • temporal overlap;
  • schema conformance;
  • policy-defined predicate;
  • approved semantic equivalence.

Match criteria SHALL be explicit.

23.29.6. Candidate Specificity​

Specificity measures how narrowly a candidate matches the Runtime Context.

Specificity MAY consider:

  • tenant specificity;
  • organisation specificity;
  • jurisdiction specificity;
  • framework specificity;
  • product specificity;
  • temporal specificity;
  • methodology specificity;
  • assurance specificity.

Specificity SHALL not override mandatory authority or legal applicability.

23.29.7. Candidate Authority​

Every candidate SHALL identify the authority under which it may apply.

Candidate authority MAY derive from:

  • constitutional governance;
  • regulatory issuance;
  • tenant approval;
  • organisational policy;
  • contractual agreement;
  • certification;
  • assurance approval.

Authority strength SHALL remain distinguishable from evidence quality.

23.29.8. Candidate Evidence​

Candidate evaluation MAY consider evidence such as:

  • regulatory publication;
  • certification;
  • verification;
  • scientific source;
  • audit evidence;
  • approved registry entry;
  • signed tenant policy;
  • provenance chain;
  • validation result.

Evidence SHALL be evaluated according to a governed evidence-quality policy.

23.29.9. Candidate Trust​

Trust evaluation MAY consider:

  • source identity;
  • source authority;
  • signatures;
  • provenance completeness;
  • verification status;
  • synchronisation state;
  • known disputes;
  • revocation;
  • federation trust profile.

Trust SHALL remain contextual.

23.29.10. Candidate Compatibility​

Compatibility SHALL evaluate whether a candidate can be used with:

  • the Constitutional Schema;
  • the Runtime Bundle;
  • other selected candidates;
  • the methodology;
  • the unit system;
  • the reporting framework;
  • the temporal context;
  • the assurance profile;
  • the target deployment.

Compatibility SHALL be governed rather than assumed.

23.29.11. Candidate Exclusion​

A candidate SHALL be excluded where a mandatory exclusion rule applies.

Exclusion SHALL preserve:

  • excluded candidate;
  • exclusion rule;
  • reason;
  • authority;
  • context;
  • timestamp;
  • provenance.

Excluded candidates SHALL remain visible in the Resolution Explanation where relevant.

23.29.12. Candidate Ranking​

Eligible candidates MAY be ranked.

Ranking SHALL preserve:

  • ranking criteria;
  • normalized values;
  • policy version;
  • rank;
  • ties;
  • rejected candidates;
  • confidence;
  • provenance.

23.29.13. Candidate Evaluation Result​

Each candidate SHALL receive a Candidate Evaluation Result containing:

  • candidate identity;
  • eligibility;
  • match status;
  • specificity;
  • authority;
  • temporal validity;
  • evidence quality;
  • trust;
  • compatibility;
  • exclusions;
  • score where applicable;
  • rank;
  • qualifications;
  • provenance.

23.30. Precedence​

Precedence determines which otherwise applicable candidate has constitutional priority.

Precedence SHALL be explicit, policy-governed and explainable.

Implementation order SHALL NOT establish precedence.

23.30.1. Precedence Sources​

Precedence MAY arise from:

  • constitutional authority;
  • legal hierarchy;
  • jurisdictional hierarchy;
  • tenant overlay order;
  • organisational policy;
  • specificity;
  • temporal succession;
  • explicit priority;
  • assurance status;
  • evidence quality;
  • approved override.

23.30.2. Precedence Hierarchy​

A CRP MAY define a hierarchy such as:

Mandatory Law
        │
        ▼
Applicable Regulation
        │
        ▼
Constitutional Policy
        │
        ▼
Tenant Policy
        │
        ▼
Organisation Policy
        │
        ▼
Governed Default

The hierarchy SHALL be contextual.

A tenant policy SHALL NOT override mandatory law merely because it is more specific.

23.30.3. Specificity Precedence​

More specific knowledge MAY take precedence over general knowledge where:

  • both possess valid authority;
  • the more specific candidate applies to the same target;
  • no higher-order mandatory rule prohibits it;
  • the specificity dimensions are governed;
  • the candidate remains compatible.

23.30.4. Temporal Precedence​

Temporal precedence MAY prefer:

  • currently effective knowledge;
  • the latest approved applicable version;
  • the version effective during the reporting period;
  • the transaction-time state known at a historical point.

“Latest” SHALL NOT be used without defining the applicable time dimension.

23.30.5. Authority Precedence​

Where authorities conflict, precedence SHALL follow a governed Authority Resolution Policy.

The policy MAY consider:

  • legal hierarchy;
  • delegated authority;
  • scope;
  • jurisdiction;
  • constitutional governance;
  • temporal validity.

23.30.6. Evidence Precedence​

Evidence quality MAY influence precedence only where the applicable CRP permits it.

Higher-quality evidence SHALL NOT override a mandatory legal or constitutional rule unless that rule explicitly depends upon evidence quality.

23.30.7. Precedence Ties​

A precedence tie SHALL be resolved through explicit tie-breaking.

Where no tie-breaker exists, the outcome SHALL remain conflicted or unresolved.

The runtime SHALL NOT select arbitrarily.

23.30.8. Precedence Chain​

Every final selection SHALL preserve the complete Precedence Chain.

The chain SHALL identify:

  • compared candidates;
  • precedence criteria;
  • winning criterion;
  • governing CRP;
  • rejected alternatives;
  • unresolved ties;
  • final candidate.

23.30.9. Precedence Validation​

HECATE SHALL validate:

  • missing precedence rules;
  • circular precedence;
  • illegal authority inversion;
  • tenant override of mandatory Core constraints;
  • temporal ambiguity;
  • unresolved ties;
  • inconsistent policy hierarchies.

23.31. Overrides​

An Override is an explicit, governed act that causes one applicable constitutional item to take precedence over another within a defined scope and period.

Overrides SHALL be exceptional, traceable and reversible or supersedable where possible.

An override SHALL NOT erase the overridden knowledge.

23.31.1. Override Object​

Every override SHALL be represented as a Constitutional Object or governed Constitutional Assertion.

It SHALL possess:

  • Override Identifier;
  • overriding object or authority;
  • overridden object;
  • scope;
  • context;
  • reason;
  • legal or policy basis;
  • authority;
  • start time;
  • end time;
  • lifecycle;
  • approval;
  • evidence;
  • provenance.

23.31.2. Override Types​

Override Types MAY include:

  • tenant override;
  • jurisdictional override;
  • organisational override;
  • temporal override;
  • methodology override;
  • validation override;
  • emergency override;
  • security override;
  • publication override;
  • compatibility override.

Each Override Type SHALL define permitted targets and required authority.

23.31.3. Override Eligibility​

An override SHALL be eligible only where:

  • the target is overrideable;
  • the actor possesses override authority;
  • scope is explicit;
  • purpose is legitimate;
  • temporal validity is defined;
  • mandatory higher-order constraints remain satisfied;
  • required approval exists;
  • evidence and rationale are sufficient.

23.31.4. Non-Overrideable Constraints​

The Constitution MAY declare constraints that cannot be overridden.

These MAY include:

  • Constitutional Identity;
  • tenant isolation;
  • mandatory legal prohibitions;
  • mandatory provenance retention;
  • required separation of duties;
  • required disclosure of uncertainty;
  • prohibition on representing AI-proposed assertions as canonical;
  • prohibition on silent semantic loss.

23.31.5. Override Scope​

Override scope MAY be limited by:

  • tenant;
  • organisation;
  • jurisdiction;
  • Constitutional Object;
  • Relationship Type;
  • schema;
  • reporting period;
  • workflow;
  • publication;
  • Component;
  • execution mode.

An override SHALL NOT apply outside its explicit scope.

23.31.6. Override Duration​

Every override SHALL define:

  • effective start;
  • effective end or review date;
  • transaction-time activation;
  • expiration behaviour;
  • renewal rules.

Indefinite overrides SHOULD require heightened governance and periodic review.

23.31.7. Override Approval​

Overrides MAY require multi-party approval.

Approval SHALL preserve:

  • approver identity;
  • authority;
  • separation-of-duties compliance;
  • conditions;
  • timestamp;
  • evidence;
  • provenance.

23.31.8. Override Application​

When an override applies, the Resolution Outcome SHALL identify:

  • base candidate;
  • overriding candidate;
  • override object;
  • governing authority;
  • reason;
  • scope;
  • temporal period;
  • effect;
  • qualifications.

23.31.9. Override Revocation​

An override MAY be revoked.

Revocation SHALL:

  • identify the revoking authority;
  • preserve the original override;
  • define the revocation time;
  • trigger affected resolution invalidation;
  • preserve provenance;
  • support downstream impact analysis.

23.31.10. Emergency Override​

Emergency overrides SHALL:

  • be explicitly classified;
  • have narrow scope;
  • have short duration;
  • preserve controls bypassed;
  • define compensating controls;
  • require retrospective review;
  • expire automatically.

23.31.11. Override Audit​

Pergamum Pulse SHOULD analyse override activity for:

  • frequency;
  • authority concentration;
  • repeated emergency use;
  • tenant divergence;
  • regulatory risk;
  • validation bypass patterns;
  • stale overrides;
  • expired overrides still influencing outcomes.

Derived findings SHALL remain Intelligence Layer assertions until governed activation.

23.32. Fallback​

Fallback is the governed selection of a secondary candidate where the preferred candidate is unavailable, invalid, incompatible or otherwise unusable.

Fallback SHALL be explicit and SHALL never conceal degraded quality or applicability.

23.32.1. Fallback Chain​

A CRP MAY define an ordered Fallback Chain.

Example:

Tenant-approved Dataset
        │
        ▼
Jurisdiction-approved Dataset
        │
        ▼
Framework Default Dataset
        │
        ▼
Global Default Dataset

Each step SHALL define entry conditions and qualifications.

23.32.2. Fallback Eligibility​

Fallback MAY occur where:

  • no preferred candidate exists;
  • the preferred candidate is unavailable;
  • the preferred candidate is temporally invalid;
  • the preferred candidate fails validation;
  • the preferred candidate is incompatible;
  • the preferred candidate lacks required evidence;
  • the preferred source exceeds a permitted latency threshold;
  • policy explicitly permits fallback.

23.32.3. Prohibited Fallback​

Fallback SHALL be prohibited where:

  • mandatory law requires a specific source;
  • the assurance profile prohibits substitution;
  • a security policy prohibits the secondary source;
  • the fallback would cross tenant boundaries;
  • the fallback would materially change methodology without disclosure;
  • no candidate meets minimum evidence quality;
  • the requested cardinality cannot be satisfied.

23.32.4. Fallback Qualification​

Every fallback outcome SHALL be qualified.

Qualifications MAY include:

  • lower evidence quality;
  • broader geographic scope;
  • older version;
  • provisional status;
  • estimated value;
  • reduced assurance;
  • methodological substitution;
  • increased uncertainty.

23.32.5. Fallback Provenance​

Fallback provenance SHALL identify:

  • preferred candidate;
  • reason it was unusable;
  • selected fallback;
  • fallback chain position;
  • governing CRP;
  • qualification;
  • timestamp;
  • provenance.

23.32.6. Temporary Fallback​

A temporary fallback SHALL define:

  • expiration;
  • retry or refresh policy;
  • preferred-source monitoring;
  • replacement trigger;
  • downstream re-evaluation requirement.

23.32.7. Fallback Recovery​

When the preferred candidate becomes available, the runtime SHALL determine whether:

  • future executions use the preferred candidate;
  • prior outcomes require recalculation;
  • reports require correction;
  • assurance conclusions require review;
  • cached Resolution Outcomes require invalidation.

23.32.8. Fallback Depth​

Fallback depth SHALL be bounded.

Unbounded fallback chains SHALL be prohibited.

A fallback loop SHALL be treated as a critical Resolution Policy defect.

23.32.9. Fallback Metrics​

Runtime observability MAY track:

  • fallback frequency;
  • fallback depth;
  • fallback duration;
  • affected tenants;
  • affected methodologies;
  • affected reports;
  • quality degradation;
  • unresolved preferred-source failures.

Operational metrics SHALL not redefine fallback semantics.

23.33. Conflict Resolution​

A Resolution Conflict occurs where two or more candidates, policies, authorities, contexts or constraints cannot simultaneously determine one valid outcome.

Conflicts SHALL be represented explicitly.

The runtime SHALL NOT conceal a conflict by choosing the first technically available candidate.

23.33.1. Conflict Types​

Conflict Types MAY include:

  • candidate conflict;
  • policy conflict;
  • authority conflict;
  • jurisdiction conflict;
  • temporal conflict;
  • version conflict;
  • methodology conflict;
  • evidence conflict;
  • schema conflict;
  • tenant-overlay conflict;
  • security conflict;
  • assurance conflict;
  • cardinality conflict.

23.33.2. Conflict Object​

Every material conflict SHOULD be represented as a governed Conflict Object.

The Conflict Object SHALL include:

  • Conflict Identifier;
  • conflict type;
  • involved candidates;
  • involved CRPs;
  • Runtime Context;
  • severity;
  • detected time;
  • detecting Component;
  • affected scope;
  • resolution status;
  • required authority;
  • evidence;
  • provenance.

23.33.3. Conflict Detection​

Conflicts MAY be detected during:

  • Context Assembly;
  • Context Validation;
  • candidate discovery;
  • candidate evaluation;
  • CRP composition;
  • precedence evaluation;
  • override application;
  • fallback;
  • outcome validation;
  • replay.

23.33.4. Conflict Severity​

Conflict severity MAY be:

  • informational;
  • minor;
  • material;
  • critical;
  • blocking.

Blocking conflicts SHALL prevent authoritative resolution.

23.33.5. Automated Conflict Resolution​

A conflict MAY be resolved automatically only where an applicable CRP defines:

  • the conflict type;
  • the permitted strategy;
  • authority;
  • deterministic criteria;
  • tie-breaking;
  • required evidence;
  • explanation requirements.

23.33.6. Human Conflict Resolution​

A conflict requiring human judgement SHALL generate a governed decision task.

The task SHALL identify:

  • decision authority;
  • conflict scope;
  • candidates;
  • policies;
  • evidence;
  • deadlines;
  • permitted decisions;
  • required rationale;
  • appeal or review path.

23.33.7. Authority Conflict​

Where authorities conflict, the runtime SHALL evaluate:

  • constitutional hierarchy;
  • legal hierarchy;
  • jurisdiction;
  • delegation;
  • scope;
  • temporal validity;
  • separation of duties.

An unresolved authority conflict SHALL block authoritative resolution.

23.33.8. Jurisdiction Conflict​

Jurisdiction conflict MAY occur where multiple jurisdictions impose incompatible requirements.

Resolution MAY produce:

  • one jurisdiction selected;
  • multiple parallel obligations;
  • the stricter common requirement;
  • a qualified outcome;
  • a required legal decision;
  • exclusion of the operation.

The strategy SHALL be governed and shall not be assumed.

23.33.9. Temporal Conflict​

Temporal conflict MAY occur where:

  • candidate versions overlap;
  • effective and valid times disagree;
  • regulatory issuance postdates the reporting period;
  • transaction-time knowledge differs from later knowledge.

The Resolution Outcome SHALL identify which time dimension governed the decision.

23.33.10. Evidence Conflict​

Conflicting evidence SHALL remain visible.

The runtime MAY resolve evidence conflict using:

  • source authority;
  • verification status;
  • recency within the correct temporal model;
  • scientific quality;
  • assurance level;
  • chain of custody;
  • independence.

The losing evidence SHALL not be deleted.

23.33.11. Conflict Resolution Outcome​

A Conflict Resolution Outcome SHALL preserve:

  • conflict;
  • strategy;
  • authority;
  • selected decision;
  • rejected alternatives;
  • conditions;
  • rationale;
  • evidence;
  • temporal validity;
  • review date;
  • provenance.

23.33.12. Unresolved Conflict​

An unresolved conflict SHALL produce one of:

  • blocked execution;
  • suspended execution;
  • provisional outcome;
  • qualified advisory outcome;
  • human decision task;
  • escalation.

An unresolved conflict SHALL not be represented as final certainty.

23.33.13. Conflict Reopening​

A resolved conflict MAY be reopened where:

  • new evidence appears;
  • authority changes;
  • a CRP changes;
  • temporal applicability changes;
  • a selected candidate is revoked;
  • an appeal succeeds;
  • a material defect is discovered.

Reopening SHALL preserve the prior decision.

23.33.14. Conflict Impact Analysis​

The runtime SHALL support impact analysis for conflicts affecting:

  • downstream Resolution Outcomes;
  • calculations;
  • validations;
  • reports;
  • disclosures;
  • publications;
  • assurance conclusions;
  • workflows;
  • AI knowledge retrieval.

23.34. Resolution Explanations​

A Resolution Explanation is the machine-readable and human-readable account of how a Runtime Resolution produced its outcome.

Every authoritative Resolution Outcome SHALL be explainable.

The explanation SHALL expose constitutional reasoning without exposing protected information beyond the recipient’s authority.

23.34.1. Explanation Purpose​

Resolution Explanations SHALL support:

  • operational transparency;
  • developer diagnostics;
  • user trust;
  • auditor review;
  • assurance;
  • regulatory review;
  • dispute resolution;
  • AI explainability;
  • deterministic replay;
  • policy improvement.

23.34.2. Explanation Content​

A complete Resolution Explanation SHALL identify:

  • Resolution Request;
  • Runtime Context;
  • Context Fingerprint;
  • candidate discovery scope;
  • candidate set;
  • Candidate Set completeness;
  • applicable CRPs;
  • policy versions;
  • evaluation phases;
  • included candidates;
  • excluded candidates;
  • rejected candidates;
  • candidate scores or ranks;
  • precedence chain;
  • override use;
  • fallback use;
  • conflicts;
  • selected outcome;
  • qualifications;
  • temporal boundary;
  • authority;
  • evidence;
  • resolver Component;
  • Runtime Bundle;
  • provenance.

23.34.3. Explanation Layers​

Explanations SHOULD support layers including:

LayerIntended Audience
Summary ExplanationEnd users and decision-makers
Policy ExplanationGovernance, compliance and legal users
Technical ExplanationDevelopers and runtime operators
Assurance ExplanationAuditors and verifiers
Machine ExplanationAPIs, agents and automated controls
Forensic ExplanationIncident investigators and dispute reviewers

Each layer SHALL preserve the same constitutional outcome.

23.34.4. Candidate Explanation​

For every material candidate, the explanation SHOULD state:

  • why it was discovered;
  • whether it was eligible;
  • how it matched context;
  • its authority;
  • its temporal validity;
  • its evidence quality;
  • its compatibility;
  • why it was selected, rejected or excluded.

23.34.5. Policy Explanation​

The explanation SHALL identify how each applicable CRP influenced the outcome.

It SHALL distinguish:

  • policies that filtered candidates;
  • policies that ranked candidates;
  • policies that established precedence;
  • policies that authorised override;
  • policies that permitted fallback;
  • policies that required human decision.

23.34.6. Explanation of Non-selection​

A user or auditor SHALL be able to determine why an apparently relevant candidate was not selected.

Non-selection reasons MAY include:

  • inapplicable context;
  • insufficient authority;
  • temporal invalidity;
  • incompatible schema;
  • insufficient evidence;
  • lower precedence;
  • explicit exclusion;
  • revoked status;
  • tenant mismatch;
  • security restriction.

23.34.7. Explanation of Uncertainty​

Where uncertainty affects resolution, the explanation SHALL identify:

  • uncertainty source;
  • affected candidates;
  • confidence;
  • assumptions;
  • missing evidence;
  • provisional status;
  • sensitivity to alternative inputs.

23.34.8. Explanation of Fallback​

A fallback explanation SHALL identify:

  • preferred candidate;
  • reason for preferred-candidate failure;
  • selected fallback;
  • quality or assurance degradation;
  • expected duration;
  • recovery path.

23.34.9. Explanation of Override​

An override explanation SHALL identify:

  • base outcome;
  • overriding authority;
  • override object;
  • reason;
  • scope;
  • duration;
  • approvals;
  • controls affected;
  • review requirements.

23.34.10. Explanation of Conflict​

A conflict explanation SHALL identify:

  • conflicting candidates or policies;
  • conflict type;
  • severity;
  • strategy;
  • authority;
  • outcome;
  • unresolved elements;
  • escalation path.

23.34.11. Explainability and Security​

Resolution Explanations SHALL respect:

  • tenant isolation;
  • access control;
  • confidentiality;
  • personal-data minimisation;
  • legal privilege;
  • trade-secret protection;
  • security classification.

Redaction SHALL preserve the existence and effect of hidden material where disclosure is prohibited.

23.34.12. Explanation Determinism​

Equivalent Resolution Outcomes SHOULD produce semantically equivalent explanations.

Presentation differences MAY occur by language, audience and disclosure profile, but the underlying reasoning graph SHALL remain stable.

23.34.13. Explanation Identifier​

Every authoritative Resolution Explanation SHALL possess:

  • Explanation Identifier;
  • Resolution Outcome Identifier;
  • explanation profile;
  • language;
  • audience;
  • disclosure profile;
  • generation Component;
  • generation timestamp;
  • Runtime Bundle;
  • Context Fingerprint;
  • integrity metadata;
  • provenance.

23.34.14. Explanation Validation​

HECATE SHALL validate Resolution Explanations for:

  • outcome consistency;
  • policy completeness;
  • candidate traceability;
  • precedence traceability;
  • override disclosure;
  • fallback disclosure;
  • conflict disclosure;
  • qualification disclosure;
  • temporal consistency;
  • security compliance;
  • provenance completeness.

23.34.15. Resolution Replay​

The explanation and provenance SHALL permit replay of the resolution decision.

Replay SHALL identify:

  • the original candidate set;
  • the original CRPs;
  • the original Context Fingerprint;
  • the original temporal boundary;
  • the original policy order;
  • the original outcome.

23.34.16. Pergamum Pulse Integration​

Pergamum Pulse MAY analyse Context and Resolution Runtime data to identify:

  • unstable context dimensions;
  • frequent context conflicts;
  • excessive use of defaults;
  • fallback concentration;
  • override concentration;
  • unresolved candidate ambiguity;
  • policy gaps;
  • jurisdictional divergence;
  • tenant divergence;
  • stale Resolution Outcomes;
  • low-quality evidence patterns;
  • high-impact resolution dependencies.

Pergamum Pulse SHALL preserve:

  • Module lineage;
  • Component lineage;
  • Context lineage;
  • CRP lineage;
  • candidate lineage;
  • Resolution Outcome lineage;
  • temporal validity;
  • provenance;
  • tenant isolation.

Derived insights SHALL remain Intelligence Layer assertions until governed activation.

Part III Conformance​

A Constitutional Runtime Framework implementation conforms to Part III where it:

  1. assembles every authoritative Runtime Context from identifiable governed sources;
  2. prohibits hidden application defaults from becoming constitutional context;
  3. supports explicit context composition, inheritance, override and conflict handling;
  4. validates context completeness, coherence, authority, temporal applicability and tenant isolation;
  5. seals authoritative Runtime Contexts before execution;
  6. produces deterministic Context Fingerprints from normalized constitutional meaning;
  7. performs resolution through explicit Constitutional Resolution Policies;
  8. creates identifiable Candidate Sets and records their completeness;
  9. evaluates candidate eligibility, specificity, authority, evidence, trust and compatibility;
  10. applies explicit precedence and deterministic tie-breaking;
  11. represents overrides as governed, scoped and temporally bounded constitutional acts;
  12. permits fallback only through explicit policy and discloses resulting degradation;
  13. represents and governs conflicts rather than resolving them silently;
  14. produces machine-readable and human-readable Resolution Explanations;
  15. preserves complete context, candidate, policy, authority, temporal and provenance lineage;
  16. preserves both Module and Component lineage in Pergamum Pulse;
  17. prevents unresolved or materially ambiguous resolution from appearing final and authoritative.

Part III Foundational Principle​

Context and Resolution Runtime is the governed decision layer through which ZAYAZ determines the conditions under which constitutional knowledge is interpreted and which constitutional knowledge applies within those conditions.

Context SHALL be assembled from identifiable Constitutional Contexts, inheritance relationships, governed defaults and explicit request dimensions. It SHALL be validated, sealed and fingerprinted before authoritative execution. Resolution SHALL evaluate complete or explicitly qualified Candidate Sets through versioned Constitutional Resolution Policies that preserve applicability, authority, specificity, precedence, temporal validity, evidence, compatibility, override, fallback and conflict handling.

No runtime decision SHALL depend upon hidden defaults, database ordering, implicit precedence, undocumented scoring or arbitrary selection. Every resolved outcome SHALL remain deterministic, reproducible, explainable and fully traceable to its Runtime Context, Candidate Set, CRPs, authority, evidence, Runtime Bundle, Module lineage and Component lineage.



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