AI database answers need a completeness contract
A database answer can be fresh, numerically correct, and still incomplete.
One regional source may be unavailable. A join may silently drop unmatched records. The reporting cutoff may exclude late-arriving events. A connector may stop after the first page while the model describes the result as the whole population.
That is why production AI database access needs a completeness contract—not just a plausible number.
Define the population before the query
Completeness has no meaning without an expected population. “Revenue by region” should identify the legal entities, regions, currencies, transaction states, source systems, and reporting interval that belong in the calculation.
Turn those choices into a versioned metric or approved operation. If the request does not provide enough scope, the tool should ask for clarification instead of silently selecting a population from conversational context.
For the related time dimension, see the answer freshness contract.
Track expected and observed coverage
A useful result envelope distinguishes what should have been queried from what was actually available. It can include:
- expected sources, partitions, tenants, and regions;
- observed sources and their watermarks;
- missing, rejected, or timed-out sources;
- expected versus observed date ranges;
- row counts before and after filters and joins;
- unknown, null, rejected, and duplicate counts;
- pagination, truncation, and result-size state;
- reconciliation status and trace ID.
The model should not infer these fields from prose. The connector should attach them from trusted execution state.
Make join loss visible
Inner joins are a common source of invisible incompleteness. An order without a matching customer, product, or currency rate disappears from the result even though the SQL executed successfully.
Record counts before and after each material join. Define whether unmatched rows should fail the operation, appear in an “unknown” category, or be excluded with an explicit reason. A production metric should never rely on accidental join semantics.
Approved views can encode this behavior consistently. See approved views for AI database agents.
Do not turn unknown into zero
Missing, not applicable, not yet received, redacted, and zero are different states. Collapsing them into the same value creates a clean-looking answer that cannot be audited.
Use typed states in the operation result. If a region is unavailable, return “source unavailable” with its last successful watermark. If a dimension is redacted by policy, report that the value is withheld rather than implying no activity.
Define partial-result policy
Some workflows can use a partial answer; others cannot. An exploratory trend may tolerate 98% source coverage if the missing region is named. A regulatory total may require every expected source and a completed reconciliation.
For each workflow, define the minimum coverage, sources that are mandatory, acceptable late-arrival window, allowed unknown rate, and response when the threshold fails. The outcome can be:
- return a complete result;
- return a bounded partial result with explicit warnings;
- refuse until missing inputs arrive;
- route to a human review workflow.
The model should not decide whether missing data is acceptable after seeing the answer.
Concrete example: revenue by region
A finance user asks for yesterday's recognized revenue by region. The approved operation expects four regional ledgers and one currency-rate snapshot.
Three ledgers succeed. The fourth times out. The query returns EUR 1.8 million from the available sources. Without a completeness contract, the model may simply answer “EUR 1.8 million.”
With a contract, the result says: three of four regions included; APAC unavailable; rates complete through the reporting cutoff; 0.4% of rows lack a product mapping; reconciliation incomplete. The workflow refuses to label the number as the company total.
Test completeness as a failure property
- Disable one expected source while keeping the others healthy.
- Add unmatched foreign keys and measure join loss.
- Insert null, unknown, duplicate, and late-arriving records.
- Force pagination and exceed the result byte limit.
- Change the expected population without updating the metric version.
- Compare the answer with an independent reconciliation query.
- Verify that the prose never upgrades a partial result to a complete one.
Keep evidence separate from explanation
The model can explain why a result is partial. It should not manufacture the evidence that proves coverage. Preserve normalized inputs, approved operation version, source set, query references, counts, policy decision, and checksums in the audit trail.
For a broader evidence model, use the audit-ready MCP database workflow.
Where Conexor fits
Conexor provides MCP infrastructure for connecting AI clients to databases and APIs through governed tools. A completeness contract makes source coverage, scope, limits, and partial-result behavior part of the operation instead of leaving them to the model.