For any team putting an AI assistant in front of customers, technicians, or staff
TruthLock checks every claim in an AI answer against the sources you've declared authoritative, blocks what fails, and keeps a signed record.
A technician asks how to clear a fault on a press. Both assistants answer identically. Only one was checked against the manufacturer's safety bulletins first.
Same question. Same answer.
Use it stand-alone in its own console, or build it in: REST API · Python SDK · TypeScript SDK · CLI · MCP server. See Developers → See where it fits →
The problem
A bulletin that supersedes a manual. A policy rewritten last quarter. A return rule that changed for the holidays. A case since overturned. Two documents disagree, and nothing in a retrieval stack says which one wins. The retriever picks the closer match; the model picks the more fluent one.
TruthLock grades against the order you declare. Every source sits in a tier with an effective date and a revision. When two disagree, the higher tier wins, an undated source cannot be Verified, and a claim that rests on a superseded document is marked Contradicted with the reason attached.
Then it decides what the answer may do. A claim that failed can be shown with a caveat, withheld, or sent to a reviewer, per your policy, before the user acts on it. The whole result is signed, so the fix you made today is also the record you can produce later.
What TruthLock does
Each one closes a gap that shows up in nearly every published AI failure. Together they turn an answer into evidence.
Your corpus contains documents that contradict each other: a bulletin and the manual it amends, this year's policy and last year's. You declare which tier wins, which sources carry effective dates and revisions, and what happens on conflict. The retriever no longer decides on similarity, and the model no longer decides on fluency.
Every response is decomposed into atomic claims before anything is graded. Opinion, interpretation, and metaphor are marked not applicable and left out of the score. Three correct steps and one prohibited one no longer average out to high confidence.
Verified means an exact match to the top-ranked applicable source, in scope and current. Everything else is labeled with the specific reason it fell short: no evidence, inexact match, source undated, revision unspecified, source outranked, source expired. A deterministic rules pass runs after the model and can only downgrade, never upgrade.
Showing a claim with a caveat, citing it, reasoning from it, forwarding it to another agent, publishing it, and acting on it are different operations that warrant different thresholds. A reliance policy decides, per grade and per operation, whether each is allowed, denied, or routed to a reviewer. Your application asks before it acts.
Each record is canonicalized, hashed claim by claim into a Merkle root, and signed. Evidence is snapshotted at grading time so it can be produced six months later even after the page changed. Records are superseded, never edited. Anyone with the code can check what standing a claim carried at the moment it was asserted and whether it has since been superseded or invalidated.
Grades
Exact match, in scope, current, from the top-ranked applicable source. Nothing else earns it.
Consistent with a ranked source, but not exact or not the top rank.
Could not be established. The reason is always attached.
no_evidenceinexact_matchsource_undatedrevision_unspecifiedsource_outrankedsource_expiredscope_mismatchA ranked source says otherwise.
reversed_meaningwrong_attributionwrong_datequantitativesuperseded_sourceOpinion, interpretation, testimony, metaphor. Recorded, not scored.
The system declined to grade, and says why. A legitimate state, not a failure to hide.
timeoutprovider_errorextraction_failedcircuit_openThe term
A confidence score says how sure the model was. It is silent on two questions you will be asked to answer: which source the claim came from, and whether the system was permitted to present it the way it did. Those two have a name.
What authority a claim rests on. Whether that authority was current. Whether anything outranked it. Whether it matched the question actually asked. And whether the system was permitted to present it as guidance rather than as a caveat.
Standing is assigned per claim, not per response. A four-step procedure is four claims, each possibly resting on a different source at a different level of authority. One score across the whole answer describes none of them.
You can improve accuracy next quarter. You cannot go back and establish standing for an answer you gave last March. It either existed at the time, or it never will.
Teams that captured the prompt and the response do not have an audit trail. They have a transcript. TruthLock produces the record instead: what each claim rested on, what it was allowed to do, and a proof that it has not changed since.
Where it fits
Arize, LangSmith, Langfuse, Datadog. They record the prompt, the response, the latency, and the tokens. Table stakes. TruthLock sits above them and consumes the same traces.
They ask whether a claim is true according to sources they find. They cannot grade against your service manual, your policy set, or your canon, and they stop at the verdict.
They check whether an answer is faithful to the retrieved context. They do not check whether that context was the document that applied, or whether a higher-ranked one said otherwise.
They prove the bytes are unaltered. A cryptographically perfect record of an ungoverned answer verifies perfectly. TruthLock signs the standing, not only the content.
Certify the model and you have said nothing about the answer. Standing is a property of each claim at the moment it was asserted.
They govern whether an agent may call a tool. They do not govern whether a weakly established claim may be shown as procedure, forwarded, or used as a premise. Reliance policy does.
Four questions for Monday
If the honest answers are "a transcript," "the model," "no," and "we can't," the exposure is already accumulating. An assistant handling a thousand questions a day produces 250,000 answers a year. At a harm-causing error rate of one in ten thousand, that is twenty-five incidents annually, each one a demand to produce the record.
The pipeline
Every stage emits a trace span and a job event. Same text, same hierarchy version, same prompt hash, same model pin gives the same claims and the same evidence keys. Verdicts differ only when evidence differs, and the difference is visible because the evidence is hashed.
Response text becomes atomic claims. No tools, temperature zero, schema output.
Claims grouped by the source they would need, using rules from the domain pack.
Evidence pulled tier by tier from your connectors. Everything snapshotted and hashed.
One call per group with the evidence, the hierarchy, and the rules in the prompt.
Deterministic post-pass applies rank, currency, and exactness. Downgrades only.
Reliance policy evaluated per claim and per operation. Review routing where required.
Canonical record, Merkle root, KMS signature, supersession link. Public verify code issued.
Deployment
Start on the hosted service at app.truthlock.io: nothing to run, a free plan to try it, and each company's data isolated in the database itself, not only in the application. Or take a dedicated AWS stack, in your account or ours: its own Postgres, Redis, S3 and KMS, nothing shared, and the record never leaves your boundary. Compare plans →
Connect the stores you already run: vector databases, graph databases, SQL, document stores, REST APIs, and declared website domains. Or let TruthLock host and ingest a managed store with effective dates and revisions on every document.
Bring your own Anthropic, OpenAI, or Google keys, or use ours. Every record pins the provider, model, and prompt version that produced it.