SovrenAI
Claim verification on the founder's own ontology, where the language model only suggests
The founder of SovrenAI had a prototype of TITO, the Truth Token Ontology, that classified claims against his own ontology of truth tokens, but nothing could be measured, scaled or audited. We rebuilt everything around his logic: rules anchor each result, the model only suggests, and every answer carries its metrics.
B2B SoftwareTITO, an AI claim verification engineBuilt from zero
The challenge
The founder's prototype had no database, cache, API or audit history, its verification ran synchronously, its metrics fell back to stubs, and no labeled data existed to measure accuracy.
What we did
A FastAPI and React engine that keeps his rule tiers as the anchor, adds embeddings and suggestion-only model calls through tunable weights, and measures every answer.
The outcome
After a move to Azure OpenAI with fallback, responses were stable and classification consistent, tiers T0 to T9 worked end to end, and the founder made our engine his source of truth.
- Truth tiers
- T0 to T9 working end to end
- Ontology
- The founder's own truth tokens, each with examples
- Model role
- Suggestions with confidence, never the final word
- Runs on
- Azure OpenAI with primary and fallback routing
The starting point
SovrenAI builds TITO, its truth verification technology: claims are broken into atomic units, classified against the founder's tiered ontology of truth tokens, scored and recorded for use in AI models, research and fact checking. The founder is deeply involved and keeps adding ideas and code of his own.
What had to change
The prototype proved the idea but had no database, cache, API or audit history, its verification ran synchronously and its metrics fell back to stubs. Without a labeled dataset, no one could say how accurate it was.
What could not break
- The founder's ontology and scoring logic stay intact
- The language model suggests; it never makes the final classification
- Every answer carries its own metrics
- Exports redact personal data by default
The calls we made
We treated the founder's ontology and scoring logic as the fixed core and made everything around it measurable, traceable and testable.
- 01
Gap analysis before code
We audited the founder's developer packet before writing code and found no labeled validation data, no working semantic layer, no database, cache or API, scrapers with hardcoded selectors and no check for missing tokens, so the plan fixed what was actually missing.
Ruled outBuilding on top of the prototype as it was.
- 02
Rules anchor, the model suggests
With no labeled ground truth and a real risk of hallucination, regex stays the fast, explainable anchor, SBERT adds meaning, and the model only suggests tokens with a confidence, merged through calibrated weights.
Ruled outLetting the language model decide the classification.
- 03
Net and gross effort on every answer
The founder wanted proof that truth validated AI uses less compute than a plain model, so each answer reports tokens in the final answer apart from all tokens spent, including discarded paths, next to energy and latency.
Ruled outOne token total per answer, which hides the effort spent on discarded paths.
- 04
Keep the tested pipeline
When the founder shared a single file engine for the next version, we kept our tested pipeline under it, so core scoring and agent logic stayed unchanged while new capability arrived.
Ruled outReplacing tested logic with an untested rewrite.
- 05
Merge into the engine, not the reverse
The founder's separate chat codebase arrived with hard-coded models and partial monitoring, so we agreed to audit it and move its useful logic into the engine, which stays the source of truth.
Ruled outMoving the engine into the larger, less structured codebase.
How the system fits together
What we built
Verification chat
A React front end on a FastAPI backend with Google sign in, streamed answers, light and dark modes, and token discovery and voting tested with multiple users.
A report behind every verdict
A report view with the verdict, processing time, difficulty, resistance pattern and uncertainty type, behavior metrics such as epistemic humility and doubt immunity, and token, effort and energy figures.
Hybrid classifier on the founder's ontology
The founder's truth tokens, each with positive and negative example sentences, classified by regex anchors, SBERT embeddings and model suggestions merged through calibrated weights.
Telemetry and audit controls
Token usage, an energy estimate and latency on every answer and an audit pipeline, with reasoning traces, a baseline model comparison and exports that redact personal data specified for the second version.
How it works
Submit a claim
A user asks or submits a claim in the verification chat.
Break it down
The engine splits the text into atomic claims.
Classify
Regex anchors the tier, and embeddings and model suggestions add weighted confidence.
Measure
Tokens, effort, energy and latency are recorded for that answer.
Answer
The reply streams back with its truth tier and its metrics.
A closer look
What changed
After moving to Azure OpenAI with primary and fallback routing, responses were stable, token usage was correct and classification was consistent, with tiers T0 to T9 working end to end. The founder agreed that the engine we built is the source of truth for his platform.
Under the hood
- Datics role
- Product built by Datics
- Models
- Azure OpenAI with primary and fallback routing, SBERT sentence embeddings and Qdrant vector search, with the model limited to suggestions.
- Data and audit
- PostgreSQL for results and the audit pipeline and Redis for caching, with a ledger designed to sign each claim's id, text, classification and timestamp with SHA-256.
- Deployment
- Azure hosting with Docker, CI/CD from the first sprint and Swagger documented APIs.
- Privacy
- Exports were specified to redact personal data by default, with input scrubbing, masking and retention rules in the risk plan.
AI and models
Data and retrieval
Apps and APIs
Also in the stack
How it shipped
Gap analysis
We reviewed the founder's developer packet and wrote a detailed gap analysis with a target architecture, a risk table and four milestones.
Core engine
FastAPI, React, PostgreSQL, Redis, Qdrant and CI/CD in the first sprint, then the hybrid classifier on the founder's final token file and a backend with live Swagger docs.
Telemetry and audit
The measurement and audit controls the founder asked for, shown in a demo of Google sign in, chat and per answer metrics, then token discovery and voting tested with multiple users.
Stable on Azure
After a local merge broke the chat stream, we rolled back by commit hash and moved from local models with cold starts to Azure OpenAI with primary and fallback routing.
One source of truth
The founder agreed that our engine is the source of truth, with his separate chat codebase to be audited and merged into it.
Founder code, assessed first
Each optimizer, classifier update and feature package the founder sent went to our analyst and CTO for review, and only what fit the tested pipeline was merged.
Nothing on assumptions
Unclear requirements were written down and confirmed with the founder before work started, and meeting minutes recorded the calls, from the tier structure to the source of truth.
Working state in GitHub
Work lived in repositories with CI/CD from the first sprint, and after one bad local merge we agreed to push only working state and roll back by commit hash.
What this unlocked
The founder now builds new apps as self contained modules, and we act as the line that audits, refines, deploys and launches them; a public analysis endpoint on the same pipeline was also proposed.
Related work
Have a product with the same kind of constraints?
Tell us what already exists and what you want it to do. We will tell you what it takes.