Epistemic — Deterministic Assurance Layer

A deterministic assurance layer for probabilistic intelligence.

Core Axiom

• No single model, human, or tool can be trusted to produce truth alone.
• Truth emerges through independent reasoning, adversarial critique, deterministic verification, and evidence firmly grounded in execution.
• LLMs are witnesses, never judges.

What It Is

Epistemic is a distributed, zero-trust code verification system. It seamlessly orchestrates multiple AI models alongside deterministic tools to converge on the best attainable truth regarding the safety, correctness, and inherent risk of code changes.

Crucially, final authority is never delegated to an AI. Humans remain the final authority. Always.

It functions as a Git-native epistemic layer residing above existing IDEs — essentially, "the place you go after the code is written."

What It Is NOT

• ❌ A code editor
• ❌ An auto-merge bot
• ❌ A single-model assistant
• ❌ A black-box "AI reviewer"
• ❌ A replacement for human engineers

First Principles

1. Deterministic Supremacy: Final verdicts are computed entirely deterministically. LLMs are treated solely as witnesses, never as judges. Outcomes are 100% reproducible from inputs + evidence + rules.
2. Tool-Evidence Supremacy: Execution fundamentally outranks opinion. Evidence includes static analysis, tests (unit/integration/e2e), property-based testing, runtime sandboxing, security scans, and visual diffs.
3. Byzantine Fault Tolerance: The system explicitly assumes that models hallucinate, tools fail, agents disagree, and jobs unexpectedly die. Truth robustly emerges via redundancy, adversarial peer review, and deterministic aggregation.

Verification Lifecycle

1. Context acquisition
2. Isolated execution (Leveraging Firecracker microVMs)
3. Tool verification
4. Multi-agent witness generation
5. Adversarial peer review
6. Deterministic verdict calculation
7. Truth publication

(Note: Any systemic failure defaults to an UNCERTAIN verdict; the system never defaults to CONFIRMED).

Verdict Types

• CONFIRMED: Hard evidence unequivocally supports the claim.
• REJECTED: Hard evidence directly contradicts the claim.
• UNCERTAIN: Insufficient evidence exists (the safe system default).
• Each verdict explicitly includes granular evidence citations.

Tech Stack

Layer	Technology
Core Language	Python (orchestration, analysis, deterministic engine)
Performance Paths	Rust (parsers, isolation helpers)
Workflow Orchestration	Temporal (mandatory for robust multi-stage pipelines)
Code Isolation	Firecracker microVMs (mandatory for executing untrusted code)
Multi-Model Ensemble	OpenAI, Anthropic, Gemini, Grok, DeepSeek
Data	PostgreSQL (SQL + JSONB), pgvector, Redis (cache), S3-compatible storage
Interfaces	CLI (primary), GitHub Checks, Web Studio, IDE extensions
CI/CD	Dual lanes: fast unit tests (100% coverage gate) + substrate integration (Linux+KVM)

Dual Execution Planes

• Open-Source Plane: Local/self-hosted models (Ollama, vLLM, llama.cpp) ensuring full data ownership and enabling offline reproducibility.
• Frontier Plane: Hosted frontier models (OpenAI, Anthropic, Gemini) unlocking higher reasoning capabilities, heavily policy-gated.
• Both planes are instantly interchangeable via a strict adapter contract.

Spec-Driven Development

The architecture was forged through Spec-Driven Development:

• Multiple, competing architectural specs were independently generated by Claude, OpenAI, Gemini, Grok, and DeepSeek.
• These were rigorously converged into a locked, canonical v1.2 spec.
• The SPEC_VERSION file pins the repository to a specific spec version.
• Documentation strictly constrains system behavior — spec drift is considered a critical failure.

Sprint History

• Sprint 1-3: Core pipeline, worker, trigger, librarian, and achieving a 100% unit test coverage gate.
• Sprint 4: Substrate integration, Firecracker CI lane, and dual CI architecture validation.

Status

Sprint 4 complete. Core verification pipeline is fully operational.