Online Dispute Resolution: Why AI Should Not Settle Disputes Based on Truth Alone

Can an AI be unsure about the truth and still be confident about a settlement?

At first, that sounds contradictory.

If the system does not know exactly what happened, how can it recommend what should happen next?

But this is precisely how many real-world decisions work. A doctor may not know the exact biological pathway that caused a symptom, but still know the safest clinical intervention. A compliance officer may not prove money laundering conclusively, but still know that a transaction should be blocked, investigated or escalated. A business leader may not know every internal failure that caused a project delay, but still know how to renegotiate delivery, protect the relationship and reduce further loss.

This distinction is critical for AI-powered dispute resolution.

Most people assume that a dispute-resolution AI must first determine the truth, then assign responsibility, then propose an outcome. That sounds logical, but it is not how many commercial disputes actually behave in the real world.

In low-value, high-volume disputes, the cost of proving the truth may exceed the value of the dispute itself. The missing evidence may no longer exist. The warehouse CCTV may have been overwritten. The courier may not have item-level weight logs. The signed delivery note may prove that a pallet arrived but not that the contents were individually verified. The claimant may have a photo showing eight units, but the photo may not prove that only eight units crossed the delivery threshold.

So the real question is not always:

Can we prove exactly what happened?

The better product question is:

Can we propose a fair, explainable and commercially acceptable resolution under uncertainty?

That is where the concept of Resolution Confidence becomes important.

Truth Confidence Is Not Resolution Confidence

A serious AI dispute platform should not operate with a single confidence score.

One score is too crude. It collapses different kinds of uncertainty into one number and creates the illusion of precision.

Instead, the system must separate at least three layers.

• Truth Confidence asks: what most likely happened?
• Responsibility Confidence asks: who should bear the loss, risk or burden?
• Resolution Confidence asks: can the AI safely propose a fair settlement without human review?

These are related, but they are not the same.

A system may have only moderate confidence about factual truth but high confidence that a compromise settlement is fair. Conversely, it may know the facts very well but still be uncertain about the correct legal or commercial allocation of loss.

This distinction matters deeply for CEOs and founders building AI-native platforms. If you confuse these three layers, your product will either over-automate risky decisions or over-escalate commercially resolvable cases to expensive human review.

Neither scales.

The Warehouse Example

Consider a simple business dispute.

A claimant ordered and paid for ten units of equipment. The respondent says all ten were dispatched. The claimant says only eight arrived. The contract only says the respondent must deliver the quantity paid for. There is no special proof-of-delivery clause.

The respondent has a courier dispatch manifest showing ten units handed over to the courier. The claimant has an internal goods-received note and photos showing eight units after unboxing. The signed delivery confirmation says the claimant received one pallet, but contents were not individually verified.

A weak AI system will ask: Who is more credible?

A better system will ask: What does each evidence artifact actually prove?

The dispatch manifest supports the proposition that ten units entered the dispatch process. It does not prove that ten units were individually delivered to the claimant’s premises.

The delivery confirmation supports the proposition that one pallet was delivered. It does not prove that ten units were inside the pallet at delivery.

The photos support the proposition that eight units were visible when the photos were taken. They do not prove that only eight units arrived unless metadata, timing or first-opening evidence supports that interpretation.

The claimant’s goods-received note supports the proposition that the claimant internally recorded eight units. It does not automatically prove that the respondent breached the delivery obligation.

So the system should not jump from documents to judgment. It should pass through a structured evidentiary model.

In simplified form:

$[ \text{Evidence} \rightarrow \text{Propositions} \rightarrow \text{Custody Hypotheses} \rightarrow \text{Confidence Scores} \rightarrow \text{Settlement Policy} ]$

That middle layer is where most AI products fail.

Evidence Does Not Speak for Itself

In regulated domains, documents are not merely “data.” They are evidence, and evidence must always be interpreted against a proposition.

The same document may be strong evidence for one proposition and weak evidence for another.

A signed delivery note may be strong evidence that a pallet arrived. It may be weak evidence that the correct item count arrived. A dispatch manifest may be strong evidence that a warehouse process recorded ten units. It may be weak evidence that the claimant received ten units. A photo may be strong evidence that eight items were visible. It may be weak evidence that the shipment originally contained only eight.

This is why treating dispute resolution as a document summarization problem is a category error.

An LLM can summarize the documents beautifully and still misunderstand what they prove.

