Trinity Passage

epistemic

Trinity Passage

Definition

Trinity Passage refers to the successful traversal of all layers of the Trinity Gate verification mechanism, certifying that a platform belief, decision, or conclusion has been independently validated across three orthogonal verification dimensions -- structural consistency (graph theory), logical consistency (rule-based evaluation), and formal necessity (modal logic and Lean4 theorem proving) -- plus a meta-integrity check that validates the gate's own correctness. No claim within the Prismatic Platform is considered established without Trinity Passage. The passage is the formal act of epistemic certification.

The distinction between "Trinity Gate" and "Trinity Passage" is important: the Trinity Gate is the mechanism (the verification apparatus), while Trinity Passage is the event (the successful completion of verification). A belief "attempts" the Trinity Gate and either "achieves" Trinity Passage or "fails" the gate. This distinction matters because the passage itself generates a cryptographically signed certificate -- a formal attestation that verification was completed, which layers were evaluated, what evidence was considered, and when the passage occurred. This certificate serves as the authorization token for the Transition Protocol, enabling the shift from exploration to execution.

Within the Prismatic Platform ecosystem, the platform maintains 629 trinity entities with 100% passage compliance. Every belief that enters the execution phase has achieved Trinity Passage. Every decision that drives platform action carries a passage certificate. The 13-layer extended Trinity Gate architecture (introduced in Generation 19) adds ten additional verification layers beyond the original three, creating the most rigorous epistemic verification system in the platform's history.

The Passage Sequence

Trinity Passage follows a strict sequential evaluation across four layers, with each layer serving as a prerequisite for the next:

Layer 1: Structural Consistency Check

The first layer evaluates the topological integrity of the belief graph using graph-theoretic analysis. This is the fastest evaluation and the most common point of failure (approximately 40% of all gate rejections).

What is verified:

  • The belief network forms a valid directed acyclic graph (DAG)
  • No circular reasoning patterns exist (A supports B supports C supports A)
  • Every conclusion node traces back to evidence nodes through valid edges
  • Contradictory evidence is explicitly represented with proper annotation
  • No orphaned belief nodes exist (conclusions without supporting evidence)
  • Inference direction flows from evidence upward to conclusions

Passage criteria: Zero structural violations. Any circular dependency, orphaned node, or hidden contradiction results in Layer 1 failure, and the passage attempt terminates.

Common failure modes:

  1. Circular reasoning: An investigation where company A's legitimacy is supported by its relationship with company B, and company B's legitimacy is supported by its relationship with company A
  2. Evidence orphans: A conclusion that appears in the belief graph but has no supporting evidence path -- typically caused by evidence being deleted without updating dependent conclusions
  3. Contradiction hiding: Representing contradictory evidence in a way that structurally obscures the contradiction from downstream layers

Layer 2: Logical Consistency Check

The second layer evaluates whether the inference rules applied within the structurally valid graph are logically sound. A belief graph can be structurally perfect (valid DAG, no orphans) while containing logically invalid reasoning steps.

What is verified:

  • Conclusions follow from premises through valid inference rules
  • No conclusion asserts more than its premises support (overreach detection)
  • All seven NABLA Infinity axioms are satisfied at every inference step
  • Hidden assumptions are detected through dependency analysis
  • Inference rules themselves are validated for soundness
  • Signal Plurality compliance at every belief node
  • Provenance Mandatory compliance throughout

Passage criteria: Zero logical violations. Any unsound inference, axiom breach, or hidden assumption results in Layer 2 failure.

Common failure modes:

  1. Inference overreach: Drawing a stronger conclusion than the evidence supports (e.g., "company is sanctioned" from "company shares an address with a sanctioned entity")
  2. Assumption leakage: Using premises that were never stated or validated, typically introduced by pattern matching against training data rather than the actual evidence
  3. Axiom bypass: Reaching a conclusion while skipping one or more NABLA axioms (e.g., forming a belief on a single source in violation of Signal Plurality)

Layer 3: Formal Necessity Check

The third layer is the most computationally expensive and the most rigorous. It uses modal logic and Lean4 formal proofs to determine whether the conclusion is not merely probable but necessary given the evidence.

What is verified:

  • The conclusion is necessary in all possible worlds consistent with the evidence (modal logic)
  • The core claim can be translated into a Lean4 theorem and formally proved
  • The proof uses minimal assumptions (assumption minimality)
  • When proofs fail, explicit counterexamples are constructed
  • The proof is robust against evidence removal (removing any single piece of evidence does not invalidate the proof unless that evidence was essential)

