Runs as a pre-deployment verification layer (CI/CD, agent pipelines, or manual evaluation).
This system decides whether software should be trusted.
It evaluates a claim across 10 structural enforcement gates.
If any gate fails → execution halts immediately.
If all pass → the result is cryptographically sealed with a reproducible trace.
Caution
Example: auth-api v0.3.0
Gate 8: SECURITY → SECRET_DETECTED
Result: VIOLATION (execution halted)
This would have prevented shipping a compromised authentication system.
- Define a BuildClaim (what your system asserts is true).
- Run it through the 10-gate pipeline.
- The system returns:
PASS,VIOLATION,MODEL_BOUND, orINCONCLUSIVE. - If
PASS→ the result is sealed and your software is deployed.
What this is: A deterministic verification protocol that evaluates software claims across 10 structural enforcement gates.
What it does:
It decides whether a system can actually be trusted. It enforces a strict terminal outcome: PASS, VIOLATION, MODEL_BOUND, or INCONCLUSIVE.
What makes it different: It halts immediately on failure, mandates mathematically independent evidence, and guarantees an immutable, cryptographic execution trace on out S.E.A.L. Ledger.
Every pipeline execution maps directly to a strict terminal outcome. There is no gray area.
flowchart LR
EVAL["Evaluate Claim"] --> PASS["🟢 PASS"]
EVAL --> VIOLATION["🔴 VIOLATION"]
EVAL --> MODEL_BOUND["🟡 MODEL_BOUND"]
EVAL --> INCONCLUSIVE["⚪ INCONCLUSIVE"]
PASS -->|"All Gates Satisfied"| EXEC["Full Execution / Stable Continuation"]
VIOLATION -->|"Constraint Failure/Risk"| HALT["Halt Early / Terminal Shutdown"]
MODEL_BOUND -->|"Thresholds Redlining"| FLAG["Flag Risk / Isolated Containment"]
INCONCLUSIVE -->|"Insufficient Data"| MORE["Require More Evidence / Terminal"]
classDef pass fill:#0e2a14,stroke:#5cb870,color:#5cb870,stroke-width:2px;
classDef fail fill:#2a0e0e,stroke:#e05252,color:#e05252,stroke-width:2px;
classDef warn fill:#2a230e,stroke:#d4a03c,color:#d4a03c,stroke-width:2px;
classDef inc fill:#1a1a1a,stroke:#9d9b95,color:#9d9b95,stroke-width:2px;
class PASS,EXEC pass;
class VIOLATION,HALT fail;
class MODEL_BOUND,FLAG warn;
class INCONCLUSIVE,MORE inc;
The following scenarios are canonical demonstrations of the pipeline's non-PASS terminal states, designed to enforce trust by preventing silent failure. (The auth-api trace example above demonstrates the immediate execution halt of a VIOLATION).
1. The VIOLATION State → auth-api v0.3.0
Gate 8: SECURITY detected a hardcoded secret in the build manifest. The pipeline halted instantly. The system was shut down before deployment, averting a critical supply-chain breach.
2. The MODEL_BOUND State → pricing-engine v1.2.4
Gate 9: ADVERSARY fuzzing revealed that a 15% perturbation in bounds degraded 30% of the cost paths over threshold. The pipeline flagged the fragility risk and forced isolated containment, averting silent structural degradation.
3. The INCONCLUSIVE State → ml-pipeline v4.0.1
Gate 4: EVIDENCE found that 3 independent sources were required, but only 2 were provided (
K < 3). Quality could not be established. The system halted execution and demanded more evidence to proceed, averting unverified trust.
THIS IS A SYSTEM THAT HAS DEMONSTRATED:
- CORRECTNESS
- DISCIPLINE
- HONESTY
- REPRODUCIBILITY
- Shipping code with hidden secrets
- Passing tests but failing under perturbation
- Trusting single-source or biased evidence
- Silent cost or threshold overruns
- Undetected supply chain risk
VERITAS Ω-CODE v2.0 is the canonical verification protocol for the VERITAS ecosystem. It enforces its strict, 10-gate evaluation pipeline powered by the Sovereign Session Protocol and the omega-brain-mcp.
"If it cannot be expressed as typed, declared, constraint-bound assertions with artifact evidence, it cannot be evaluated."
This repository serves as the definitive source of truth for the v2.0 framework, containing the canonical specifications, full execution traces, and high-fidelity HTML/MD documentation artifacts.
The core mechanism of VERITAS is the 10-Gate Pipeline. Every BuildClaim must pass sequentially through these structural enforcement gates. A failure at any gate halts pipeline execution.
flowchart LR
G1[1. INTAKE] --> G2[2. TYPE]
G2 --> G3[3. DEPENDENCY]
G3 --> G4[4. EVIDENCE]
G4 --> G5[5. MATH]
G5 --> G6[6. COST]
G6 --> G7[7. INCENTIVE]
G7 --> G8[8. SECURITY]
G8 --> G9[9. ADVERSARY]
G9 --> G10[10. TRACE/SEAL]
classDef default fill:#1a1a1a,stroke:#d4af37,stroke-width:1px,color:#e8e6e1;
To immediately experiment with the protocol, see the following public endpoints:
- JSON Schema Definition:
schemas/buildclaim.schema.json→ The canonical JSON schema mapped directly from the CLAEG specification. - Reference Parser CLI:
bin/veritas_stub.py→ A lightweight Python CLI stub demonstrating how INTAKE handles structural parsing, canonicalization, and hashing.
# Test a theoretical claim through the INTAKE gate
python bin/veritas_stub.py ./path/to/mock_claim.json| # | Gate Name | Enforcement Focus | Status |
|---|---|---|---|
| 1 | INTAKE | Parse, validate, and canonicalize the BuildClaim. | Enforced |
| 2 | TYPE | Validate type safety, unit consistency, and symbol resolution. | Enforced |
| 3 | DEPENDENCY | Supply chain verification and CVE dependency depth scanning. | Enforced |
| 4 | EVIDENCE | Evaluate the quality, independence, and agreement of evidence. | Enforced |
| 5 | MATH | Verify that declared constraints are satisfiable given the evidence. | Enforced |
| 6 | COST | Verify resource consumption is within declared bounds. | Enforced |
| 7 | INCENTIVE | Detect evidence source dominance and vendor concentration. | Enforced |
| 8 | SECURITY | Dedicated security posture evaluation (SAST, secrets, TLS). | Enforced |
| 9 | ADVERSARY | Hostile verification (Fuzz, mutate, exploit, stress-test). | Enforced |
| 10 | TRACE/SEAL | Compute the cryptographic seal over the entire pipeline run. | Enforced |
This repository tracks the immutable specification and reports of the VERITAS Ω-CODE core:
VERITAS_OMEGA_CODE_v2.0.html: Premium HTML rendition of the v2.0 specification, built with Sovereign Gold (#C9A84C) and Obsidian (#09090B) aesthetics.VERITAS_OMEGA_CODE_v2.0.md: The raw, machine-readable Markdown canonical specification.OMEGA_CODE_FULL_RUN_REPORT.html: Complete, cryptographically sealed run report generated by theomega-brain-mcpexecution.VERITAS_OMEGA_CODE_v1.0.html/.md: Legacy specifications preserved for cryptographic lineage and trace verification.
Right now, trust is implied. VERITAS makes it explicit. Every evaluation resolves to one of four CLAEG terminal states:
All gates satisfied. Artifact is fully verified and deployable under the declared operational regime. -> STABLE_CONTINUATION
Gates mathematically pass, but computational resources, coverage, or structural confidence levels are riding the redline. -> ISOLATED_CONTAINMENT
Insufficient evidence independence, structurally low quality, or algorithmic decidability timeouts. The system cannot affirm trust. -> TERMINAL_SHUTDOWN
Constraint failure, severe vulnerability, type mismatch, or threshold collapse. The system halted. -> TERMINAL_SHUTDOWN
| Subsystem | Role |
|---|---|
omega-brain-mcp |
Hosts the 10-gate pipeline; exposes evaluation tools; appends seal to S.E.A.L. hash chain. |
| AEGIS-Rewrite | Receives VIOLATION records and applies deterministic code fixes. |
| Gravity-Omega v2 | Execution host; enforces VTP signature on gate outputs before downstream routing. |
| S.E.A.L. Ledger | Append-only chain of cryptographic seal values ensuring state continuity. |
Built by RJ Lopez | VERITAS Framework