Definition

Axiom Enforcement is the programmatic mechanism that ensures non-negotiable epistemic principles are upheld at all times within a belief processing system, regardless of the authority level of the requesting entity. An axiom, in this context, is a foundational rule that the system treats as unconditionally true -- it cannot be overridden, deferred, or selectively applied. Enforcement is the automated process of validating every belief, claim, and decision against these axioms before the system accepts them as part of its knowledge base.

In the Prismatic Platform, axiom enforcement implements the seven non-negotiable axioms of the NABLA Infinity (Nabla) epistemic framework. Every piece of information that enters the platform's reasoning pipeline must pass through axiom validation at one of four enforcement levels (E1-E4), with hard axioms producing blocking rejections and soft axioms producing tracked warnings. No entity, regardless of tier, can bypass this enforcement.

Overview

Epistemic systems face a fundamental challenge: how to maintain reasoning integrity as the volume of information, the number of reasoning agents, and the complexity of decisions grow. Without enforcement mechanisms, epistemic drift is inevitable -- agents begin accepting unverified claims, discarding inconvenient contradictions, relying on single sources, and producing conclusions without traceable provenance.

Axiom enforcement addresses this challenge by embedding invariant checks directly into the belief processing pipeline. Rather than relying on manual review or post-hoc auditing, the system automatically validates every epistemic operation against its foundational principles. This approach draws from formal methods in computer science, where invariants are proven to hold across all possible system states, and from axiomatic systems in mathematics, where theorems must derive from accepted axioms through valid inference rules.

The distinction between hard and soft enforcement is critical. Hard-enforced axioms produce blocking violations -- the operation is rejected and cannot proceed until the violation is resolved. Soft-enforced axioms produce warnings that are logged and tracked but do not block the operation. This two-tier approach balances system integrity (hard axioms prevent corruption) with operational pragmatism (soft axioms guide improvement without halting production work).

The Seven NABLA Axioms

#	Axiom	Enforcement	Description
1	Signal Plurality	HARD	Minimum 2 independent signals required for any belief
2	Contradiction Preservation	HARD	Both sides of contradictions must be preserved, never discarded
3	Absence Informative	SOFT	Missing signals are tracked as informative data points
4	Time Decay	HARD	All beliefs must carry mandatory timestamps for freshness assessment
5	Unknown Valid	HARD	"I don't know" is a legitimate and valued epistemic state
6	Source Independence	SOFT	Independent sources receive higher weight than correlated ones
7	Provenance Mandatory	HARD	All beliefs must be traceable to their origin

Technical Details

Enforcement Architecture

The axiom enforcement system is implemented as a pipeline of validators, each responsible for one axiom. Every belief operation passes through all validators before being accepted:

Input Belief/Claim
       │
       ▼
┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│ Signal       │────>│ Contradiction│────>│ Absence      │
│ Plurality    │     │ Preservation │     │ Informative  │
│ [HARD]       │     │ [HARD]       │     │ [SOFT]       │
└──────────────┘     └──────────────┘     └──────────────┘
       │                                         │
       ▼                                         ▼
┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│ Time Decay   │────>│ Unknown      │────>│ Source       │
│ [HARD]       │     │ Valid        │     │ Independence │
│              │     │ [HARD]       │     │ [SOFT]       │
└──────────────┘     └──────────────┘     └──────────────┘
                                                 │
                                                 ▼
                                          ┌──────────────┐
                                          │ Provenance   │
                                          │ Mandatory    │
                                          │ [HARD]       │
                                          └──────────────┘
                                                 │
                                                 ▼
                                          Trinity Gate
                                          (if required)

Core Implementation