Passage criteria: Formal proof succeeds with minimal assumptions. The conclusion must be proven necessary, not merely possible.

Common failure modes:

  1. Possibility without necessity: The conclusion is consistent with the evidence but not forced by it -- other conclusions are equally consistent
  2. Assumption fragility: The proof depends on an assumption that could easily be false, making the conclusion technically correct but practically unreliable
  3. Counterexample existence: An explicit scenario is constructed where the evidence holds but the conclusion does not

Layer 4: Meta-Integrity Check

The fourth layer validates the gate mechanism itself, ensuring that the three primary checks were conducted properly:

What is verified:

  • Gate independence: The three layers evaluated independently without influencing each other
  • Gate completeness: Verification covered the full scope of the claim, not a subset
  • Self-consistency: The meta-layer applies structural, logical, and formal checks to its own evaluation
  • Tamper detection: No attempts to bypass, weaken, or scope-reduce gate checks

Passage criteria: All meta-integrity conditions satisfied. Any independence violation, scope reduction, or tamper indicator results in meta-integrity failure.

The 13-Layer Extended Architecture

Generation 19 of the Prismatic Platform introduced the 13-layer extended Trinity Gate, adding ten additional verification layers to the original four. These extended layers provide defense-in-depth for critical decisions:

LayerNameVerification TypeAdded In
1Structural ConsistencyGraph TheoryGen 1
2Logical ConsistencyRule-BasedGen 1
3Formal NecessityModal Logic + Lean4Gen 1
4Meta-IntegritySelf-VerificationGen 3
5Temporal ConsistencyTime-Series ValidationGen 8
6Cross-Domain CoherenceMulti-Domain AlignmentGen 10
7Adversarial RobustnessRed Team SimulationGen 12
8Provenance Chain IntegrityEnd-to-End TraceabilityGen 13
9Axiom Compliance AuditFull NABLA CheckGen 14
10Confidence CalibrationScore Accuracy VerificationGen 15
11Agent ConsensusMulti-Agent AgreementGen 16
12External ValidationIndependent Source Cross-CheckGen 17
13Formal Certificate GenerationCryptographic AttestationGen 19

Not all 13 layers are required for every passage. The layer requirements scale with the decision context:

ContextRequired LayersMinimum for Passage
Critical DecisionsAll 1313/13
Standard OperationsLayers 1-99/9
Exploratory AnalysisLayers 1-44/4 (recommended)
Research QueriesLayers 1-33/3 (optional)

The Passage Certificate

Upon successful Trinity Passage, the system generates a signed Passage Certificate that serves as the formal authorization for execution:

defmodule PrismaticTrinityNexus.PassageCertificate do
  @moduledoc """
  Represents a successful Trinity Passage -- the cryptographically
  signed attestation that a belief has passed all required verification
  layers. The certificate is immutable once generated and serves as
  the authorization token for the Transition Protocol.

  Certificates include the complete verification trace: which layers
  were evaluated, what evidence was considered, what proofs were
  constructed, and the timestamp of passage. This trace enables
  post-hoc auditing of any execution decision.
  """

  @type t :: %__MODULE__{
          id: String.t(),
          belief_id: String.t(),
          timestamp: DateTime.t(),
          layers_evaluated: [layer_result()],
          total_layers: pos_integer(),
          layers_passed: pos_integer(),
          confidence_at_passage: float(),
          context: atom(),
          evidence_snapshot: [String.t()],
          formal_proof_hash: String.t() | nil,
          signature: binary(),
          valid_until: DateTime.t()
        }

  @type layer_result :: %{
          layer: pos_integer(),
          name: String.t(),
          status: :passed | :failed | :skipped,
          duration_ms: non_neg_integer(),
          diagnostics: map()
        }

  @spec generate(belief_id :: String.t(), evaluation :: map()) ::
          {:ok, t()} | {:error, :passage_failed}
  def generate(belief_id, evaluation) do
    case all_required_layers_passed?(evaluation) do
      true ->
        certificate = build_certificate(belief_id, evaluation)
        signed = sign_certificate(certificate)
        persist_certificate(signed)
        {:ok, signed}

      false ->
        {:error, :passage_failed}
    end
  end

  @spec verify(certificate :: t()) :: {:ok, :valid} | {:error, :invalid | :expired}
  def verify(%__MODULE__{} = certificate) do
    with :ok <- verify_signature(certificate),
         :ok <- verify_expiry(certificate),
         :ok <- verify_integrity(certificate) do
      {:ok, :valid}
    end
  end

  @spec audit_trail(certificate :: t()) :: {:ok, [audit_entry()]}
  def audit_trail(%__MODULE__{} = certificate) do
    {:ok, reconstruct_trail(certificate)}
  end
