How it works
TruthLock is configured per organization: one knowledge domain, one hierarchy, its connectors, its agents, and its reliance policy. A company can run as many organizations as it has domains. The pipeline is the same for all of them.
1 · Authority hierarchy
A hierarchy is an ordered set of tiers. A field-service organization might declare: safety bulletins, then the current service manual, then superseded manual revisions, then distributor knowledge bases, then the open web. Each source in a tier carries an effective date, an optional expiry, a revision, and a pointer to whatever superseded it.
Rules say what happens when things go wrong: on conflict, prefer the higher tier; on an undated source, downgrade to unconfirmed; on an unspecified revision, require review. Hierarchies are versioned, and every record pins the version it was graded under. Change the hierarchy and old records still say what they said.
The strict default is TruthLock's own threshold. If your domain tolerates more, loosen it. The record shows which threshold applied.
2 · Connectors
Every source in the hierarchy is backed by a connector. External connectors query stores you already run and never copy the corpus: vector databases, graph databases, SQL, S3 document stores, REST APIs, and live search restricted to the website domains you declare. Managed connectors are stores TruthLock provisions and hosts for you, with ingestion that stamps each document with its effective date, revision, and successor.
Each connector has a health check and a circuit breaker. When a store is down, claims that depended on it come back refused with the reason, not silently unconfirmed.
3 · Claims
Before anything is graded, the response is decomposed into atomic claims by an extractor that runs with no tools, at temperature zero, into a fixed schema. Pronouns are resolved and compound sentences split. Each claim keeps the snippet it came from so a reader can see where in the answer it lived.
Claims are typed against a taxonomy you control. A manufacturer might type procedure, specification, and safety. A legal team might type holding, dicta, and statute. Types you mark non-verifiable are recorded as not applicable and never scored, so an opinion cannot drag a grade up or down.
4 · Grading
Evidence is gathered tier by tier, and every piece is snapshotted to object storage with its hash at grading time. A grader agent sees the claim, the evidence, the hierarchy block, and the rules, and returns a grade, a reason code from the fixed set, a plain-language explanation, and the evidence it relied on.
Then a deterministic resolver runs in code. It applies rank, currency, and exactness, checks that the rationale is consistent with the grade, and treats an empty or junk source as no evidence. It can downgrade a grade the model gave. It can never upgrade one. The model cannot round up, and neither can a prompt.
Grader prompts, presets, and fallback chains are versioned and hashed into every record. Display labels and colors are a per-organization mapping over the fixed grades, so the grades stay comparable across customers.
5 · Reliance
A reliance policy is a grid: grade on one axis, operation on the other, and in each cell allow, deny, or require review. Your application calls the reliance check before it shows, cites, reasons from, propagates, publishes, or acts on a claim. Review routes the claim to a queue where a reviewer adjudicates with a rationale. The adjudication produces a new attestation that supersedes the old one. It never edits it.
| Operation | Verified | Supported | Unconfirmed | Contradicted |
|---|---|---|---|---|
| Display | Allow | Allow | Review | Deny |
| Display with caveat | Allow | Allow | Allow | Allow |
| Cite | Allow | Allow | Deny | Deny |
| Reason from | Allow | Review | Deny | Deny |
| Propagate to another agent | Allow | Review | Deny | Deny |
| Publish | Allow | Review | Deny | Deny |
| Act | Allow | Deny | Deny | Deny |
The strict default policy. Every cell is yours to change per organization.
6 · Attestation
The full standing record, including the hierarchy version, agent versions, model identifiers, prompt hashes, and evidence hashes, is serialized canonically. Each claim becomes a Merkle leaf; the root is signed with a key in AWS KMS. The attestation carries the signature, the root, and links to whatever it supersedes and whatever later superseded it.
When a source is later superseded, or a reviewer adjudicates, or an operator invalidates a record with a reason, a new attestation is issued and chained to the old one. The old one still validates, and it now says it was superseded and why. A public verify code shows anyone the standing at time T and the chain since. An export bundle produces record, evidence, proof, and signature as one artifact.
Signed receipts are always on. An optional second anchor to a public chain can be enabled per stack for customers who want an outside timestamp nobody controls.
Operating it
Hierarchies, connectors, claim types, presets, agents, reliance policies, review queue, monitor, audit log. Roles and capabilities drive what each person sees and may change.
Paste a response and a question. Watch the pipeline run stage by stage and read the standing record it produced.
Verify asynchronously, check reliance before you act, fetch attestations and exports. Signed webhooks and idempotency keys.
Anyone with a code sees the claims, grades, reasons, signature, and supersession chain. No account needed.