defmodule Prismatic.Epistemic.AxiomEnforcer do
  @moduledoc """
  Non-bypassable axiom enforcement for the NABLA epistemic framework.
  Validates all beliefs against the seven foundational axioms before
  acceptance into the platform's knowledge base.
  """

  @type belief :: %{
    claim: String.t(),
    signals: [signal()],
    provenance: provenance(),
    timestamp: DateTime.t(),
    confidence: float(),
    metadata: map()
  }

  @type signal :: %{source: String.t(), value: term(), timestamp: DateTime.t()}
  @type provenance :: %{origin: String.t(), chain: [String.t()], method: atom()}

  @type enforcement_result ::
    {:ok, belief()}
    | {:error, :e2_hard_violation, [violation()]}
    | {:warning, belief(), [violation()]}

  @type violation :: %{
    axiom: atom(),
    level: :e1 | :e2 | :e3 | :e4,
    message: String.t(),
    remediation: String.t()
  }

  @hard_axioms [:signal_plurality, :contradiction_preservation, :time_decay, :unknown_valid, :provenance_mandatory]
  @soft_axioms [:absence_informative, :source_independence]

  @spec enforce(belief()) :: enforcement_result()
  def enforce(belief) do
    hard_results = Enum.map(@hard_axioms, &validate_axiom(&1, belief))
    soft_results = Enum.map(@soft_axioms, &validate_axiom(&1, belief))

    hard_violations = Enum.filter(hard_results, &match?({:violation, _}, &1))
    soft_violations = Enum.filter(soft_results, &match?({:violation, _}, &1))

    case hard_violations do
      [] when soft_violations == [] ->
        {:ok, belief}

      [] ->
        warnings = Enum.map(soft_violations, fn {:violation, v} -> v end)
        log_warnings(belief, warnings)
        {:warning, belief, warnings}

      violations ->
        errors = Enum.map(violations, fn {:violation, v} -> v end)
        log_violations(belief, errors)
        {:error, :e2_hard_violation, errors}
    end
  end

  @spec validate_axiom(atom(), belief()) :: :ok | {:violation, violation()}
  defp validate_axiom(:signal_plurality, %{signals: signals}) when length(signals) < 2 do
    {:violation, %{
      axiom: :signal_plurality,
      level: :e2,
      message: "Belief requires minimum 2 independent signals, found #{length(signals)}",
      remediation: "Provide additional independent signals before establishing belief"
    }}
  end

  defp validate_axiom(:contradiction_preservation, %{metadata: %{contradictions: contradictions}})
       when is_list(contradictions) do
    discarded = Enum.filter(contradictions, &(&1.status == :discarded))

    case discarded do
      [] -> :ok
      _ ->
        {:violation, %{
          axiom: :contradiction_preservation,
          level: :e2,
          message: "#{length(discarded)} contradictions were discarded instead of preserved",
          remediation: "Restore discarded contradictions and preserve both sides"
        }}
    end
  end

  defp validate_axiom(:time_decay, %{timestamp: nil}) do
    {:violation, %{
      axiom: :time_decay,
      level: :e2,
      message: "Belief has no timestamp, cannot assess freshness",
      remediation: "Add mandatory timestamp to belief"
    }}
  end

  defp validate_axiom(:time_decay, %{timestamp: ts}) do
    age_days = DateTime.diff(DateTime.utc_now(), ts, :day)

    if age_days > 365 do
      {:violation, %{
        axiom: :time_decay,
        level: :e2,
        message: "Belief is #{age_days} days old, exceeds maximum age threshold",
        remediation: "Re-validate belief with fresh signals or mark as historical"
      }}
    else
      :ok
    end
  end

  defp validate_axiom(:unknown_valid, %{confidence: confidence, metadata: meta}) do
    forces_certainty = Map.get(meta, :forced_certainty, false)

    if forces_certainty and confidence < 0.5 do
      {:violation, %{
        axiom: :unknown_valid,
        level: :e2,
        message: "System forced certainty on belief with confidence #{confidence}",
        remediation: "Accept uncertainty as valid state; do not force conclusions"
      }}
    else
      :ok
    end
  end

  defp validate_axiom(:provenance_mandatory, %{provenance: nil}) do
    {:violation, %{
      axiom: :provenance_mandatory,
      level: :e2,
      message: "Belief has no provenance chain, origin unknown",
      remediation: "Attach provenance metadata tracing belief to its origin"
    }}
  end

  defp validate_axiom(:provenance_mandatory, %{provenance: %{chain: chain}}) when chain == [] do
    {:violation, %{
      axiom: :provenance_mandatory,
      level: :e2,
      message: "Belief provenance chain is empty",
      remediation: "Populate provenance chain with at least one traceable step"
    }}
  end

  defp validate_axiom(:absence_informative, %{metadata: meta}) do
    expected_signals = Map.get(meta, :expected_signals, [])
    actual_signals = Map.get(meta, :actual_signal_sources, [])
    missing = expected_signals -- actual_signals

    case missing do
      [] -> :ok
      _ ->
        {:violation, %{
          axiom: :absence_informative,
          level: :e1,
          message: "#{length(missing)} expected signals are absent: #{inspect(missing)}",
          remediation: "Track absent signals as informative data points"
        }}
    end
  end

  defp validate_axiom(:source_independence, %{signals: signals}) do
    sources = Enum.map(signals, & &1.source)
    unique_sources = Enum.uniq(sources)

    if length(unique_sources) < length(sources) * 0.5 do
      {:violation, %{
        axiom: :source_independence,
        level: :e1,
        message: "More than 50% of signals come from correlated sources",
        remediation: "Seek independent sources to reduce correlation bias"
      }}
    else
      :ok
    end
  end

  defp validate_axiom(_axiom, _belief), do: :ok

  @spec log_violations(belief(), [violation()]) :: :ok
  defp log_violations(belief, violations) do
    :telemetry.execute(
      [:prismatic, :epistemic, :axiom_violation],
      %{count: length(violations)},
      %{claim: belief.claim, violations: violations, level: :hard}
    )
  end

  @spec log_warnings(belief(), [violation()]) :: :ok
  defp log_warnings(belief, warnings) do
    :telemetry.execute(
      [:prismatic, :epistemic, :axiom_warning],
      %{count: length(warnings)},
      %{claim: belief.claim, warnings: warnings, level: :soft}
    )
  end