end

The GateEvaluator orchestrates the full passage evaluation:

defmodule PrismaticTrinityNexus.GateEvaluator do
  @moduledoc """
  Orchestrates the sequential evaluation of Trinity Gate layers for
  a given belief. Manages the passage sequence, enforces layer
  dependencies, generates diagnostic reports for failures, and
  produces Passage Certificates for successes.

  The evaluator is deterministic: the same belief graph with the same
  evidence always produces the same passage result. No randomness,
  no race conditions, no order dependence.
  """

  use GenServer

  alias PrismaticTrinityNexus.{PassageCertificate, LayerRegistry}
  alias PrismaticTrinityNexus.Layers.{Structural, Logical, Formal, MetaIntegrity}

  @type evaluation_result ::
          {:ok, PassageCertificate.t()}
          | {:error, :layer_failed, failure_report()}

  @type failure_report :: %{
          layer: pos_integer(),
          layer_name: String.t(),
          reason: atom(),
          diagnostics: map(),
          remediation_hints: [String.t()]
        }

  @spec evaluate(belief_id :: String.t(), context :: atom()) :: evaluation_result()
  def evaluate(belief_id, context \\ :standard) do
    GenServer.call(__MODULE__, {:evaluate, belief_id, context}, :infinity)
  end

  @impl GenServer
  def handle_call({:evaluate, belief_id, context}, _from, state) do
    required_layers = LayerRegistry.layers_for_context(context)

    result =
      Enum.reduce_while(required_layers, {:ok, []}, fn layer, {:ok, results} ->
        case evaluate_layer(layer, belief_id, results) do
          {:ok, layer_result} ->
            {:cont, {:ok, [layer_result | results]}}

          {:error, _} = error ->
            {:halt, error}
        end
      end)

    case result do
      {:ok, layer_results} ->
        {:ok, certificate} =
          PassageCertificate.generate(belief_id, %{
            layers: Enum.reverse(layer_results),
            context: context
          })

        emit_telemetry(:passage_achieved, belief_id, certificate)
        {:reply, {:ok, certificate}, state}

      {:error, layer_failure} ->
        emit_telemetry(:passage_failed, belief_id, layer_failure)
        {:reply, {:error, :layer_failed, layer_failure}, state}
    end
  end

  @spec evaluate_layer(layer :: module(), belief_id :: String.t(), prior :: list()) ::
          {:ok, map()} | {:error, map()}
  defp evaluate_layer(layer, belief_id, prior_results) do
    start_time = System.monotonic_time(:millisecond)
    result = layer.evaluate(belief_id, prior_results)
    duration = System.monotonic_time(:millisecond) - start_time

    case result do
      {:ok, diagnostics} ->
        {:ok, %{layer: layer.layer_number(), name: layer.name(),
                 status: :passed, duration_ms: duration, diagnostics: diagnostics}}

      {:error, reason, diagnostics} ->
        {:error, %{layer: layer.layer_number(), layer_name: layer.name(),
                   reason: reason, diagnostics: diagnostics,
                   remediation_hints: layer.remediation_hints(reason)}}
    end
  end
end

Passage vs. Failure: Diagnostic Analysis

When a passage attempt fails, the system produces a detailed diagnostic report that identifies exactly which layer failed, why it failed, and what evidence would be needed to resolve the failure. This diagnostic is critical because it transforms a binary "pass/fail" into an actionable improvement path:

Structural Failure Diagnostic Example:

Layer 1 FAILED: Structural Consistency
Reason: circular_dependency_detected
Location: belief_graph.edges[47..52]
Cycle: entity_A.legitimacy -> entity_B.endorsement -> entity_A.legitimacy
Remediation: Break the cycle by providing independent evidence for
             entity_A.legitimacy that does not depend on entity_B

Logical Failure Diagnostic Example:

Layer 2 FAILED: Logical Consistency
Reason: inference_overreach
Location: belief_graph.nodes["sanctions_conclusion"]
Issue: Conclusion "entity is sanctions-evading" requires ownership link,
       but only address proximity was established
Remediation: Provide evidence of beneficial ownership connection
             or downgrade conclusion to "address proximity noted"

Formal Failure Diagnostic Example:

Layer 3 FAILED: Formal Necessity
Reason: counterexample_exists
Counterexample: Possible world where address_match AND no_sanctions_evasion
                (shared commercial building with 200+ tenants)
Remediation: Provide evidence that excludes the counterexample scenario
             (e.g., exclusive tenancy, direct ownership link)

These diagnostics embody the platform's commitment to actionable feedback. A failed passage is not a dead end -- it is a map showing the path to successful passage.

Passage Statistics and Performance

The platform tracks detailed passage statistics across all 629 trinity entities:

MetricValueNotes
Total entities629All managed by Trinity Gate
Passage compliance100%All executing beliefs have certificates
Layer 1 failure rate~40%Most common failure point
Layer 2 failure rate~30%Second most common
Layer 3 failure rate~20%Computationally expensive
Layer 4 failure rate~5%Rare but critical
Average passage time< 100msFor standard 4-layer passage
Extended 13-layer time< 500msFor critical decisions
Certificate verification< 5msSignature + integrity check

Relationship to Transition Protocol

Trinity Passage is the central verification event within the Transition Protocol. The protocol's second condition (of three) requires Trinity Passage before any transition from exploration to execution is authorized. Without a valid Passage Certificate, the Transition Protocol blocks the shift to execution mode regardless of how high the confidence score is.

This relationship creates a two-factor verification model: high confidence (a quantitative measure of evidence strength) combined with Trinity Passage (a qualitative verification of reasoning integrity). Neither alone is sufficient. A belief can have 99% confidence but fail structural consistency due to circular reasoning. Conversely, a belief can pass all gate layers but have insufficient evidence for high confidence. Only when both conditions are met (along with full axiom compliance) does the transition proceed.

Formal Properties of Passage

Trinity Passage satisfies several formally verified properties that ensure its reliability:

  1. Soundness: If a belief achieves Trinity Passage, the conclusion is consistent with the evidence across all three verification dimensions. Passage is never granted for structurally incoherent, logically unsound, or formally unnecessary conclusions.

  2. Completeness: If a belief is structurally consistent, logically sound, and formally necessary, it will achieve Trinity Passage. The gate does not reject valid conclusions.

  3. Independence: Each layer evaluates independently. A pass in Layer 1 does not influence Layer 2's evaluation. The meta-integrity layer verifies this independence.

  4. Determinism: The same belief graph with the same evidence always produces the same passage result. There is no non-determinism in the evaluation.

  5. Non-forgery: Passage Certificates are cryptographically signed. A certificate cannot be forged, and a belief cannot claim passage without a valid certificate.

  6. Auditability: Every passage (and every failure) generates a complete audit trail that can be reconstructed from the certificate.

Historical Evolution

The concept of Trinity Passage has evolved significantly across platform generations:

  • Gen 1-2: Original three-layer gate with manual passage verification
  • Gen 3: Addition of meta-integrity layer (Layer 4)
  • Gen 6: Integration with the Transition Protocol (passage as transition condition)
  • Gen 8-10: Extended layers 5-6 (temporal consistency, cross-domain coherence)
  • Gen 12-17: Layers 7-12 (adversarial robustness through external validation)
  • Gen 19: Layer 13 (formal certificate generation), completing the 13-layer architecture

Each extension addressed a specific failure mode discovered in production use. Temporal consistency (Layer 5) was added after a case where structurally and logically valid conclusions were based on contradictory evidence from different time periods. Adversarial robustness (Layer 7) was added after Red Team exercises identified beliefs that passed three layers but were vulnerable to targeted evidence manipulation.

Passage in Multi-Agent Systems

In the platform's multi-agent architecture (530+ AIAD agents), Trinity Passage introduces coordination challenges. When multiple agents contribute to a shared belief graph, the passage must verify not just the final graph but the contribution integrity of each agent:

  • Agent contribution tracing: Each node in the belief graph carries the contributing agent's identifier, enabling per-agent audit of the evidence chain
  • Cross-agent consistency: Evidence from different agents must be consistent when it overlaps, and contradictions must be explicitly annotated (not silently overwritten by the last agent to write)
  • Consensus verification (Layer 11): For critical decisions, multiple agents independently evaluate the same evidence and must reach consistent conclusions before passage is granted

This multi-agent dimension adds complexity but also increases robustness. A single agent's error is more likely to be caught when multiple agents independently verify the same conclusion.

See Also

  • Architecture -- Platform architecture overview
  • Technologies -- Technology stack details
  • Glossary Index -- Complete glossary of platform concepts

Connect & Contribute

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

Back to Glossary