For any evidence item $e_i$, the system must evaluate its relevance to a proposition $\phi_m$, not to the dispute in general. A simplified support score may look like this:

$[ S_m = \sum_i A_i \gamma_{im} q_{im} \lambda_{im} ]$

Here, $A_i$ indicates whether the evidence is present, $(\gamma_{im})$ measures relevance to the proposition, $(q_{im})$ measures evidence quality, and $(\lambda_{im})$ measures the evidentiary direction and strength.

This is the principle: A document should not receive one global credibility score. Its strength depends on what proposition it is being used to prove.

The Missing Evidence Problem

The most important evidence in a dispute is often the evidence that is absent.

In the warehouse case, the crucial missing element is item-level delivery verification at the claimant’s premises. The respondent proves dispatch better than delivery. The claimant proves receipt-shortage observation better than delivery-stage causation. Neither proves item-level delivery or item-level shortage at the exact custody handoff.

This creates a critical evidence gap.

Let:

$[ S_D = \text{support for dispatch of ten units} ]$

$[ S_R = \text{support for observed receipt shortage} ]$

$[ \operatorname{Cov}_L = \text{coverage of item-level delivery evidence} ]$

Then, in this case, we may have:

$[ S_D \uparrow,\quad S_R \text{ moderate},\quad \operatorname{Cov}_L \downarrow ]$

That low item-level delivery coverage creates what I call a delivery evidence gap:

$[ G_L = \rho_L(1-\operatorname{Cov}_L) ]$

where $(\rho_L)$ represents the importance of item-level delivery proof in that dispute type.

This gap should not be treated as automatic proof against either party. It is not a magical shortcut to liability. It is an uncertainty amplifier.

And that uncertainty affects the system differently depending on which confidence score is being computed.

It lowers Truth Confidence because the exact failing link in the chain-of-custody is unclear.

It lowers Responsibility Confidence because the system cannot confidently assign the loss to one party.

But it may increase the defensibility of a risk-sharing settlement, because a one-sided outcome becomes harder to justify when the critical evidence gap is large.

This is the design insight.

Missing evidence does not always mean “do nothing.” Sometimes it means “do not adjudicate, but propose a proportionate settlement.”

The Settlement Layer

A settlement proposal should be evaluated differently from a factual finding.

A factual finding asks whether the system knows what happened. A settlement proposal asks whether a proposed outcome is fair, explainable, commercially rational and likely to resolve the dispute without escalation.

For a settlement proposal (s), a practical resolution-confidence model may be expressed abstractly as:

$C_S(s)=\operatorname{Cal}_S \left[ D_s^{\alpha} A_s^{\beta} F_s^{\delta} P_s^{\eta} Q_s^{\theta} V_s^{\kappa} \right]$

where the terms represent evidentiary defensibility, acceptance probability, fairness, proportionality, explanation quality and external survivability.

The exact weights should not be guessed in a conference room. They should be calibrated through product data, expert validation, settlement outcomes and downstream challenge behavior.

The function $(\operatorname{Cal}_S)$ is the calibration layer. It converts a raw model score into an operational probability. If $(C_S(s)=0.72)$, that should mean proposals of comparable type, risk and evidence profile have historically resolved successfully around seventy-two percent of the time.

Without calibration, the number is just random pick – Nothing more, nothing less.

This is where many AI products become dangerous. They display confidence scores that look quantitative but are not tied to observed outcomes. A founder should be allergic to such systems. A CTO should reject them before they enter production.

Why 72 Percent Is Not a Magic Number

When people ask at what confidence level an AI should propose settlement without human review, they usually expect a fixed number.

That is the wrong framing.

The threshold should be dynamic.

For a low-value, non-binding Stage 1 settlement proposal, the threshold may initially sit around 0.72. But this number is not a universal legal constant. It is a product-risk threshold.

A simplified decision threshold can be written as:
$\tau(D)=\inf_{\tau} \left\{ \tau: P(Y_{\text{fail}}=1 \mid C_S \geq \tau,D) \leq \epsilon(D) \right\}$

This says: choose the lowest threshold at which the failure probability stays within the acceptable risk tolerance for that dispute class.

The case context D matters. A £300 dispute over missing inventory should not have the same automation threshold as a £300,000 dispute involving regulatory exposure, reputational consequences or complex contractual dependencies.

The tolerated failure rate $\epsilon(D)$ should shrink as claim value, legal risk, jurisdictional uncertainty or reputational exposure increase.