end

Enforcement Levels

The enforcement system operates at four escalation levels, each with increasing severity and authority requirements:

Level	Trigger	Response	Authority Required	Auto-Recovery
E1	Single soft axiom violation	Warning logged + correction request	Agent-level	Yes
E2	Single hard axiom violation	BLOCK + rejection	System-level	No, requires fix
E3	Trinity Gate failure	HALT + review required	Supreme-level	No, requires review
E4	Multiple axiom violations	Investigation + full audit	Cosmic clearance	No, requires audit

defmodule Prismatic.Epistemic.EnforcementLevel do
  @moduledoc """
  Enforcement level escalation logic. Determines the appropriate
  response based on the severity and count of axiom violations.
  """

  @type level :: :e1 | :e2 | :e3 | :e4

  @spec determine_level(violations :: [map()]) :: level()
  def determine_level(violations) do
    hard_count = Enum.count(violations, &(&1.level == :e2))
    soft_count = Enum.count(violations, &(&1.level == :e1))
    trinity_failures = Enum.count(violations, &(&1.axiom == :trinity_gate))

    cond do
      trinity_failures > 0 -> :e3
      hard_count >= 3 -> :e4
      hard_count >= 1 -> :e2
      soft_count >= 1 -> :e1
      true -> :e1
    end
  end

  @spec response_for(level()) :: map()
  def response_for(:e1), do: %{action: :warn, blocking: false, audit: false, escalation: nil}
  def response_for(:e2), do: %{action: :block, blocking: true, audit: true, escalation: :system}
  def response_for(:e3), do: %{action: :halt, blocking: true, audit: true, escalation: :supreme}
  def response_for(:e4), do: %{action: :investigate, blocking: true, audit: true, escalation: :cosmic}
end

Integration with Trinity Gate

Axiom enforcement is the first layer of the three-layer Trinity Gate validation system. All three gates must pass for a claim to be established:

defmodule Prismatic.Epistemic.TrinityGate do
  @moduledoc """
  Three-layer validation gate. All three must pass for claim establishment.
  Gate 1: Axiom compliance (this module delegates to AxiomEnforcer)
  Gate 2: Structural consistency (belief graph forms valid DAG)
  Gate 3: Formal necessity (modal logic / Lean4 proof)
  """

  @spec validate(belief :: map(), context :: atom()) :: {:passed, map()} | {:failed, gate :: atom(), reason :: term()}
  def validate(belief, context) do
    threshold = confidence_threshold(context)

    with {:ok, belief} <- gate_1_axiom_compliance(belief),
         {:ok, belief} <- gate_2_structural_consistency(belief),
         {:ok, belief} <- gate_3_formal_necessity(belief, threshold) do
      {:passed, %{belief | metadata: Map.put(belief.metadata, :trinity_passed, true)}}
    else
      {:error, gate, reason} -> {:failed, gate, reason}
    end
  end

  @spec gate_1_axiom_compliance(map()) :: {:ok, map()} | {:error, :axiom_compliance, term()}
  defp gate_1_axiom_compliance(belief) do
    case Prismatic.Epistemic.AxiomEnforcer.enforce(belief) do
      {:ok, belief} -> {:ok, belief}
      {:warning, belief, _warnings} -> {:ok, belief}
      {:error, _level, violations} -> {:error, :axiom_compliance, violations}
    end
  end

  @spec gate_2_structural_consistency(map()) :: {:ok, map()} | {:error, :structural_consistency, term()}
  defp gate_2_structural_consistency(belief) do
    case Prismatic.Epistemic.BeliefGraph.validate_dag(belief) do
      {:ok, _} -> {:ok, belief}
      {:error, reason} -> {:error, :structural_consistency, reason}
    end
  end

  @spec gate_3_formal_necessity(map(), float()) :: {:ok, map()} | {:error, :formal_necessity, term()}
  defp gate_3_formal_necessity(belief, threshold) do
    if belief.confidence >= threshold do
      {:ok, belief}
    else
      {:error, :formal_necessity, "Confidence #{belief.confidence} below threshold #{threshold}"}
    end
  end

  @spec confidence_threshold(atom()) :: float()
  defp confidence_threshold(:critical), do: 0.95
  defp confidence_threshold(:standard), do: 0.80
  defp confidence_threshold(:exploratory), do: 0.60
  defp confidence_threshold(:research), do: 0.50
  defp confidence_threshold(_), do: 0.80
