NABLA Axioms

epistemic

NABLA Axioms

Definition

The NABLA Axioms are the seven non-negotiable epistemic principles that govern all belief formation, evidence evaluation, and decision-making within the Prismatic Platform's NABLA Infinity framework. They are: (1) Signal Plurality -- minimum two independent signals required for any belief, (2) Contradiction Preservation -- conflicting evidence must be preserved, never discarded, (3) Absence Informative -- missing data is itself meaningful data, (4) Time Decay -- all beliefs carry mandatory timestamps and degrade over time, (5) Unknown Valid -- "I don't know" is a legitimate and honored epistemic state, (6) Source Independence -- independent sources receive higher evidential weight, and (7) Provenance Mandatory -- all beliefs must be traceable to their origins. Together, these axioms form the DNA-level constraints that prevent epistemic corruption across the platform's 530+ agents and 115 applications.

Overview

The NABLA Axioms exist because intelligent systems -- whether human or artificial -- have a natural tendency toward epistemic shortcuts: cherry-picking evidence, smoothing over contradictions, treating absence as absence of significance, and accepting claims without provenance. These tendencies, while efficient in low-stakes environments, produce catastrophic failures in systems that process intelligence, assess security risks, or make autonomous decisions.

The Prismatic Platform was designed to resist these tendencies at the architectural level. The NABLA Axioms are not guidelines or suggestions -- they are hard constraints enforced through the Trinity Gate verification system, automated axiom validators, and the Addiction Preservation doctrine that demands constant vigilance against epistemic rationalization.

The axioms draw from three intellectual traditions. From formal logic, they inherit rigor and verifiability. From intelligence analysis, they inherit the requirement for source plurality and contradiction tracking. From philosophy of science, they inherit the principle that unfalsifiable claims and claims without provenance are epistemically worthless regardless of their apparent plausibility.

Every claim that passes through the platform -- whether a security rating from the Prismatic Perimeter, a threat assessment from the Red Team, or a quality score from the Quality Floor Guardian -- must satisfy all seven axioms before it can influence platform behavior. This is not optional. There is no bypass. The axioms are enforced at COSMIC CLEARANCE authority level.

Technical Details

Axiom 1: Signal Plurality (HARD Enforcement)

No belief may be established on the basis of a single signal, regardless of that signal's apparent reliability. A minimum of two independent signals is required for any proposition to enter the belief graph.

Rationale: Single-source beliefs are brittle. If the source is compromised, wrong, or out of date, the entire downstream chain of reasoning is corrupted. Plurality provides redundancy against individual source failure.

Enforcement: HARD -- violations result in E2 BLOCK. The proposition is rejected and cannot enter the belief graph until a second independent signal is provided.

Threshold in context:

  • Critical decisions require 3+ signals
  • Standard operations require 2+ signals
  • Exploratory analysis allows single signals but marks them as "unconfirmed"

Axiom 2: Contradiction Preservation (HARD Enforcement)

When evidence contradicts existing beliefs, both the existing belief and the contradicting evidence must be preserved. Contradictions are never resolved by discarding one side. Instead, they are explicitly tracked, investigated, and either resolved through additional evidence or maintained as genuine uncertainty.

Rationale: Premature contradiction resolution -- choosing one side because it is more convenient, familiar, or expected -- is the most common form of epistemic corruption. Contradictions are signals that the model of reality is incomplete. Discarding them destroys information.

Enforcement: HARD -- E2 BLOCK for any operation that discards contradicting evidence. E3 HALT for systematic contradiction burial.

Axiom 3: Absence Informative (SOFT Enforcement)

When expected signals are absent, this absence is itself a data point that must be recorded and tracked. A security scan that finds no vulnerabilities, a search that returns no results, and a monitoring check that detects no anomalies are all informative events -- they may indicate either genuinely clean conditions or failures in the detection mechanism.

Rationale: Systems that only process positive signals develop confirmation bias. By tracking what was expected but not found, the platform maintains awareness of its detection blind spots.

Enforcement: SOFT -- violations result in E1 WARNING with investigation triggered. The system logs the expected-but-absent signal and tracks it for follow-up.

Axiom 4: Time Decay (HARD Enforcement)

All beliefs carry mandatory timestamps and degrade in reliability over time. A security assessment from 6 months ago is less reliable than one from today. A network scan from 2024 does not accurately represent 2026 infrastructure. Time decay forces the platform to continuously re-verify its beliefs rather than treating past assessments as permanent truths.

Rationale: The world changes. Beliefs that were accurate yesterday may be dangerously wrong today. Without time decay, stale beliefs accumulate and create a false sense of certainty.

