Your AI Answered Thousands of Questions Last Quarter. How Many Could You Defend in a Deposition?

Pick one of your AI's responses at random. A technician, a clinician, a claims adjuster, or a customer acted on it. Now put yourself under oath, with opposing counsel holding that single response.

Your confidence score only covers one of the three things you'll be asked to prove.

1. That the response was correct.
2. That the response claims came from the source that actually applies. Not a bulletin since replaced, a policy since rewritten, or a case since overturned.
3. That your system distinguished a confirmed claim from an unconfirmed claim, an unsourced claim, or a reasoned claim rather than delivering them in the same authoritative voice.

Your stack measures one thing: how confident the model was. It's silent on the other two.

Confidence is not the wrong metric. It is the wrong number of metrics.

The second and third have a name: standing.

Standing is what authority a claim rests on, whether that authority was current, whether anything outranked it, whether it actually matched the question asked, and whether the system was permitted to present it as guidance rather than as a caveat. You can improve accuracy. You cannot go back and establish standing for an answer you gave last March. It either existed at the time, or it never will.

Standing is assigned per claim, not per response.

Your liability is accumulating now, one unrecorded answer at a time

Plaintiffs have shifted from pleading that AI harms mainly through consumer protection and defamation toward pleading them as product liability: strict liability, design defect, failure to warn. Courts have allowed those theories past the pleading stage, and in February the San Francisco Superior Court coordinated a dozen suits against OpenAI into a single proceeding, In re ChatGPT Product Liability Cases (JCCP No. 5431). Leadership was appointed in August. Whether these theories survive on the merits is the next milestone, and the answer will set the shape of exposure for anyone shipping AI-assisted guidance.

A second shift matters more to anyone who buys rather than builds. In Mobley v. Workday, the court held that a vendor whose AI screens candidates can be treated as an agent of the employers using it. It then ordered Workday to identify every customer that had enabled its AI screening features, so those employers' applicant flows and rejection patterns could be pulled into the case. Workday remains the only named defendant. Thousands of its customers are now inside the litigation anyway, in a lawsuit they never chose to join. Pleadings reach past the model developer to the enterprise that brands and deploys the system.

Run the arithmetic on your own deployment. An assistant handling a thousand questions a day across 250 business days produces 250,000 answers a year. At a harm-causing error rate of one in ten thousand, a rate most teams would consider excellent, that is twenty-five incidents annually. Each one is a demand to produce the record.

Boards assuming the vendor absorbs the risk are about to be corrected at volume.

What one of those incidents looks like

Imagine an industrial equipment maker deploys an AI support assistant for the technicians who service its machines in the field. Most of those technicians work for independent distributors, not the manufacturer.

A technician is trying to clear a fault on a press. He asks the AI assistant. It tells him to bypass the safety interlock so the machine will cycle with the guard open. The instruction is real: it came from an old troubleshooting thread on a user forum that was swept into the assistant's knowledge base during setup. The manufacturer's own safety bulletin, issued eighteen months later, prohibits that procedure outright. Both documents are in the corpus. The forum post matched the question more closely, so the assistant used it.

The press cycles. The technician loses two fingers.

His employer's counsel writes to the manufacturer: your system instructed our employee to defeat a safety device you had already declared unsafe. Produce the AI record.

The manufacturer opens its logs and finds four things: the technician's question, the assistant's answer, a timestamp, and a confidence score of 0.91.

The record does not show which document the bypass step came from. It does not show that the safety bulletin existed, that it outranked the forum post, or that the system ever compared the two. It does not show whether the assistant was permitted to present a forum comment as procedure at all. And nothing about the log proves it hasn't been edited since.

Worse, the record confirms what the technician saw: a clean, confident instruction with nothing attached to it. No flag that the step rested on an unverified source. No note that a higher-ranked document said otherwise. No claim-by-claim report he could open to see which parts of the answer were established and which were not. The manufacturer's lawyers now have to defend an answer their own system produced, and they cannot say where it came from, what it rested on, or why it was allowed out the door.

The moment when a warning would have changed the outcome, the system said nothing. And now it can't show that it ever knew there was something to say.

The market is spending billions recording what happened, not whether it should have

The problem is not being ignored. Agent observability is now a crowded category: Arize, LangSmith, Langfuse, Comet, Weights & Biases, with Datadog, Dynatrace, and New Relic racing to catch up, and analysts forecasting nine-figure acquisitions within the year. OpenTelemetry instrumentation is table stakes. OWASP has published an Agent Observability Standard, and to its credit it goes beyond logging: it specifies hooks for hard controls on what an agent may do. A parallel lineage market (Collibra, Alation, Solidatus, Securiti, Unity Catalog) sells verifiable derivation history under an EU AI Act whose record-keeping duties (Article 12) carry fines of up to €15 million or 3% of global turnover.

