Chapter 23 — Constitutional Runtime Framework
Part V — Reasoning Runtime
The Reasoning Runtime is the governed constitutional runtime through which ZAYAZ derives new assertions, conclusions, classifications, implications and explanations from explicit Constitutional Objects, Constitutional Relationships, Constitutional Assertions, evidence, validated runtime state and applicable Inference Rules.
Reasoning SHALL be treated as a distinct constitutional process.
It SHALL remain separate from:
- resolution, which determines which constitutional knowledge applies;
- validation, which determines whether a subject conforms;
- computation, which transforms numerical or symbolic inputs according to a defined method;
- workflow, which coordinates state transitions and actions;
- AI generation, which proposes content or hypotheses without constitutional authority by default.
The governing distinction is:
Resolution selects applicable knowledge. Validation evaluates conformance. Computation calculates outcomes. Reasoning derives implications.
Conceptually:
Explicit Constitutional Knowledge
│
├── Constitutional Objects
├── Constitutional Relationships
├── Constitutional Assertions
├── Evidence
├── Validated Runtime Outcomes
└── Context
│
▼
Reasoning Profile Resolution
│
▼
Reasoning Plan
│
├── Inference Rule Resolution
├── Premise Resolution
├── Temporal Evaluation
├── Authority Evaluation
├── Confidence Evaluation
└── Contradiction Evaluation
│
▼
Reasoning Engine
│
▼
Derived Assertions
│
├── Entailed
├── Inferred
├── Hypothesised
├── Predicted
├── Refuted
├── Contested
└── Indeterminate
│
▼
HECATE Validation
│
▼
Reasoning Provenance and Explanation
The Reasoning Runtime SHALL preserve the distinction between explicit knowledge and derived knowledge at all times.
A derived assertion SHALL NOT become canonical merely because it was produced by a reasoning engine.
23.47. Constitutional Reasoning
Constitutional Reasoning is the governed process of deriving one or more new assertions from explicit or previously derived knowledge through identifiable Inference Rules within an explicit Runtime Context.
Every authoritative reasoning execution SHALL be represented as a specialised Constitutional Execution.
23.47.1. Purpose
Constitutional Reasoning MAY support:
- applicability derivation;
- classification;
- obligation derivation;
- dependency inference;
- impact propagation;
- risk propagation;
- control inference;
- report completeness analysis;
- supply-chain relationship inference;
- product and component lineage inference;
- temporal implication;
- governance implication;
- evidence implication;
- policy implication;
- anomaly interpretation;
- assurance support;
- explanation generation;
- scenario analysis;
- hypothesis generation.
23.47.2. Reasoning Request
Every reasoning execution SHALL originate from a Reasoning Request identifying:
- Reasoning Request Identifier;
- purpose;
- initiating actor or Component;
- authority;
- Runtime Context;
- Context Fingerprint;
- target subject or query;
- requested Reasoning Profile;
- requested scope;
- knowledge snapshot;
- permitted Inference Rule families;
- permitted sources of uncertainty;
- requested outcome type;
- execution mode;
- side-effect policy;
- provenance.
23.47.3. Reasoning Subject
A Reasoning Subject MAY be:
- a Constitutional Object;
- a Constitutional Relationship;
- a Constitutional Assertion;
- a graph node or subgraph;
- a report;
- a disclosure;
- a product;
- an organisation;
- a facility;
- a supplier network;
- a methodology;
- a risk;
- a control;
- a finding;
- a scenario;
- a question expressed through a governed query object.
23.47.4. Knowledge Snapshot
Authoritative reasoning SHALL operate against an identifiable Knowledge Snapshot.
The snapshot SHALL preserve:
- Constitutional Knowledge Graph release or snapshot;
- applicable Runtime Bundle;
- explicit assertions;
- accepted derived assertions;
- evidence state;
- temporal boundary;
- tenant boundary;
- jurisdictional boundary;
- inference rule versions;
- trust state;
- snapshot fingerprint;
- provenance.
Reasoning against mutable unversioned knowledge SHALL be explicitly qualified.
23.47.5. Reasoning Plan
A Reasoning Plan SHALL define:
- reasoning purpose;
- scope;
- Reasoning Profile;
- premise sources;
- applicable Inference Rules;
- rule dependencies;
- execution order;
- reasoning mode;
- world assumption;
- contradiction strategy;
- uncertainty strategy;
- termination conditions;
- maximum depth;
- maximum iterations;
- resource constraints;
- validation gates;
- explanation requirements;
- provenance requirements.
23.47.6. Reasoning Plan Validation
HECATE SHALL validate the Reasoning Plan for:
- request-plan consistency;
- context compatibility;
- rule applicability;
- rule completeness;
- cycle safety;
- authority;
- tenant isolation;
- temporal consistency;
- contradiction policy;
- uncertainty policy;
- termination guarantees;
- Component capability;
- provenance completeness.
23.47.7. Reasoning Modes
Reasoning Modes MAY include:
- authoritative;
- advisory;
- exploratory;
- simulation;
- assurance;
- forensic;
- replay;
- continuous;
- AI-assisted.
Only an authorised profile MAY produce assertions eligible for constitutional activation.
23.47.8. Reasoning Engines
A Reasoning Engine SHALL declare:
- engine identity;
- Component identity;
- Module lineage;
- supported logic families;
- supported world assumptions;
- supported uncertainty models;
- supported contradiction strategies;
- deterministic guarantees;
- termination guarantees;
- scalability limits;
- explanation capabilities;
- version;
- security profile;
- provenance.
A technical reasoning engine SHALL NOT become constitutionally authoritative merely because it can derive a conclusion.
23.47.9. Reasoning Strategies
Strategies MAY include:
- forward chaining;
- backward chaining;
- goal-directed reasoning;
- graph traversal;
- rule-based classification;
- constraint reasoning;
- abductive reasoning;
- defeasible reasoning;
- probabilistic reasoning;
- temporal reasoning;
- hybrid reasoning.
The selected strategy SHALL be governed by the Reasoning Profile.
23.47.10. Reasoning Termination
Every Reasoning Plan SHALL define termination conditions.
Termination MAY depend upon:
- goal satisfaction;
- fixed point;
- maximum depth;
- maximum iterations;
- resource limit;
- confidence threshold;
- contradiction threshold;
- timeout;
- human decision gate.
Unbounded reasoning SHALL be prohibited for authoritative execution.
23.47.11. Side Effects
Reasoning SHOULD be side-effect free by default.
A reasoning execution MAY propose:
- Derived Assertions;
- findings;
- remediation suggestions;
- workflow actions;
- candidate classifications;
- candidate obligations;
- candidate relationships.
A separate governed execution SHALL be required to activate, publish or otherwise commit those proposals where side effects are constitutionally significant.
23.47.12. Reasoning Lifecycle
A reasoning execution MAY progress through:
Requested
│
▼
Admitted
│
▼
Planned
│
▼
Premises Resolved
│
▼
Rules Resolved
│
▼
Reasoning
│
├──► Suspended
├──► Contradicted
├──► Indeterminate
└──► Failed
│
▼
Derived Assertions Produced
│
▼
Validated
│
▼
Explained
│
▼
Completed
23.48. Reasoning Profiles
A Reasoning Profile is the governed Constitutional Object defining the reasoning semantics, rule families, world assumptions, contradiction handling, uncertainty treatment, scope and activation policy applicable to a reasoning purpose.
23.48.1. Profile Identity
Every Reasoning Profile SHALL possess:
- Constitutional Identifier;
- canonical name;
- semantic definition;
- profile type;
- governing authority;
- applicability;
- lifecycle;
- version;
- temporal validity;
- permitted rule families;
- prohibited rule families;
- world assumption;
- contradiction strategy;
- uncertainty strategy;
- activation policy;
- validation policy;
- explanation policy;
- provenance.
23.48.2. Profile Types
Reasoning Profile Types MAY include:
- constitutional entailment;
- governance implication;
- regulatory applicability;
- reporting obligation;
- materiality reasoning;
- risk reasoning;
- control reasoning;
- supply-chain reasoning;
- product lineage reasoning;
- assurance reasoning;
- temporal reasoning;
- impact analysis;
- scenario reasoning;
- anomaly interpretation;
- AI-assisted hypothesis generation.
23.48.3. Profile Resolution
CRP SHALL resolve the applicable Reasoning Profile using:
- reasoning purpose;
- subject type;
- tenant;
- jurisdiction;
- reporting framework;
- constitutional release;
- execution mode;
- assurance level;
- security profile;
- requested outcome type.
The Reasoning Runtime SHALL NOT select a profile through hidden application logic.
23.48.4. Profile Composition
A Reasoning Profile MAY compose other profiles.
Example:
ESRS Obligation Reasoning Profile
│
├── Core Constitutional Entailment
├── Jurisdiction Applicability
├── ESRS Version Reasoning
├── Materiality Reasoning
├── Temporal Reasoning
└── Explanation Profile
Composition SHALL define precedence, conflict handling, rule compatibility and activation semantics.
23.48.5. Profile Inheritance
A specialised profile MAY inherit from a parent profile.
Inheritance SHALL NOT silently weaken mandatory parent restrictions.
23.48.6. Profile Overlays
Reasoning Profile overlays MAY be:
- Core;
- white-label base;
- tenant;
- jurisdictional;
- organisational;
- assurance-specific;
- experimental.
Tenant overlays MAY add specialised rules but SHALL NOT redefine Core constitutional semantics.
23.48.7. World Assumption Declaration
Every Reasoning Profile SHALL declare whether each reasoning domain uses:
- open-world reasoning;
- closed-world reasoning;
- locally closed-world reasoning;
- hybrid reasoning.
The declaration MAY differ by predicate, relationship family, registry or scope.
23.48.8. Monotonicity Declaration
Every profile SHALL declare whether reasoning is:
- monotonic;
- non-monotonic;
- defeasible;
- mixed by rule family.
23.48.9. Activation Policy
The profile SHALL define whether a Derived Assertion is:
- advisory only;
- eligible for automated activation;
- eligible after HECATE validation;
- eligible after human approval;
- eligible after assurance;
- prohibited from activation;
- simulation-only.
23.48.10. Profile Validation
HECATE SHALL validate Reasoning Profiles for:
- identity;
- completeness;
- deterministic semantics;
- rule compatibility;
- contradiction policy;
- uncertainty policy;
- termination policy;
- tenant isolation;
- activation safety;
- explanation completeness;
- provenance.
23.49. Inference Rules
An Inference Rule is the governed Constitutional Object defining how one or more premises may produce one or more conclusions.
Inference Rules SHALL remain independent of any particular reasoning language or engine.
23.49.1. Rule Identity
Every Inference Rule SHALL possess:
- Constitutional Identifier;
- canonical name;
- semantic definition;
- rule family;
- premise pattern;
- conclusion pattern;
- variables;
- guards;
- applicability;
- governing authority;
- lifecycle;
- version;
- temporal validity;
- priority;
- defeasibility;
- exceptions;
- confidence policy;
- explanation template;
- compiler mappings;
- provenance.
23.49.2. Premises
Premises MAY reference:
- explicit assertions;
- validated Derived Assertions;
- Constitutional Relationships;
- object properties;
- graph paths;
- evidence states;
- validation outcomes;
- resolution outcomes;
- computation outcomes;
- temporal conditions;
- context dimensions;
- absence conditions where closed-world reasoning applies.
23.49.3. Conclusions
A conclusion MAY produce:
- a Derived Assertion;
- a classification;
- an inferred relationship;
- an applicability conclusion;
- an obligation;
- a prohibition;
- a risk implication;
- a control implication;
- a validation finding candidate;
- a workflow action candidate;
- a contradiction;
- an explanation element.
23.49.4. Rule Guards
Guards MAY constrain a rule by:
- tenant;
- jurisdiction;
- reporting framework;
- reporting period;
- object type;
- relationship type;
- lifecycle;
- evidence quality;
- assurance level;
- authority;
- confidence;
- temporal interval;
- execution mode.
23.49.5. Rule Variables
Variables SHALL be typed and SHALL declare permitted bindings.
Unbounded variables SHALL be prohibited where they can create uncontrolled traversal or cross-tenant leakage.
23.49.6. Rule Priority
Rule priority SHALL be governed.
Priority MAY consider:
- legal hierarchy;
- constitutional authority;
- specificity;
- temporal applicability;
- rule version;
- explicit priority;
- defeasibility.
Implementation evaluation order SHALL NOT establish constitutional priority.
23.49.7. Rule Dependencies
Inference Rules MAY depend on other rules.
Dependencies SHALL be represented in a Rule Dependency Graph.
HECATE SHALL detect:
- missing dependencies;
- circular dependencies;
- incompatible versions;
- unresolved conflicts;
- unsafe recursive rules;
- non-terminating rule sets.
23.49.8. Recursive Rules
Recursive rules MAY be permitted where:
- the recursion is semantically valid;
- termination is guaranteed or bounded;
- the reasoning profile permits recursion;
- provenance preserves each derivation step;
- resource limits are defined.
23.49.9. Defeasible Rules
A defeasible rule produces a conclusion that may be defeated by a higher-priority rule, exception or contrary evidence.
The rule SHALL identify:
- defeat conditions;
- exception conditions;
- competing rule families;
- priority policy;
- restoration conditions;
- provenance.
23.49.10. Rule Compilation
The Constitutional Compiler Framework MAY compile Inference Rules into:
- rule-engine artefacts;
- graph queries;
- Datalog;
- SPARQL rules;
- OWL axioms;
- decision tables;
- code modules;
- event rules;
- reasoning service definitions.
Compiled artefacts SHALL preserve rule identity and semantic-loss declarations.
23.49.11. Rule Validation
HECATE SHALL validate rules for:
- syntactic completeness;
- semantic completeness;
- variable safety;
- scope safety;
- authority;
- temporal validity;
- contradiction handling;
- termination;
- determinism;
- tenant isolation;
- explanation support;
- provenance.
23.49.12. Rule Versioning
Historical reasoning SHALL use the rule versions applicable to the historical Knowledge Snapshot.
A new rule version SHALL NOT silently reinterpret prior Derived Assertions.
23.50. Open-World Reasoning
Open-World Reasoning assumes that absence of known evidence does not establish falsity.
Under an open-world assumption:
Not known to be true
≠
Known to be false
Open-world reasoning SHOULD be the default for incomplete, federated, external and evolving constitutional knowledge unless a governed profile declares otherwise.
23.50.1. Appropriate Domains
Open-world reasoning MAY apply to:
- external regulatory knowledge;
- scientific knowledge;
- supply-chain discovery;
- federated registries;
- stakeholder information;
- evidence discovery;
- product lineage;
- geography knowledge;
- risk knowledge;
- incomplete organisational data.
23.50.2. Unknown State
The runtime SHALL represent Unknown explicitly.
Unknown SHALL remain distinct from:
- false;
- not applicable;
- not evaluated;
- unavailable;
- redacted;
- disputed;
- prohibited.
23.50.3. Absence of Relationship
The absence of a Constitutional Relationship SHALL NOT prove that the relationship does not exist unless the applicable profile declares the relationship domain closed.
23.50.4. Negative Assertions
A negative assertion SHALL require explicit support.
Examples include:
- explicitly does not apply;
- explicitly is not owned by;
- explicitly is not certified by;
- explicitly does not contain;
- explicitly is not equivalent to.
Negative assertions SHALL preserve authority, context, temporal validity and provenance.
23.50.5. Federated Knowledge
Open-world reasoning SHALL account for incomplete federation.
A missing candidate from one federated source SHALL NOT establish global absence.
23.50.6. Open-World Validation
HECATE SHALL detect rules that incorrectly infer falsity from absence in an open-world domain.
23.50.7. Explanation
An explanation SHALL state when a conclusion remains unknown because the world is open or the knowledge snapshot is incomplete.
23.51. Closed-World Reasoning
Closed-World Reasoning assumes that, within an explicitly bounded and complete domain, absence may establish falsity or non-membership.
Closed-world reasoning SHALL be permitted only where completeness is governed and verifiable.
23.51.1. Appropriate Domains
Closed-world reasoning MAY apply to:
- controlled enumerations;
- complete tenant registries;
- approved workflow states;
- Runtime Bundle contents;
- Validation Rule Sets;
- complete access-control lists;
- complete reporting checklists;
- complete schema property sets;
- explicitly closed graph partitions.
23.51.2. Closure Declaration
A closed domain SHALL declare:
- Closure Identifier;
- domain scope;
- owner;
- completeness authority;
- closure time;
- applicable context;
- temporal validity;
- permitted absence inferences;
- refresh policy;
- provenance.
23.51.3. Local Closed World
A Reasoning Profile MAY declare a locally closed-world assumption for selected predicates, registries or graph partitions while retaining open-world reasoning elsewhere.
23.51.4. Completeness Validation
HECATE SHALL validate that the domain is complete for the intended purpose before absence-based inference is permitted.
23.51.5. Closure Expiration
A closure declaration MAY expire when:
- the source changes;
- the reporting period changes;
- federation becomes stale;
- a registry is incomplete;
- authority expires;
- the tenant overlay changes.
Expired closure SHALL invalidate absence-based Derived Assertions.
23.51.6. Closed-World Risks
The runtime SHALL protect against:
- treating incomplete registries as complete;
- assuming missing evidence means no evidence exists;
- assuming missing suppliers means no suppliers exist;
- assuming missing relationships mean non-relationship;
- carrying closure across tenants;
- carrying closure across periods;
- using stale snapshots.
23.51.7. Explanation
Every absence-based conclusion SHALL identify the closure declaration that permitted the inference.
23.52. Non-Monotonic Reasoning
Non-Monotonic Reasoning permits a conclusion to be withdrawn, defeated, qualified or superseded when new knowledge becomes available.
Non-monotonic reasoning SHALL be governed explicitly.
23.52.1. Monotonic and Non-Monotonic Distinction
In monotonic reasoning, adding premises does not invalidate prior conclusions.
In non-monotonic reasoning, new premises MAY invalidate or qualify a prior conclusion.
23.52.2. Appropriate Uses
Non-monotonic reasoning MAY apply to:
- regulatory applicability;
- exceptions;
- overrides;
- fallback;
- risk assessment;
- assurance conclusions;
- incomplete evidence;
- provisional classifications;
- changing supply-chain knowledge;
- temporary governance decisions;
- AI-assisted hypotheses.
23.52.3. Defeaters
A conclusion MAY be defeated by:
- higher-priority rule;
- explicit exception;
- contrary evidence;
- authority change;
- context change;
- temporal change;
- rule revocation;
- closure invalidation;
- contradiction;
- assurance limitation.
23.52.4. Truth Maintenance
The Reasoning Runtime SHALL maintain dependencies between Derived Assertions and their supporting premises.
When a premise changes, the runtime SHALL determine affected:
- Derived Assertions;
- dependent rules;
- downstream calculations;
- validation outcomes;
- reports;
- disclosures;
- workflows;
- assurance conclusions.
23.52.5. Retraction
Retraction SHALL preserve:
- retracted assertion;
- original derivation;
- retraction reason;
- defeating knowledge;
- authority;
- timestamp;
- downstream impact;
- provenance.
Retraction SHALL NOT erase historical visibility.
23.52.6. Revision
A Derived Assertion MAY be revised through:
- qualification;
- confidence change;
- scope reduction;
- temporal restriction;
- replacement;
- supersession;
- dispute;
- revocation.
23.52.7. Stable and Unstable Conclusions
The runtime MAY classify conclusions as:
- stable;
- defeasible;
- provisional;
- contested;
- expired;
- retracted.
23.52.8. Non-Monotonic Determinism
Given the same premises, rule priorities, exceptions, context and temporal state, the runtime SHALL produce the same defeat and revision outcome.
23.52.9. Validation
HECATE SHALL validate:
- defeat conditions;
- priority cycles;
- exception scope;
- retraction propagation;
- unresolved competing conclusions;
- historical traceability;
- explanation completeness.
23.53. Derived Assertions
A Derived Assertion is a governed assertion produced by the Reasoning Runtime from one or more premises and Inference Rules.
Derived Assertions SHALL remain distinguishable from explicit Constitutional Assertions.
23.53.1. Derived Assertion Identity
Every Derived Assertion SHALL possess:
- Derived Assertion Identifier;
- assertion type;
- subject;
- predicate or Relationship Type;
- object or value;
- derivation type;
- Reasoning Profile;
- Inference Rule identities and versions;
- premise identities;
- Runtime Context;
- Context Fingerprint;
- Knowledge Snapshot;
- temporal validity;
- confidence where applicable;
- contradiction status;
- lifecycle;
- activation status;
- provenance.
23.53.2. Derivation Types
Derivation Types MAY include:
- logically entailed;
- rule-inferred;
- graph-inferred;
- abductively hypothesised;
- probabilistically inferred;
- predicted;
- classified;
- context-derived;
- temporally derived;
- AI-proposed;
- refuted;
- contested.
23.53.3. Assertion Status
A Derived Assertion MAY be:
- candidate;
- provisional;
- validated;
- approved;
- active;
- disputed;
- defeated;
- retracted;
- superseded;
- expired;
- rejected;
- simulation-only.
23.53.4. Activation Boundary
A Derived Assertion SHALL become constitutionally active only through the activation policy defined by its Reasoning Profile.
Activation MAY require:
- HECATE validation;
- authority approval;
- human review;
- assurance;
- evidence threshold;
- contradiction clearance;
- publication approval.
23.53.5. Explicit and Derived Separation
Storage systems SHALL preserve whether an assertion is:
- explicitly asserted;
- derived;
- computed;
- imported;
- AI-proposed;
- human-approved;
- corrected;
- disputed.
A graph implementation SHALL NOT collapse explicit and derived assertions into indistinguishable edges.
23.53.6. Multiple Derivations
One Derived Assertion MAY possess multiple independent derivations.
The runtime SHALL preserve every derivation path and MAY use independence as an input to confidence or assurance evaluation.
23.53.7. Assertion Equivalence
Semantically equivalent Derived Assertions MAY be consolidated where:
- identity and scope are equivalent;
- context is compatible;
- temporal validity is compatible;
- provenance remains preserved;
- contradictory derivations are not concealed.
23.53.8. Assertion Invalidation
A Derived Assertion SHALL be re-evaluated when:
- a premise changes;
- a rule changes;
- context changes;
- temporal validity changes;
- evidence is revoked;
- authority changes;
- contradiction is discovered;
- the Knowledge Snapshot changes materially.
23.53.9. Assertion Impact Analysis
The runtime SHALL support impact analysis over dependants including:
- other Derived Assertions;
- calculations;
- validation outcomes;
- materiality outcomes;
- risks;
- controls;
- reports;
- disclosures;
- workflows;
- assurance conclusions.
23.53.10. HECATE Validation
HECATE SHALL validate Derived Assertions for:
- identity;
- rule applicability;
- premise validity;
- context;
- temporal validity;
- authority;
- contradiction;
- confidence policy;
- activation eligibility;
- provenance completeness;
- tenant isolation.
23.54. Confidence
Confidence expresses the governed degree of support associated with a conclusion where the applicable Reasoning Profile permits graded belief, uncertainty or probabilistic inference.
Confidence SHALL NOT be treated as truth.
Confidence SHALL remain distinct from:
- constitutional authority;
- evidence quality;
- trust;
- probability;
- assurance level;
- validation status;
- materiality;
- severity.
23.54.1. Confidence Applicability
Confidence MAY apply to:
- hypotheses;
- predictions;
- probabilistic classifications;
- AI-assisted proposals;
- uncertain mappings;
- incomplete supply-chain inference;
- risk inference;
- anomaly interpretation;
- evidence synthesis.
Pure logical entailment MAY use a categorical support status rather than numerical confidence.
23.54.2. Confidence Model
Every Reasoning Profile using confidence SHALL identify a Confidence Model defining:
- scale;
- interpretation;
- calculation method;
- aggregation;
- calibration;
- thresholds;
- missing-value treatment;
- update policy;
- explanation requirements;
- version.
23.54.3. Confidence Representations
Confidence MAY be represented as:
- categorical level;
- bounded score;
- probability;
- probability distribution;
- interval;
- belief and plausibility;
- evidence-weight classification;
- calibrated model score.
The representation SHALL be explicit.
23.54.4. Confidence Inputs
Inputs MAY include:
- premise confidence;
- evidence quality;
- source independence;
- rule reliability;
- model calibration;
- missing knowledge;
- contradiction;
- temporal staleness;
- federation completeness;
- validation status.
23.54.5. Confidence Aggregation
Aggregation SHALL be governed.
The runtime SHALL NOT average unrelated confidence values without a defined model.
23.54.6. Uncertainty Propagation
Where conclusions depend upon uncertain premises, uncertainty SHALL be propagated according to the declared model.
Monte Carlo, Bayesian or interval methods MAY be invoked through the Computation Runtime, but the Reasoning Runtime SHALL preserve their identity, parameters, outputs and limitations.
23.54.7. Confidence Thresholds
Thresholds MAY determine:
- advisory display;
- requirement for evidence;
- requirement for human review;
- activation eligibility;
- workflow escalation;
- assurance limitation.
Thresholds SHALL be profile-governed and versioned.
23.54.8. Calibration
Model-based confidence SHOULD be calibrated against known outcomes where appropriate.
Calibration artefacts SHALL preserve:
- dataset;
- period;
- methodology;
- model version;
- metrics;
- limitations;
- provenance.
23.54.9. Confidence Change
Confidence changes SHALL preserve:
- prior value;
- new value;
- triggering evidence or rule;
- method;
- timestamp;
- downstream impact;
- provenance.
23.54.10. Explanation
Every graded confidence conclusion SHALL explain:
- what the confidence represents;
- how it was produced;
- which inputs influenced it;
- uncertainty and limitations;
- applicable thresholds;
- whether it is calibrated.
23.55. Contradiction Detection
Contradiction Detection identifies incompatible assertions, conclusions, rules, evidence, authorities or temporal states within a defined reasoning scope.
Contradictions SHALL be represented explicitly rather than silently overwritten.
23.55.1. Contradiction Types
Contradiction Types MAY include:
- explicit assertion contradiction;
- derived assertion contradiction;
- rule contradiction;
- authority contradiction;
- temporal contradiction;
- context contradiction;
- evidence contradiction;
- methodology contradiction;
- classification contradiction;
- probabilistic contradiction;
- tenant-overlay contradiction;
- federation contradiction.
23.55.2. Contradiction Object
A material contradiction SHOULD be represented as a governed Contradiction Object containing:
- Contradiction Identifier;
- contradiction type;
- involved assertions;
- involved rules;
- involved evidence;
- Runtime Context;
- temporal scope;
- severity;
- impact;
- status;
- resolution authority;
- provenance.
23.55.3. Detection Timing
Contradictions MAY be detected during:
- premise resolution;
- rule resolution;
- reasoning execution;
- Derived Assertion validation;
- continuous reasoning;
- federation synchronisation;
- replay;
- assurance review.
23.55.4. Four-State Treatment
A Reasoning Profile MAY distinguish:
- supported true;
- supported false;
- both supported true and supported false;
- neither supported.
This treatment SHALL be explicit and SHALL NOT imply that contradiction is resolved.
23.55.5. Paraconsistent Handling
A profile MAY permit paraconsistent reasoning so that one contradiction does not make every conclusion derivable.
The profile SHALL define:
- affected predicates;
- propagation limits;
- blocked rules;
- explanation requirements;
- escalation requirements.
23.55.6. Contradiction Severity
Severity MAY consider:
- constitutional significance;
- affected scope;
- authority level;
- regulatory impact;
- materiality;
- assurance impact;
- propagation depth;
- tenant count;
- publication status.
23.55.7. Contradiction Resolution
Resolution MAY use:
- authority precedence;
- temporal precedence;
- context separation;
- evidence quality;
- rule priority;
- explicit override;
- human decision;
- qualification;
- coexistence within different contexts.
A contradiction SHALL NOT be resolved by implementation order.
23.55.8. Unresolved Contradiction
An unresolved contradiction MAY produce:
- blocked activation;
- provisional assertion;
- contested assertion;
- qualified outcome;
- human decision task;
- assurance limitation;
- workflow escalation.
23.55.9. Contradiction Propagation
The runtime SHALL identify Derived Assertions and Runtime Outcomes dependent upon contradicted premises.
23.55.10. Historical Contradiction
A current contradiction SHALL not automatically invalidate a historically correct conclusion where the historical Knowledge Snapshot differed.
23.55.11. HECATE Validation
HECATE SHALL validate:
- contradiction detection completeness;
- contradiction classification;
- propagation;
- resolution authority;
- qualification;
- unresolved status;
- historical preservation;
- explanation;
- provenance.
23.56. Reasoning Provenance
Reasoning Provenance is the complete governed lineage explaining how a Derived Assertion or reasoning conclusion was produced.
Reasoning Provenance SHALL be captured during reasoning rather than reconstructed solely from logs.
23.56.1. Provenance Scope
Reasoning Provenance SHALL include:
- Reasoning Request;
- Reasoning Plan;
- Reasoning Profile;
- Runtime Context;
- Context Fingerprint;
- Knowledge Snapshot;
- premise identities and versions;
- Inference Rule identities and versions;
- rule bindings;
- rule execution order;
- reasoning engine;
- Component identity;
- Module lineage;
- intermediate conclusions;
- contradiction evaluations;
- confidence evaluations;
- validation results;
- activation decisions;
- timestamps;
- trust state;
- signatures where applicable.
23.56.2. Proof Graph
Reasoning Provenance SHOULD be represented as a Proof Graph.
Premise A ─────┐
├── Rule R1 ──► Derived Assertion X
Premise B ───── ┘ │
├── Rule R2 ──► Derived Assertion Y
Premise C ────────────────────────────┘
The Proof Graph SHALL preserve every material derivation path.
23.56.3. Rule Bindings
For each rule execution, provenance SHALL identify:
- rule;
- variable bindings;
- matched premises;
- guards evaluated;
- exceptions evaluated;
- priority outcome;
- conclusion;
- timestamp;
- engine.
23.56.4. Alternative Derivations
Where multiple derivations support one assertion, all material derivations SHALL remain available.
23.56.5. Negative and Absence Provenance
An absence-based conclusion SHALL preserve:
- closure declaration;
- searched scope;
- completeness status;
- query or traversal;
- snapshot;
- time;
- provenance.
23.56.6. Confidence Provenance
Where confidence applies, provenance SHALL preserve:
- Confidence Model;
- inputs;
- aggregation method;
- calibration artefacts;
- thresholds;
- output;
- uncertainty.
23.56.7. AI-Assisted Provenance
AI-assisted reasoning SHALL preserve:
- model identity;
- model version;
- provider;
- prompt or instruction artefact;
- retrieval snapshot;
- tool calls;
- sampling parameters;
- output;
- grounding evidence;
- validator results;
- human review;
- limitations.
23.56.8. Provenance Integrity
Reasoning Provenance SHALL be protected through appropriate integrity mechanisms such as:
- cryptographic hashes;
- signatures;
- append-only stores;
- trusted timestamps;
- transparency logs;
- replicated evidence stores.
23.56.9. Provenance Completeness
Completeness MAY be classified as:
- complete;
- complete with controlled redaction;
- partially complete;
- materially incomplete;
- reconstructed;
- disputed;
- unavailable.
A materially incomplete provenance chain SHALL prevent unqualified high-assurance activation.
23.56.10. Replay
The runtime SHALL support reasoning replay using the original Knowledge Snapshot, Context Fingerprint, Reasoning Profile, Inference Rules, engine version and uncertainty inputs.
23.56.11. Reasoning Diff
A Reasoning Diff SHOULD identify changes in:
- premises;
- rules;
- profile;
- context;
- world assumption;
- contradiction handling;
- confidence;
- conclusions;
- explanations;
- provenance.
23.56.12. Pergamum Pulse Integration
Pergamum Pulse MAY analyse reasoning provenance to identify:
- highly influential premises;
- fragile conclusions;
- recurring contradictions;
- reasoning bottlenecks;
- rule coverage gaps;
- tenant divergence;
- jurisdictional divergence;
- stale Derived Assertions;
- low-confidence assertion clusters;
- Component reliability;
- Module-level reasoning risk;
- unexplained conclusion divergence.
Pergamum Pulse SHALL preserve both Module and Component lineage.
Derived intelligence SHALL remain Intelligence Layer assertions until governed activation.
23.57. Explainable Reasoning
Explainable Reasoning is the constitutional requirement that every material Derived Assertion and reasoning outcome can be explained in machine-readable and human-readable form.
An explanation SHALL describe why a conclusion was produced, what supported it, what opposed it, which assumptions applied and how uncertainty or contradiction affected it.
23.57.1. Explanation Contents
A complete reasoning explanation SHALL identify:
- Reasoning Request;
- Reasoning Profile;
- Runtime Context;
- Context Fingerprint;
- Knowledge Snapshot;
- premises;
- Inference Rules;
- rule bindings;
- world assumption;
- monotonicity model;
- competing conclusions;
- contradictions;
- confidence;
- Derived Assertion;
- validation results;
- activation status;
- limitations;
- provenance.
23.57.2. Explanation Layers
Explanations SHOULD support:
| Layer | Intended Audience |
|---|---|
| Summary Explanation | Decision-makers and end users |
| Constitutional Explanation | Governance and architecture users |
| Regulatory Explanation | Compliance and legal users |
| Technical Explanation | Developers and runtime operators |
| Assurance Explanation | Auditors and verifiers |
| Machine Explanation | APIs, agents and automated controls |
| Forensic Explanation | Investigators and dispute reviewers |
All layers SHALL preserve the same underlying reasoning outcome.
23.57.3. Minimal Explanation
A minimal explanation SHALL identify the smallest sufficient set of premises and rules supporting the conclusion where such a set can be determined.
23.57.4. Complete Explanation
A complete explanation MAY additionally include:
- all derivation paths;
- rejected rule applications;
- defeated conclusions;
- excluded premises;
- confidence propagation;
- contradiction handling;
- alternative conclusions;
- resource limits;
- incomplete knowledge.
23.57.5. Why and Why-Not Explanations
The runtime SHOULD support:
- Why was this conclusion derived?
- Why was this candidate conclusion not derived?
- Why was this conclusion defeated?
- Why is the outcome indeterminate?
- What additional evidence would change the outcome?
23.57.6. Counterfactual Explanation
Where permitted, the runtime MAY explain the smallest governed change that would alter the conclusion.
Counterfactual explanations SHALL distinguish hypothetical changes from recommendations or constitutional authority.
23.57.7. Explanation of Unknown
Where no conclusion can be reached, the explanation SHALL identify whether the reason is:
- open-world incompleteness;
- missing premise;
- missing evidence;
- unresolved identity;
- unresolved contradiction;
- insufficient confidence;
- unavailable rule;
- exceeded resource limit;
- prohibited access;
- redaction.
23.57.8. Explanation of Contradiction
A contradiction explanation SHALL identify:
- conflicting assertions;
- supporting derivations;
- authorities;
- contexts;
- temporal boundaries;
- resolution strategy;
- unresolved elements;
- impact.
23.57.9. Explanation Security
Explanations SHALL respect:
- tenant isolation;
- access control;
- confidentiality;
- personal-data minimisation;
- legal privilege;
- trade-secret protection;
- security classification;
- inference-leakage prevention.
Redaction SHALL preserve the existence and effect of hidden material where disclosure is prohibited.
23.57.10. Explanation Determinism
Equivalent reasoning outcomes SHOULD produce semantically equivalent explanations.
Presentation MAY vary by language, audience and disclosure profile.
23.57.11. Explanation Identity
Every authoritative explanation SHALL possess:
- Explanation Identifier;
- Derived Assertion or Reasoning Outcome Identifier;
- explanation profile;
- language;
- audience;
- disclosure profile;
- generation Component;
- generation timestamp;
- Runtime Bundle;
- Context Fingerprint;
- integrity metadata;
- provenance.
23.57.12. Explanation Validation
HECATE SHALL validate reasoning explanations for:
- outcome consistency;
- premise traceability;
- rule traceability;
- context traceability;
- contradiction disclosure;
- confidence disclosure;
- qualification disclosure;
- security compliance;
- provenance completeness.
23.57.13. Public and Regulatory Explanation
Reasoning explanations MAY be exported for:
- internal governance;
- customer review;
- external assurance;
- regulatory review;
- scientific reproducibility;
- dispute resolution;
- public transparency.
Exports SHALL preserve scope, qualification, integrity, redaction state and provenance.
23.57.14. Reasoning Conformance Suite
The Constitutional Compiler Framework SHOULD generate a Reasoning Conformance Suite containing:
- positive entailment cases;
- negative assertion cases;
- open-world cases;
- closed-world cases;
- locally closed-world cases;
- recursive-rule cases;
- defeasible-rule cases;
- contradiction cases;
- confidence cases;
- temporal cases;
- tenant-isolation cases;
- replay cases;
- explanation cases;
- non-termination cases.
Part V Conformance
A Constitutional Runtime Framework implementation conforms to Part V where it:
- separates reasoning from resolution, validation, computation, workflow and AI generation;
- requires an identifiable Reasoning Request and deterministic Reasoning Plan;
- reasons against an identifiable Knowledge Snapshot and Context Fingerprint;
- resolves Reasoning Profiles and Inference Rules through Constitutional Resolution Policies;
- represents every Inference Rule as a governed Constitutional Object;
- declares world assumptions and monotonicity explicitly;
- distinguishes open-world, closed-world, locally closed-world and hybrid reasoning;
- supports governed non-monotonic reasoning and truth maintenance where required;
- preserves explicit and Derived Assertions as distinct constitutional classes;
- prevents Derived Assertions from becoming canonical without governed activation;
- preserves rule bindings, premises and derivation paths;
- treats confidence as distinct from truth, authority, assurance and validation;
- represents contradictions explicitly and prevents arbitrary selection;
- supports reasoning replay, diff and impact analysis;
- produces machine-readable and human-readable explanations;
- validates Derived Assertions and reasoning explanations through HECATE;
- preserves tenant isolation and inference-leakage controls;
- preserves Module and Component lineage;
- preserves complete Reasoning Provenance;
- prevents AI-generated or probabilistic conclusions from appearing constitutionally authoritative without governed validation and activation.
Part V Foundational Principle
Reasoning Runtime is the governed constitutional mechanism through which ZAYAZ derives new assertions and implications from explicit constitutional knowledge, validated runtime state, evidence and versioned Inference Rules within an explicit Runtime Context.
Constitutional Resolution Policies SHALL determine which Reasoning Profiles and Inference Rules apply. The Reasoning Runtime SHALL execute those rules against an identifiable Knowledge Snapshot, preserve open-world and closed-world boundaries, govern non-monotonic revision, represent contradictions explicitly and maintain complete dependencies between every conclusion and its supporting premises.
A Derived Assertion SHALL remain distinguishable from an explicit Constitutional Assertion and SHALL NOT become canonical merely because a reasoning engine, graph traversal, probabilistic model or AI system produced it. Confidence SHALL not be treated as truth. Absence SHALL not be treated as falsity unless a validated closure declaration permits that inference. Contradiction SHALL not be resolved by implementation order.
Every reasoning outcome SHALL preserve its Reasoning Request, Reasoning Plan, Runtime Context, Knowledge Snapshot, Inference Rules, rule bindings, premises, uncertainty, contradictions, validator results, Runtime Bundle, Module lineage, Component lineage, explanation and complete provenance. By making reasoning governed, replayable, defeasible, context-aware and independently explainable, ZAYAZ enables powerful machine reasoning without sacrificing constitutional integrity, regulatory assurance or human accountability.