Enforcement: HARD -- E2 BLOCK for any belief without a timestamp. Automatic confidence degradation applied to beliefs exceeding their TTL (time-to-live).

Axiom 5: Unknown Valid (HARD Enforcement)

"I don't know" is a legitimate and honored epistemic state. The platform explicitly refuses to guess, extrapolate, or fabricate answers when evidence is insufficient. An unknown is represented as {:unknown, reason, metadata} rather than being silently replaced with a default or best guess.

Rationale: False certainty is more dangerous than acknowledged uncertainty. A system that says "the target has no vulnerabilities" when it actually means "I could not determine the target's vulnerability status" can lead to catastrophic security failures.

Enforcement: HARD -- E2 BLOCK for any operation that converts unknown states into definite claims without additional evidence.

Axiom 6: Source Independence (SOFT Enforcement)

Independent sources receive higher evidential weight than correlated sources. Two reports from the same underlying data source count as one signal, even if they are presented by different intermediaries. Source independence is evaluated by tracing the provenance chain of each signal.

Rationale: Information that appears to come from multiple sources but originates from a single root source creates false plurality. Intelligence analysis has repeatedly demonstrated that correlated sources masquerading as independent can lead to catastrophically overconfident assessments.

Enforcement: SOFT -- E1 WARNING for correlated sources. Bias assessment required when source independence cannot be verified.

Axiom 7: Provenance Mandatory (HARD Enforcement)

All beliefs must be traceable to their origins through an unbroken provenance chain. Every transformation, aggregation, and inference step that contributed to the belief must be recorded. If the provenance chain is broken -- if you cannot trace a claim back to its source evidence -- the claim is epistemically invalid.

Rationale: Without provenance, beliefs cannot be audited, disputed, or updated when source data changes. Provenance enables accountability and makes the reasoning process transparent and reproducible.

Enforcement: HARD -- E2 BLOCK for any belief without provenance metadata. Claims with broken provenance chains are rejected from the belief graph.

Implementation in Prismatic Platform

Axiom Validator Module

The platform implements axiom validation as a composable pipeline that every belief must pass through:

defmodule PrismaticNabla.AxiomValidator do
  @moduledoc """
  Validates beliefs against all seven NABLA axioms before they can
  enter the belief graph. Hard violations block; soft violations warn.
  """

  @type belief :: %{
    proposition: String.t(),
    signals: [signal()],
    provenance: provenance_chain(),
    timestamp: DateTime.t(),
    confidence: float(),
    contradictions: [belief_id()]
  }

  @type signal :: %{
    source: String.t(),
    value: term(),
    timestamp: DateTime.t(),
    source_chain: [String.t()]
  }

  @type provenance_chain :: [provenance_entry()]
  @type provenance_entry :: %{
    step: String.t(),
    actor: String.t(),
    timestamp: DateTime.t(),
    input_refs: [String.t()],
    transformation: String.t()
  }

  @type belief_id :: String.t()
  @type validation_result ::
          {:ok, belief()}
          | {:error, :hard_violation, atom(), String.t()}
          | {:warning, atom(), String.t(), belief()}

  @spec validate(belief()) :: validation_result()
  def validate(belief) do
    with :ok <- check_signal_plurality(belief),
         :ok <- check_contradiction_preservation(belief),
         :ok <- check_absence_tracking(belief),
         :ok <- check_time_decay(belief),
         :ok <- check_unknown_handling(belief),
         :ok <- check_source_independence(belief),
         :ok <- check_provenance(belief) do
      {:ok, belief}
    end
  end

  @spec check_signal_plurality(belief()) :: :ok | validation_result()
  defp check_signal_plurality(%{signals: signals}) when length(signals) >= 2 do
    :ok
  end

  defp check_signal_plurality(%{signals: signals}) do
    {:error, :hard_violation, :signal_plurality,
     "Belief requires minimum 2 signals, got #{length(signals)}"}
  end

  @spec check_contradiction_preservation(belief()) :: :ok | validation_result()
  defp check_contradiction_preservation(%{contradictions: contradictions})
       when is_list(contradictions) do
    :ok
  end

  defp check_contradiction_preservation(_belief) do
    {:error, :hard_violation, :contradiction_preservation,
     "Belief must track contradictions field (even if empty list)"}
  end

  @spec check_absence_tracking(belief()) :: :ok | validation_result()
  defp check_absence_tracking(belief) do
    expected_sources = get_expected_sources(belief.proposition)
    actual_sources = Enum.map(belief.signals, & &1.source)
    missing = expected_sources -- actual_sources

    case missing do
      [] ->
        :ok

      sources ->
        {:warning, :absence_informative,
         "Expected sources not present: #{inspect(sources)}", belief}
    end
  end

  @spec check_time_decay(belief()) :: :ok | validation_result()
  defp check_time_decay(%{timestamp: nil}) do
    {:error, :hard_violation, :time_decay, "Belief must have a timestamp"}
  end

  defp check_time_decay(%{timestamp: timestamp, confidence: confidence}) do
    age_hours = DateTime.diff(DateTime.utc_now(), timestamp, :hour)
    decay_factor = calculate_decay(age_hours)
    effective_confidence = confidence * decay_factor

    if effective_confidence < 0.1 do
      {:error, :hard_violation, :time_decay,
       "Belief has decayed below minimum threshold (age: #{age_hours}h, " <>
         "effective confidence: #{Float.round(effective_confidence, 3)})"}
    else
      :ok
    end
  end

  @spec check_unknown_handling(belief()) :: :ok | validation_result()
  defp check_unknown_handling(%{confidence: confidence})
       when confidence > 0.0 and confidence <= 1.0 do
    :ok
  end

  defp check_unknown_handling(%{confidence: confidence}) do
    {:error, :hard_violation, :unknown_valid,
     "Confidence must be between 0.0 and 1.0, got #{confidence}"}
  end

  @spec check_source_independence(belief()) :: :ok | validation_result()
  defp check_source_independence(%{signals: signals}) do
    source_chains = Enum.map(signals, & &1.source_chain)
    root_sources = Enum.map(source_chains, &List.last/1) |> Enum.uniq()

    if length(root_sources) < length(signals) do
      {:warning, :source_independence,
       "#{length(signals)} signals trace to only #{length(root_sources)} " <>
         "independent root sources", %{}}
    else
      :ok
    end
  end

  @spec check_provenance(belief()) :: :ok | validation_result()
  defp check_provenance(%{provenance: []}) do
    {:error, :hard_violation, :provenance_mandatory,
     "Belief must have at least one provenance entry"}
  end

  defp check_provenance(%{provenance: chain}) when is_list(chain) do
    if Enum.all?(chain, &valid_provenance_entry?/1) do
      :ok
    else
      {:error, :hard_violation, :provenance_mandatory,
       "Provenance chain contains invalid entries"}
    end
  end

  defp check_provenance(_belief) do
    {:error, :hard_violation, :provenance_mandatory,
     "Belief must have a provenance chain"}
  end

  @spec valid_provenance_entry?(provenance_entry()) :: boolean()
  defp valid_provenance_entry?(%{step: step, actor: actor, timestamp: ts})
       when is_binary(step) and is_binary(actor) and not is_nil(ts) do
    true
  end

  defp valid_provenance_entry?(_), do: false

  @spec calculate_decay(non_neg_integer()) :: float()
  defp calculate_decay(age_hours) do
    # Exponential decay with half-life of 168 hours (1 week)
    half_life = 168
    :math.pow(0.5, age_hours / half_life)
  end

  @spec get_expected_sources(String.t()) :: [String.t()]
  defp get_expected_sources(_proposition), do: []
end

Contradiction Tracker

The platform maintains an explicit contradiction registry that prevents contradiction burial:

defmodule PrismaticNabla.ContradictionTracker do
  @moduledoc """
  Tracks and preserves contradictions between beliefs.
  Implements Axiom 2 (Contradiction Preservation) by ensuring
  conflicting evidence is never silently discarded.
  """

  use GenServer

  @type contradiction :: %{
    id: String.t(),
    belief_a: String.t(),
    belief_b: String.t(),
    discovered_at: DateTime.t(),
    status: :open | :resolved | :investigating,
    resolution: String.t() | nil,
    evidence: [term()]
  }

  @type state :: %{
    contradictions: %{String.t() => contradiction()},
    open_count: non_neg_integer()
  }

  @spec start_link(keyword()) :: GenServer.on_start()
  def start_link(opts \\ []) do
    GenServer.start_link(__MODULE__, opts, name: __MODULE__)
  end

  @spec record(String.t(), String.t(), term()) :: {:ok, String.t()}
  def record(belief_a_id, belief_b_id, evidence) do
    GenServer.call(__MODULE__, {:record, belief_a_id, belief_b_id, evidence})
  end

  @spec open_contradictions() :: [contradiction()]
  def open_contradictions do
    GenServer.call(__MODULE__, :open_contradictions)
  end

  @spec resolve(String.t(), String.t()) :: :ok | {:error, :not_found}
  def resolve(contradiction_id, resolution) do
    GenServer.call(__MODULE__, {:resolve, contradiction_id, resolution})
  end

  @impl GenServer
  @spec init(keyword()) :: {:ok, state()}
  def init(_opts) do
    {:ok, %{contradictions: %{}, open_count: 0}}
  end

  @impl GenServer
  def handle_call({:record, belief_a, belief_b, evidence}, _from, state) do
    id = generate_id()

    contradiction = %{
      id: id,
      belief_a: belief_a,
      belief_b: belief_b,
      discovered_at: DateTime.utc_now(),
      status: :open,
      resolution: nil,
      evidence: [evidence]
    }

    :telemetry.execute(
      [:prismatic, :nabla, :contradiction, :recorded],
      %{count: state.open_count + 1},
      %{belief_a: belief_a, belief_b: belief_b}
    )

    new_state = %{
      state
      | contradictions: Map.put(state.contradictions, id, contradiction),
        open_count: state.open_count + 1
    }

    {:reply, {:ok, id}, new_state}
  end

  def handle_call(:open_contradictions, _from, state) do
    open =
      state.contradictions
      |> Map.values()
      |> Enum.filter(&(&1.status == :open))

    {:reply, open, state}
  end

  def handle_call({:resolve, id, resolution}, _from, state) do
    case Map.get(state.contradictions, id) do
      nil ->
        {:reply, {:error, :not_found}, state}

      contradiction ->
        updated = %{contradiction | status: :resolved, resolution: resolution}

        new_state = %{
          state
          | contradictions: Map.put(state.contradictions, id, updated),
            open_count: max(state.open_count - 1, 0)
        }

        {:reply, :ok, new_state}
    end
  end

  @spec generate_id() :: String.t()
  defp generate_id do
    :crypto.strong_rand_bytes(16) |> Base.encode16(case: :lower)
  end
end

Trinity Gate Integration

The NABLA Axioms are the first checkpoint in the Trinity Gate verification pipeline. No claim can pass through the Trinity Gate without first satisfying all seven axioms:

defmodule PrismaticNabla.TrinityGate do
  @moduledoc """
  Three-layer verification gate: Axiom Compliance -> Structural Consistency
  -> Logical Consistency -> Formal Necessity. All three must pass.
  """

  @type gate_result :: {:pass, map()} | {:fail, atom(), String.t()}

  @spec verify(PrismaticNabla.AxiomValidator.belief()) :: gate_result()
  def verify(belief) do
    with {:ok, validated} <- PrismaticNabla.AxiomValidator.validate(belief),
         :ok <- check_structural_consistency(validated),
         :ok <- check_logical_consistency(validated),
         :ok <- check_formal_necessity(validated) do
      {:pass, %{belief: validated, verified_at: DateTime.utc_now()}}
    else
      {:error, :hard_violation, axiom, reason} ->
        {:fail, axiom, reason}

      {:error, gate, reason} ->
        {:fail, gate, reason}
    end
  end

  @spec check_structural_consistency(map()) :: :ok | {:error, atom(), String.t()}
  defp check_structural_consistency(_belief) do
    # Verify belief network forms valid DAG (no cycles)
    :ok
  end

  @spec check_logical_consistency(map()) :: :ok | {:error, atom(), String.t()}
  defp check_logical_consistency(_belief) do
    # Verify propositions follow logical rules
    :ok
  end

  @spec check_formal_necessity(map()) :: :ok | {:error, atom(), String.t()}
  defp check_formal_necessity(_belief) do
    # Verify claims proven in formal systems (Modal Logic + Lean4)
    :ok
  end
end

Comparison with Alternatives

NABLA Axioms vs. Traditional Confidence Scoring

Most AI systems use simple confidence scores (0.0-1.0) to represent belief certainty. The NABLA Axioms go far beyond this by requiring provenance, plurality, and contradiction tracking. A traditional system might report "vulnerability confidence: 0.85" -- the NABLA framework requires knowing where that 0.85 came from, how many independent sources contributed, what contradicting evidence exists, and when the assessment expires.

AspectTraditional ConfidenceNABLA Axioms
ProvenanceNot trackedMandatory chain
ContradictionOverwrittenPreserved
Source trackingSingle scoreMulti-signal plurality
Time handlingStaticDecay-aware
Unknown statesDefault to 0 or 0.5Explicit :unknown type
AuditabilityLowFull trace

NABLA Axioms vs. Bayesian Reasoning