And yet, LangChain's survey of more than 1,300 practitioners found 57% running agents in production and 89% with observability already in place, while quality remained the top barrier to shipping. One market analysis puts satisfaction with current observability and evaluation tooling at fewer than one team in three. That dissatisfaction is not a tooling gap. It is a category error.

ISACA named it in May. Review boards and published principles express intent, not proof, and a policy cannot prove what the system touched, what controls applied, or whether the answer should have been produced in the first place. Teams that captured the prompt and the response do not have an audit trail. They have a transcript.

Everything above answers what happened. None of it answers whether it should have.

Exactly what is missing

None of these are provided by observability, lineage, attestation, or model certification.

1. A declared authority hierarchy. Your corpus contains documents that contradict each other. A bulletin and the manual it amends. A current policy and last year's. Nothing in your stack declares which one wins. The retriever picks on similarity; the model picks on fluency. Nearly every published AI failure reduces to this: two sources disagreed, and nothing said which one wins. That ordering is yours to declare, and if you haven't, nobody has.

2. Per-claim assessment. An answer is a set of claims. A four-step procedure is four claims, each potentially resting on a different source at a different level of authority. One score across the whole response describes none of them. Three correct claims and one prohibited step average out to high confidence. The system then reports high confidence in an answer that will injure someone.

3. A threshold that refuses to round up. A top-ranked source confers nothing if the match is inexact. A bulletin with no effective date cannot be ordered against a correction. A procedure that doesn't name the revision cannot be matched to the assembly in front of the technician. Systems today resolve these gaps by proceeding anyway. What's needed is the opposite: verified only on exact match, and everything else labeled with the specific reason it fell short, so the human knows precisely what to check.

4. Enforcement at the point of reliance. This is the largest gap of the five. Every grading system in the market stops at the grade. Action-level controls, of the kind OWASP's standard describes, govern whether an agent may call a tool or send a message. They do not govern whether a claim the agent established only weakly may be shown as procedure, forwarded to another agent, merged into a knowledge article, or used as the premise for an action. Showing a claim with a caveat, reasoning from it, acting on it, and propagating it are different operations that warrant different thresholds, and no stack distinguishes them. A confidence score describes an answer. Something has to decide what the system is allowed to do with it.

5. Proof that covers the standing, not only the bytes. Signed receipts and attestation prove content is unaltered and lineage is intact. They say nothing about whether the label attached to that content was ever permissible. A cryptographically perfect record of an ungoverned answer verifies perfectly. And none of it carries a lifecycle: a claim later contradicted or superseded by stronger authority still validates exactly as it did the day it was signed.

Grade it, and nothing stops it. Sign it, and you have certified an ungoverned answer. Certify the model, and you have said nothing about the answer at all.

The last two gaps are a pair. Enforcement without proof is a promise only you can vouch for. You constrained the answer, and no outside party can confirm it. Proof without enforcement is worse: a tamper-evident record of a system that never governed anything. Neither is worth much alone.

Together they produce something new: a claim whose standing was enforced when it mattered and remains verifiable by someone who doesn't trust you.

Four questions to ask your team on Monday

You don't need to buy anything to find out where you stand.

1. If we're asked to produce a specific answer from six months ago, what exactly can we produce, and does it show which source it came from?
2. When two documents in our corpus conflict, what decides which one wins? If the answer is "the model," we have no hierarchy.
3. Can any part of our stack refuse to act on a claim it could not establish, or does every answer flow downstream identically?
4. If someone alleges our system said something it did not, how do we disprove it?

If the honest answers are "a transcript," "the model," "no," and "we can't," the exposure is already accumulating.

Every answer your system gives today is evidence you will either have or wish you had.

Then I built it

I worked this problem out before I built anything. The five capabilities above are described in two provisional patent applications that I filed together and that are now pending.

The first patent describes the method of assigning graduated epistemic states to claims, including refusal as a legitimate state, and enforcing operation-specific reliance constraints over them, so what a system may do with a claim depends on what the claim established.

The second patent describes attestation of those states, so an outside party can verify what standing a claim carried at the moment it was asserted, and whether it has since been superseded or invalidated.

The two were filed together because neither stands alone: the first governs and cannot prove, the second proves and cannot govern. The patents are written to the processes, not to any product, platform, or deployment.

TruthLock™ implements the processes: it declares the hierarchy, decomposes each response into claims, grades each against that hierarchy with citations and a plain-language explanation, withholds Verified from anything inexact, enforces what each grade permits downstream, and anchors a proof binding the grade to the content. Each claim is graded and an explanation provided, whether it's verbatim from a file or reasoned from across sources. Direct sources are always cited unless the claim could not be sourced.

Next, I deployed it in the most demanding domain I could find: a study assistant for a tradition where the authority hierarchy is deep and not always explicit or ranked, and where a fabricated reference isn't an error rate, it's a lie about something sacred. The processes hold, and they hold in a service manual or a case file. Only the knowledge domain and hierarchy changes.