SovrenAI
Every claim in an AI answer shows its confidence and its source
SovrenAI's founder writes much of GCE, his grounded comprehension engine, himself, and in it every claim carries a truth tier, a confidence score and its source. Our engineers work inside his repository: we audit, harden, test and release each version as a production chat and Document IDE.
B2B SoftwareGCE, a grounded AI chat and document IDEBuilt from zero
The challenge
AI answers sound equally confident whether they are certain, guessing or invented. SovrenAI's engine fixes that, but its code changed with every push and still needed hardening, testing and a release.
What we did
We audited the engine before changing it, kept its single classifier path intact, added accounts and chat history, QA tested each build and deployed it on Azure with Docker.
The outcome
The grounded chat and Document IDE went to production, the second version of the engine followed, and the founder now hands each finished version to us to deploy.
- In production
- Grounded chat and Document IDE on Azure
- Every answer reports
- Graph units, new units, verification, confidence
- Audited first
- About 95 core modules and 482 tests
- Releases
- Each finished version deployed by us
The starting point
SovrenAI builds GCE, the Grounded Comprehension Engine: a grounded chat and a Document IDE on a 392 token truth classifier and ontology. Every answer breaks into knowledge units, shown as clickable pills with tier, confidence and source, and audited documents carry claim receipts. The founder writes much of the engine himself with an AI coding assistant.
What had to change
AI answers look equally confident whether they are certain, guessing or invented, and the founder wanted every claim to carry its tier, confidence, source and chain of custody. His engine was changing fast, and it needed review, hardening, testing and a stable production release.
What could not break
- All language flows through the single 392 token classifier, with no bypass
- Twelve invariants, the truth floor, load and verify before any other logic runs
- Every unit keeps its identity and provenance as it is decomposed, minted, bonded and rendered
- The founder keeps writing engine code, so review and release run alongside him
- A fresh install carries no client documents, data or keys
The calls we made
We treated the founder's engine as the core and worked inside his repository and release process, taking on everything a production release needs around it.
- 01
Audit before changing anything
We audited the whole codebase first: a ten agent pipeline, about 95 core modules and 482 tests, with security and reliability fixes flagged, such as a permissive CORS default and an unwrapped done event.
Ruled outRewriting an engine the founder owns and keeps extending.
- 02
Verify claims against full sources
Checking claims against 150 character search snippets could not really verify them, so the founder switched search to full article text; we reviewed that change and carried it into the release.
Ruled outVerifying claims against search snippets.
- 03
One score users read first
We made the Classification Integrity Score the primary score on screen and replaced the Reliability Score label with Epistemic Level across frontend and backend.
Ruled outLeaving the old reliability score as the number users see first.
- 04
Filter by provenance, not by stripping tiers
We wrote a spec for provenance first filtering in the compiler pipeline, so units are filtered by where they came from rather than by stripping their tier.
Ruled outTier stripping in the compiler pipeline, which the spec replaces.
- 05
Release readiness before new vision
The founder asked for a readiness audit of every program and page before public release, with vision changes held for a later phase. QA tests the trust signals too: a claim receipt showing high confidence on a false statement was logged as a release bug.
Ruled outFolding changes to the founder's wider vision into the release work.
How the system fits together
What we built
Document audit and claim receipts
Document audit classifies each sentence and scores its provenance, with trust lookup by barcode, printable barcodes and a full audit history; Open in IDE takes the user from an audited document straight into the editor.
Grounded chat with tier pills
Each knowledge unit in an answer appears as a clickable pill with its tier, confidence and source, and every response ends with a verification line: units from the graph, new units, verification status and confidence.
Accounts and chat history
Registration and login backed by SQLite, JWT sessions with bcrypt password hashing, and chat history scoped to each user, with per session delete and clear all.
Production on Azure, with health checks
Docker and Docker Compose on Azure virtual machines with dev and production environments, health checks on each integration, and a frontend error reporter that logs crashes for the team.
QA on every build
Test reports on each build, a QA checklist for the engine, bug lists that test the trust signals themselves, and mobile QA that led to layout and authentication fixes.
How it works
Comprehend
The question is decomposed into units, and the classifier gives every unit a truth tier.
Reason on the graph
Known units come from the knowledge graph, and confidence decides between a graph answer and the model path.
Search and generate
When needed, web search brings in full articles, and a model writes the answer with the graph as context.
Verify and repair
Claims are verified, repaired where they fail and synthesized with citations.
Answer with receipts
The user sees every unit as a pill with tier, confidence and source, plus a verification line for the whole answer.
A closer look
{
"verification": {
"units_from_graph": 14,
"new_units": 5,
"status": "verified",
"confidence": 0.92
},
"units": [
{
"text": "Copper conducts electricity",
"tier": "T1",
"confidence": 0.97,
"resistance": "high",
"bonds": 4,
"ontology_class": "property",
"source": "knowledge graph"
},
{ "text": "The plant opened a second line",
"tier": "T6", "confidence": 0.71,
"source": "news article, full text" }
]
}What changed
The grounded chat and Document IDE went to production on Azure, and the second version of the engine followed. The founder made deployment of his finished versions our responsibility, and his latest code is live on the server.
Under the hood
- Datics role
- Product built by Datics
- Models
- Anthropic models by default, with the founder's tuning routing some pipeline work to DeepSeek, and optional Azure document OCR.
- Provenance
- Every unit carries a tier from the 392 token classifier, a confidence score and a source reference, shown in pills, verification lines and claim receipts.
- Security
- SQLite backed accounts with JWT sessions and bcrypt hashing and chat history scoped per user; the first audit flagged items such as a permissive CORS default.
- Deployment
- Docker and Docker Compose on Azure virtual machines with dev and production environments; a fresh install of the second version carries no client documents, data or keys.
AI and models
Cloud and infrastructure
Apps and APIs
Also in the stack
How it shipped
Audit and knowledge transfer
The founder shared his repository; we audited the full engine, reviewed his pill system and search changes, and ran knowledge transfer sessions on the code.
First deployment and QA
The first deployment came with a QA test report, followed by accounts, chat history and the score change, then the engine on a virtual machine behind the founder's domain.
Release bugs and production
We fixed database crashes and page errors in the founder's new modules, containerized the engine with Docker Compose on Azure, and took it to production with a feature audit and system analysis.
Second version, released by us
The founder handed over the second version with deployment as our responsibility, and we now deploy each version he finishes, with mobile QA and fixes.
Inside the founder's repository
The founder pushes branches to his own repository, and our engineers review, fix and deploy them next to him, with QA reporting issues on every build.
From reviewing commits to owning releases
When the founder finished the second version of his engine, he made its deployment our responsibility, and we now release each version he hands over.
Sprints, daily scrum, weekly reports
Work runs in sprints with a daily scrum and a weekly progress report, and vision changes wait for their own phase instead of riding along with a release.
What this unlocked
Next is closing the open mobile bugs, a UI review to simplify the mobile experience, and a review of each program against the founder's vision, the phase held back from the release audit.
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.