Bayesian reasoning updates beliefs based on new evidence using Bayes' theorem. The NABLA Axioms are compatible with Bayesian updating but add constraints that vanilla Bayesian reasoning lacks: source independence verification (correlated evidence should not be double-counted), contradiction preservation (conflicting priors and likelihoods are tracked, not silently resolved), and provenance requirements (the Bayesian update itself must be auditable).

NABLA Axioms vs. Intelligence Analysis Standards

Intelligence community standards (ACH -- Analysis of Competing Hypotheses, Structured Analytic Techniques) share many goals with the NABLA Axioms. The key difference is automation: the NABLA Axioms are machine-enforced at the code level, not dependent on analyst discipline. ACH requires human analysts to consciously consider alternative hypotheses; Axiom 2 (Contradiction Preservation) automatically prevents hypothesis dismissal.

Best Practices

1. Design Data Structures with Axioms in Mind

Every data structure that represents a belief, assessment, or claim should include fields for signals (Axiom 1), contradictions (Axiom 2), timestamp (Axiom 4), confidence (Axiom 5), source chain (Axiom 6), and provenance (Axiom 7). Retro-fitting axiom compliance onto existing structures is far harder than designing for it from the start.

2. Validate Early, Validate Often

Run axiom validation at data ingestion time, not just at decision time. Catching a signal plurality violation when data enters the system is vastly cheaper than discovering it during a critical security assessment.

3. Track Absence Explicitly

When a search returns no results, create an explicit "absence record" documenting what was searched, when, with what parameters, and what was expected. This turns Axiom 3 from a conceptual principle into actionable data.

4. Set Appropriate Decay Rates

Different domains have different information half-lives. Network infrastructure changes faster than organizational structure. Security vulnerabilities have shorter half-lives than compliance certifications. Configure time decay parameters per domain, not globally.

5. Audit Provenance Chains Regularly

Provenance chains can break when upstream systems change their output formats, when intermediate processors are updated, or when data is manually corrected. Regular provenance audits detect broken chains before they cause downstream failures.

Common Pitfalls

1. Treating Axioms as Optional Guidelines

The axioms are hard constraints, not best practices. Systems that treat them as optional -- validating axioms only in production, skipping validation in development -- develop epistemic debt that compounds over time. The Prismatic Platform enforces axioms in all environments.

2. Confusing Correlation with Independence

Two data sources that both scrape the same underlying API are not independent, even if they present the data differently. Source independence (Axiom 6) requires tracing the provenance chain to the root source and verifying that root sources are genuinely independent.

3. Resolving Contradictions Prematurely

The human instinct is to resolve contradictions immediately -- to decide which side is "right." Axiom 2 demands patience: preserve both sides, gather more evidence, and resolve only when the evidence supports a clear resolution. Premature resolution is a form of information destruction.

4. Neglecting Time Decay for "Obvious" Truths

Even facts that seem permanent can change. A company's domain ownership, a server's SSL certificate, a person's job title -- all change over time. Applying time decay universally, even to seemingly stable facts, prevents the accumulation of stale beliefs.

5. Circular Provenance

When system A cites system B, which cites system A, the provenance chain is circular and the belief has no grounding in external reality. The provenance validator must detect and reject circular chains.

Use Cases

1. OSINT Intelligence Fusion

When the OSINT toolbox queries 120 sources about a target, the axioms ensure that: results from multiple sources are cross-validated (Axiom 1), conflicting findings are preserved and flagged (Axiom 2), sources that return no data are logged (Axiom 3), all findings carry timestamps (Axiom 4), and every claim traces back to its source adapter (Axiom 7).

2. Security Rating Computation

The Prismatic Perimeter security rating system uses axiom-compliant belief formation. A security grade of "B" is never assigned from a single scan -- it requires multiple independent assessment signals, preservation of any contradicting findings, and a full provenance chain from raw scan data through scoring algorithms to the final rating.

3. Agent Decision Making

When the 530+ AIAD agents make decisions, each decision must be axiom-compliant. An agent cannot act on a single signal, cannot ignore contradicting inputs, and must record the full provenance of its decision rationale. This creates an auditable decision trail across the entire agent ecosystem.

4. Quality Assessment

The Quality Floor Guardian applies axiom-compliant reasoning to quality metrics. A quality score of 100/100 is not accepted from a single analysis run -- it requires consistent results across multiple evaluation methods, acknowledgment of any quality dimensions where assessment is uncertain, and timestamps on every metric.

See Also

Connect & Contribute

Created by Tomas Korcak (korczis) | Open Source under GHL

Back to Glossary