Does every uncertain database use probabilities?

No. Some represent alternatives or incomplete information without assigning probabilities to them.

Can an AI confidence score be stored as a probability?

It can be stored, but interpreting it as a calibrated probability requires justification and evaluation for the relevant task.

Does retaining uncertainty mean no decisions can be made?

No. A workflow can use review rules, robust conclusions or explicit decision thresholds while retaining the evidence and assumptions behind the choice.

AI Glossary / Data engineering and architecture / Intermediate

Uncertain database

Definition

An uncertain database represents information whose value, existence or interpretation is not fully settled. Instead of forcing every record into one supposedly definite version of reality, it can retain alternatives and support questions about them. A probabilistic database is a related, more specific approach that assigns probabilities within a defined uncertainty model.

What it means

A supplier name might match either of two registered businesses. A sensor reading might lie within a range. A shipment record might be present only if an unresolved document is genuine. These are different kinds of uncertainty, and they require different representations.

The purpose is to make the uncertainty visible to downstream work. An AI application that chooses one interpretation during import can make later answers look more certain than the evidence permits. Keeping alternatives gives analysts an opportunity to ask which conclusions survive those alternatives and which depend on disputed inputs.

How it works

One conceptual approach describes possible worlds: complete database states compatible with the available information. A query can be considered across these states. A possible answer appears in at least one permitted world; a certain answer appears in every permitted world under the specified semantics.

Probabilistic models attach probabilities to worlds or use more compact structures from which those probabilities follow. Query evaluation must preserve relevant dependencies. Two records generated from the same underlying claim cannot automatically be treated as independent evidence.

Practical systems need compact representations because explicitly listing every combination may be too expensive. The representation, supported queries and approximation choices determine what a particular implementation can answer.

Three practical examples

1. Document intake: An invoice parser retains two plausible customer matches. An employee reviews the ambiguity before the invoice enters a customer-specific collection workflow.

2. Equipment monitoring: A team stores a measurement interval alongside its acquisition conditions. Its report distinguishes machines certainly outside a limit from machines that might be outside it.

3. Knowledge retrieval: An assistant receives alternative interpretations of an old catalog record. It explains the unresolved edition rather than presenting both versions as simultaneously established facts.

Think of it this way

Think of a planning folder containing several admissible versions of an event schedule. Some appointments appear in every version; others depend on which venue becomes available. You can distinguish commitments that survive all versions from tentative possibilities.

The analogy stops at the folder. Real database models may encode enormous combinations compactly, and probabilities need an explicit basis. Simply placing two possibilities in the same folder does not mean they are equally likely.

Worked example

Consider an original toy model of two independently uncertain shipment records. Record A exists with probability 0.7 and record B with probability 0.4. The question is whether at least one shipment exists.

Under the stated independence assumption, neither exists with probability 0.3 × 0.6 = 0.18. Therefore, at least one exists with probability 1 − 0.18 = 0.82. The four world probabilities are 0.28 for both, 0.42 for A only, 0.12 for B only and 0.18 for neither; they sum to one.

Now discover that A and B are duplicate extracts of related paperwork. Independence is no longer justified. The marginal probabilities alone do not establish the same 0.82 result. A dependency model or additional evidence is necessary before publishing a revised probability.

Illustrative case study

Illustrative fictional case: EvidenceOrchard builds a search service for archived purchasing records. Several scans have ambiguous supplier identifiers. The first import chooses the highest-scoring match and discards the alternatives.

A reviewer notices that the assistant confidently combines purchases from two distinct suppliers. The team redesigns intake to retain candidate identities, the evidence supporting each candidate and the review status. Queries for confirmed supplier totals exclude unresolved assignments, while a separate exploratory view exposes possible contributions.

The pilot checks known ambiguous documents and records which answers change after human resolution. It does not claim that candidate scores are calibrated probabilities. The practical improvement is traceable uncertainty and an explicit review path, rather than a fictional measured accuracy gain.

Common misconceptions and mistakes

An uncertain database is not simply an unreliable database. Uncertainty can be a deliberately represented property of the information.

A missing SQL value does not by itself specify possible values, probabilities or dependencies. Adding a confidence column also does not automatically supply coherent probabilistic query semantics.

Do not assume that two plausible alternatives each have probability one half. Do not multiply confidence scores without checking their meaning and dependence. Finally, a certain answer is certain relative to the permitted worlds and assumptions; a mistaken model can still omit the real situation.

Business use

Business teams can use uncertainty-aware data handling when unresolved information would otherwise contaminate decisions. Begin with one concrete decision: whether to route a document, include a record in a total or request another measurement.

Specify the acceptable response when evidence remains unresolved. Record the origin of alternatives, who may resolve them and how corrections reach derived reports. Evaluate whether users understand the difference between confirmed, possible and probability-ranked results. Extra mathematical detail is useful only if it changes how the business handles the underlying ambiguity.

Check your understanding

Two rows come from the same uncertain source document. Is it safe to treat them as independent merely because they occupy different rows?

Answer: No. Row separation does not remove a shared dependency. The query model must account for the relationship before combining probabilities.

Related terms

Probabilistic database
Possible world
Missing data
possible worlds
data provenance
entity resolution
confidence score
uncertainty quantification

Learn next

Create three alternative interpretations of one ambiguous record. Ask one question whose answer is unchanged across them and another whose answer differs. Document what additional evidence would resolve the second question.

Sources

Dalvi and Suciu, Efficient Query Evaluation on Probabilistic Databases: https://homes.cs.washington.edu/~suciu/vldbj-probdb.pdf

Christoph Koch, Managing large amounts of incomplete information, research abstract: https://www.cs.cornell.edu/~bistra/abstracts/oct17.htm

The paper's introductory semantics and dependency discussion and the research abstract were read. Shipment arithmetic and EvidenceOrchard are original fictional teaching examples, not results reported by these sources.

Previous: Uncertain data Next: Uncertain inference