end

Anti-Pattern Detection

The enforcement system actively detects and blocks known epistemic anti-patterns:

Anti-Pattern	Detection Method	Enforcement
Cherry Picking	Asymmetric signal selection from available sources	E2 BLOCK
False Certainty	High confidence without adequate signal support	E2 BLOCK
Contradiction Burial	Contradictions marked as resolved without preservation	E3 HALT
Single Source Truth	Belief established from exactly one signal	E2 BLOCK
Reasoning Opacity	Decision without traceable provenance chain	E2 BLOCK
Temporal Blindness	Beliefs without timestamps or age assessment	E2 BLOCK
Forced Conclusion	System forced past uncertainty instead of accepting "unknown"	E2 BLOCK

Implementation in Prismatic Platform

Axiom enforcement is integrated throughout the Prismatic Platform at multiple layers:

Pipeline Integration

Every NABLA epistemic pipeline operation passes through axiom enforcement. The enforcement is wired into the pipeline as non-removable middleware:

Belief ingestion: New beliefs validated before storage in the belief graph
Confidence updates: Confidence scoring changes validated for axiom compliance
Claim establishment: Trinity Gate passage requires full axiom compliance
Agent decisions: Autonomous agents validate their reasoning against axioms before acting

Quality Gate Integration

Axiom enforcement connects to the platform's quality gates system. Quality gate checks include axiom compliance verification, ensuring that code quality and epistemic quality are jointly maintained.

Telemetry and Monitoring

All axiom enforcement events emit telemetry, enabling real-time monitoring of epistemic health:

# Telemetry events emitted by axiom enforcement
[:prismatic, :epistemic, :axiom_violation]   # Hard violation detected
[:prismatic, :epistemic, :axiom_warning]     # Soft violation detected
[:prismatic, :epistemic, :trinity_passage]   # Trinity Gate result
[:prismatic, :epistemic, :enforcement_level] # Escalation level change

Comparison with Alternatives

Approach	Enforcement Strength	Bypass Resistance	Formal Grounding	Runtime Cost
Axiom Enforcement (Prismatic)	Non-bypassable, multi-level	Absolute (no authority can override)	Modal logic + Lean4	Per-belief validation
Schema Validation	Structure only, no semantics	Bypassable via schema changes	JSON Schema / Avro	Low
Business Rules Engines	Configurable, authority-dependent	Admin can modify rules	Propositional logic	Rule evaluation
Type Systems	Compile-time structural	Cannot express epistemic properties	Type theory	Zero runtime cost
Manual Review	Human judgment, inconsistent	Reviewer fatigue, bias	None formal	Human time cost
Assertion-Based	Development-time only	Disabled in production	Ad hoc	Zero in production

Axiom enforcement in Prismatic is unique in combining non-bypassable runtime validation with formal grounding in modal logic. Unlike business rules engines where administrators can modify rules, axioms are treated as immutable constants of the system -- they can only be changed through a versioned doctrine update process requiring cosmic clearance authority.

Best Practices

Treat axioms as immutable constants. Axioms should change only through formal versioned updates, never through runtime configuration. If you find yourself wanting to "relax" an axiom for a specific case, the correct response is to fix the belief, not weaken the axiom.

Validate early in the pipeline. Axiom enforcement should occur at the point of belief ingestion, not after processing. Late enforcement wastes computational resources on beliefs that will ultimately be rejected.

Log all enforcement actions. Every axiom check, whether it passes or fails, should produce a telemetry event. This creates a complete audit trail and enables trend analysis of epistemic health over time.