So the real answer is not:

I would use 72 percent.

The real answer is:

For low-value, non-binding Stage 1 settlement proposals, I would allow autonomous settlement recommendation when Resolution Confidence clears the dynamically calibrated threshold, which may initially be around 72 percent for the lowest-risk dispute classes.

That is a very different product philosophy.

It says the system is not hardcoded. It is governed.

What Not To Do

The first mistake: is to use Truth Confidence as the settlement trigger.

• That sounds reasonable, but it fails in practice. Many disputes cannot cheaply reach high factual certainty. If the system waits for near-perfect truth, it will escalate too many cases and destroy the economic value of automation. If it proposes outcomes using low truth confidence, it will look arbitrary.

The second mistake: is to let the LLM invent the confidence score.

• Language models are good at summarization, classification, extraction and explanation. They are not, by themselves, calibrated decision engines. They can support the reasoning workflow, but the confidence layer must be structured, measured and validated.

The third mistake: is to treat missing evidence as simple evidence against one party.

• Absence can mean many things. The evidence may not have been generated. It may have been generated but not retained. It may be under the control of a non-party. It may be commercially disproportionate to obtain. It may have been withheld. Each of these has different meaning.

The fourth mistake: is manual threshold tuning.

• Manual tuning may work in a pilot. It does not scale in production. If every dispute category requires bespoke human adjustment, the product is not an AI platform. It is a consulting workflow with a chatbot interface.

The fifth mistake: is to optimize only for acceptance.

• A bad settlement can be accepted if one party is fatigued, confused or commercially weaker. That is not success. A serious platform must also track execution, reopening, fairness perception, complaint rate and external survivability.

The Business Implication

For CEOs and founders, Resolution Confidence is not just a technical idea. It is a business architecture.

It determines when the product can automate, when it should ask for more evidence, when it should escalate to human review and when it should refuse to pretend certainty.

The operating model becomes:

$\text{If } C_S(s^\star) \geq \tau(D), \text{ propose settlement}$

$\text{If } C_S(s^\star) < \tau(D), \text{ acquire the next most informative evidence}$

$\text{If evidence acquisition has poor expected value, escalate}$

This is how a product remains low-cost without becoming low-trust.

The most valuable evidence request is not “send more documents.” It is targeted. Ask for courier pickup weight. Ask for delivery weight. Ask for seal records. Ask for serial-number scans. Ask for timestamped first-opening footage. Ask for ERP goods-received audit logs.

The system should estimate the expected value of each request before asking for it.

Again, the principle matters more than the formula. Evidence acquisition should be economically rational. If the evidence costs more to obtain than the dispute is worth, the platform should recognize that and shift toward proportionate resolution.

Why This Matters Beyond Legaltech

The same idea applies across regulated AI.

In healthcare, a clinical decision-support system may not know the exact diagnosis but can still recommend the safest next diagnostic step. In anti-money laundering, a system may not prove criminal intent but can still assign a transaction to enhanced due diligence. In insurance, the system may not know precisely when damage occurred but can still propose a settlement based on evidence strength and policy risk. In smart contracts, the code may execute deterministically, but real-world disputes still require evidence-aware exception handling.

The common pattern is this:

Truth is expensive. Resolution is economic. Trust requires knowing the difference.

That is where AI needs human expertise.

Not every uncertainty should be automated away. Some uncertainty must be represented, priced and resolved.

The Real Moat

Anyone can connect an LLM to a document store and call it legal AI.

That is not the moat.

The moat is knowing that a dispatch manifest proves dispatch, not delivery. A delivery signature proves pallet transfer, not item-level verification. A medical note proves a recorded observation, not a ruled-out diagnosis. An invoice proves declared value, not economic legitimacy. A smart-contract event proves execution, not necessarily fairness.

The moat is in the evidence ontology, the confidence architecture, the calibration loop and the domain judgment embedded into the system.

AI is a tool. In the hands of people who do not understand the domain, it creates fluent uncertainty. In the hands of experts, it becomes leverage.

For startups and AI businesses, the lesson is simple: do not build products that merely answer questions. Build systems that know when they have enough confidence to act, when they need better evidence and when the economically correct answer is not more truth, but better resolution.

That is the difference between an AI demo and an AI business.

Contact Me if you are building solutions in the AI space and need domain expertise (Healthcare, FinTech, Legal Tech, Retail ...) to ensure correctness and product scalability.