architecture
The independent verifier for AI systems.
Turiya is an independent verifier for AI systems: agents, fraud models, RAG, copilots. It doesn’t measure how well a system does. It checks whether the system did what it claimed. Capture the claim, re-check the effect against what actually happened, sign the verdict.
The assurance standards split on this. ISO/IEC 42001 and 42006 certify an AI management system: an organization’s policies, objectives and processes. AIUC-1 tests the agent itself, adversarially, and retests quarterly. Turiya asks a narrower question than either: did this system do the specific thing it said it did?
How It Works
1. Claim Extraction
Every verification starts with a claim: a falsifiable assertion with an attributor and a source. “This patch fixes the bug.” “This change passes the test.” “This record was updated correctly.” Turiya names the claim before it tests anything, so it never measures a property no one asserted.
2. Independent Effect Re-check
Turiya re-runs the real effect independently (the test that must pass, the diff that must apply, the record that must change) on the real repo, at the real commit. It does not trust the system’s self-report. A claim of success is checked against the effect, not the narration.
3. Verdict + Proof
The verdict lattice is asymmetric: falsified, not_falsified (provisional, not proof), certified (bounded formal check), or indeterminate (an honest refusal). Two run states sit beside the verdict: unsupported (we could not analyze it) and error (infrastructure failed). Turiya never says “true”. Every verdict is signed (Ed25519) and content-addressed (SHA-256) into a proof-carrying receipt that anyone can re-verify with the public key.
What It Verifies
The engine is not limited to code, and it is not limited to a list. It verifies any system whose claim leaves a checkable effect. These are the surfaces it reaches that effect through:
Those surfaces are one axis. This is the other: the domains we have already signed receipts in, across seventeen system types. Code effects, fraud and credit classification, sanctions screening, fairness, anomaly detection, multi-agent orchestration, forecast, recommendation, computer vision, speech, scientific AI, RAG grounding, agents, truth, efficacy, and honesty.
Neither list is the boundary. The boundary is falsifiability: a claim leaves a checkable effect, or it does not. Where it does not, we answer indeterminate rather than invent a score.
Requirements
| Python | 3.12+ |
| Runtime | Any: no GPU required |
| Model access | OpenAI / Anthropic / DeepSeek API, or local |
| Target | A git repo, a test, or a specification |
| OS | Linux / macOS (container-ready) |
Integrations
The engine is not tied to a framework. It reaches the effect wherever the effect lives, and it can point at a hosted model or run one on your own machine.
Models you can point us at
- OpenAI API
- Anthropic API
- DeepSeek API
- Gemini API
Agents we run directly
- LangGraph
- LangChain
Where the code and the model live
- GitHub
- Ollama (local)
- HuggingFace (in-process)
The model under test runs in-process, and the generator that writes the probes can be switched to a local model as well, so nothing has to leave your machine. The honest exception: if the system you want verified is a frontier API model, checking it means calling it. You cannot verify a model without running it.
Cut by verifiability
The engine is system-agnostic: predictive, generative, assistive, agentic, orchestrated, the whole tree. What decides whether we can verify a system is one question: does its claim leave a checkable effect? There are three answers, and we give the honest one.
checkable effect
what it did leaves a falsifiable trace: a flag, a code change, a grounded answer
we falsify it: re-run, re-check, sign
judgment-heavy
“correct” needs expert taste: was the loan fair, the diagnosis sound
signed expert judgment
unfalsifiable
no checkable record exists: open-ended creation, intent, alignment
we refuse: indeterminate, never a fabricated score
Signed today vs roadmap
| Classification: fraud, credit, screening | signed |
| Code & system effects | signed |
| Regression / forecast | roadmap |
| Factual text (grounded) | signed |
| RAG grounding | signed |
| Copilot suggestions | roadmap |
| System judgment / decisions | roadmap |
| Creative text / image | refuse |
Signed receipts are published across 17 system types: code effects, fraud, credit, sanctions screening, fairness, anomaly detection, multi-agent orchestration, forecast, recommendation, computer vision, speech, scientific AI, RAG grounding, agents, truth, efficacy, and honesty. The rest reuse the same engine; we claim a receipt only once it exists.