Distinguish hard and soft violations carefully. Hard axioms (signal plurality, contradiction preservation, time decay, unknown valid, provenance mandatory) are genuinely non-negotiable. Soft axioms (absence informative, source independence) are important guidance but should not block operations. Getting this classification wrong in either direction harms the system.

Test axiom enforcement with adversarial inputs. The red team should regularly attempt to construct beliefs that violate axioms in subtle ways. Enforcement that only catches obvious violations provides false security.

Common Pitfalls

Treating enforcement as optional. The most common failure mode is building "fast paths" that bypass axiom validation for performance or convenience. Every bypass is a hole in epistemic integrity. In Prismatic, the enforcement pipeline is architecturally non-removable.

Over-classifying axioms as hard. Making every axiom hard-enforced leads to excessive blocking and encourages workarounds. Reserve hard enforcement for axioms where violations genuinely corrupt the belief system. Use soft enforcement for axioms that improve quality but whose violations are not catastrophic.

Ignoring soft violations. The opposite pitfall: treating warnings as noise and never acting on them. Soft violations should be tracked, trended, and addressed. A rising count of source independence warnings signals growing epistemic fragility.

Static axiom thresholds. Using fixed thresholds (like "minimum 2 signals") without context sensitivity. Critical decisions might need 5+ signals, while exploratory research might function with 2. The confidence threshold table addresses this, but individual axiom thresholds should also be context-aware.

Confusing axiom enforcement with data validation. Axiom enforcement validates epistemic properties (plurality, provenance, contradiction handling). Data validation checks structural properties (types, formats, required fields). Both are necessary; neither substitutes for the other.

Use Cases

Intelligence Analysis

When multiple OSINT sources provide conflicting information about an entity, axiom enforcement ensures that contradictory signals are preserved rather than resolved prematurely. Signal plurality enforcement prevents conclusions based on a single source, while provenance tracking maintains the chain from raw data to analytical conclusion.

Security Assessment

The Prismatic Perimeter security rating system uses axiom enforcement to ensure that security grades are based on multiple independent evidence sources, contradictory findings (e.g., a secure configuration alongside an exposed service) are preserved in the assessment, and every rating decision traces back to specific observed evidence.

Quality Gate Decisions

When the Quality Floor Guardian decides whether to block a commit, axiom enforcement ensures the decision is based on multiple quality metrics (not just one), acknowledges uncertainty in metrics that could not be computed, and preserves the reasoning chain for audit.

Agent Decision Validation

Before any autonomous agent acts on a decision, axiom enforcement validates that the decision reasoning meets epistemic standards -- preventing agents from acting on single-source information, suppressed contradictions, or untraceable conclusions.

NABLA Infinity -- The epistemic framework defining the seven axioms
NABLA Axioms -- The individual axiom specifications
Signal Plurality -- Axiom requiring multiple independent signals per belief
Contradiction Preservation -- Axiom requiring preservation of conflicting evidence
Provenance Mandatory -- Axiom requiring traceable belief origins
Trinity Gate -- Three-layer validation gate that includes axiom enforcement
Belief Graph -- The DAG structure storing validated beliefs
Enforcement Policy -- Policy documents governing enforcement behaviour
Epistemic Robustness -- System-level resilience of the belief system
Confidence Threshold -- Context-dependent thresholds for claim establishment

Connect & Contribute

Created by Tomáš Korcak (korczis) | Open Source under GHL

GitHub | GitLab | LinkedIn | Contact
Developer Portal | Architecture | Meet the Creator

Axiom Enforcement

Definition

Overview

The Seven NABLA Axioms

Technical Details

Enforcement Architecture

Core Implementation

Enforcement Levels

Integration with Trinity Gate

Anti-Pattern Detection

Implementation in Prismatic Platform

Pipeline Integration

Quality Gate Integration

Telemetry and Monitoring

Comparison with Alternatives

Best Practices

Common Pitfalls

Use Cases

Intelligence Analysis

Security Assessment

Quality Gate Decisions

Agent Decision Validation

See Also

Connect & Contribute

Glossary

Related Terms

Axiom Enforcement

Definition

Overview

The Seven NABLA Axioms

Technical Details

Enforcement Architecture

Core Implementation

Enforcement Levels

Integration with Trinity Gate

Anti-Pattern Detection

Implementation in Prismatic Platform

Pipeline Integration

Quality Gate Integration

Telemetry and Monitoring

Comparison with Alternatives

Best Practices

Common Pitfalls

Use Cases

Intelligence Analysis

Security Assessment

Quality Gate Decisions

Agent Decision Validation

Related Concepts

See Also

Connect & Contribute

Glossary

Related Terms