The Completeness Problem: Why an Empty Field Is Not the Same as a No

This article is Deep Dive 07 in the Databright Cloud Solutions Property Intelligence series.¹ The first six gaps each concern a value that exists: which property it belongs to, what it means, when it was true, where it came from, what evidence supports it, and what you are permitted to do with it.² None of them asks the question that production keeps raising: what about the fields that are empty?

Why the original six did not cover this

The series closed with a summary that reduced the framework to six questions: which property, what does it mean, when was it true, where did it come from, what evidence supports it, and what are we allowed to do with it.² That set holds up. Its blind spot is structural rather than accidental: every one of those questions takes a value as its subject. Each presupposes that there is something there to resolve, date, attribute, or license.

Real property data is mostly not like that. Coverage varies enormously by field, by market, by source, and by vintage. The interesting question in a great many production incidents is not “what does this value mean?” but “why is there no value, and what am I entitled to conclude from that?”

So the seventh question is: what do we not know? It belongs with the other six because it has the same character — a property of a fact that has to be asserted explicitly, cannot be inferred from the data alone, and silently corrupts everything downstream when left undeclared.

A null is not a no, and the standards say so

This is not a matter of interpretation. In the RESO data dictionary context, boolean fields may be null as any OData field is nullable, and a null value means the provider has not stated the value — it is not interpreted as false.³ The query semantics follow: OData treats null as unknown in comparisons, so an operand that evaluates to null yields null rather than true or false.³

The standard is doing the right thing. Three-valued logic is the correct model for data where absence is common, and the specification is careful to say that an unstated value is unstated rather than negative.

The damage happens one layer down, where a well-meaning transformation flattens three states into two. A boolean column in the warehouse with a NOT NULL DEFAULT FALSE constraint. A JSON serializer that omits null keys, so the consumer cannot distinguish absent from unset. A dataframe operation that fills missing values before anybody has decided what they mean. Each of these is a one-line convenience that converts “we do not know” into “no” permanently, and none of them logs anything.

Five kinds of missing, and they are not interchangeable

Treating all empty cells identically is the root error. They are not the same kind of thing, and the correct downstream behavior differs for each.

The practical consequence is that a single nullable column cannot carry this. A value and a status are two different facts, and the status needs its own vocabulary — a closed one, declared up front, for the same reason any countable dimension does.⁴

Some values are missing by statute

The withheld category deserves a concrete case, because it is the one that surprises teams building nationally and it cannot be engineered away.

In the United States, twelve states are generally described as non-disclosure states, where law shields the final sale price of a transaction from the public record — commonly listed as Alaska, Idaho, Indiana, Kansas, Louisiana, Mississippi, Missouri, Montana, New Mexico, North Dakota, Texas, and Wyoming.⁵ Licensed participants may reach the figure through other channels; the public record does not carry it.

So a null sale price on a Texas parcel does not mean the property did not sell, and it does not mean the price is unknown to everyone. It means the value is not disclosable through that source. A pipeline that treats it as “unknown” is closer to right than one that treats it as “no sale”, but both lose the fact that matters: this absence is lawful, permanent, and geographically systematic. Valuation models in these markets are consequently working from proxies, which is a documented reason automated valuation is harder there⁵ — and a reason a confidence figure has to be explainable rather than merely produced.⁶

Across sources, the reason for the gap decides the merge

Running more than one source looks like the obvious cure for absence: where provider A is empty and provider B has a value, take B. That rule is wrong often enough to matter, and whether it is wrong depends entirely on why A was empty.

If A is empty because it never collects the field, B genuinely adds information and the merge is sound. If A is empty because the value is withheld by statute, B’s figure may be reaching you through a channel with different permissions attached, which makes the merge a rights question before it is a quality question.² And if A is empty because the field is not applicable — acreage on a condominium — then B offering a number is evidence that B is wrong, not that A was incomplete.

Conflict resolution across property sources is a hard problem even when every source has a value.¹⁰ Partial coverage makes it harder in a specific way: a precedence rule expressed only over values cannot see this distinction, because at the point the rule runs, all three cases look identical. The absence status has to be an input to the merge, which means it has to survive ingestion — the one place pipelines most reliably discard it.

Missingness is itself a signal

There is a further reason not to paper over absence: the pattern of what is missing often carries information about the thing you are trying to measure.

Listings with sparse optional fields are not a random sample of listings. They skew toward particular agents, particular price bands, particular urgency, particular brokerages with weaker data discipline. The same holds for public records: parcels with thin attribute coverage cluster in jurisdictions with older systems and less frequent reassessment.

That means missingness correlates with outcomes you care about. Fill it in with a market median and you have not recovered the missing information — you have destroyed a genuine signal and replaced it with one that makes the sparse records look like the dense ones. For a model predicting days on market or price, the indicator “this field was blank” is frequently more predictive than any plausible imputed value, and it is free.

Three-valued logic breaks filters quietly

Once absence is honestly represented, query semantics stop being intuitive, and this catches experienced engineers because the failure produces plausible numbers rather than errors.

Consider a pool field over a million records: 300,000 true, 200,000 false, 500,000 null. Three reasonable-looking filters give three different answers.

All three are defensible for some question. None is interchangeable with the others. And a dashboard reporting “homes without a pool” has silently chosen one, almost certainly without anyone recording which.

The same arithmetic ruins percentages. “30% of homes have a pool” is only true over the whole population if you believe every null is a negative. Over the known population the figure is 60%. Those two numbers support opposite conclusions in a market analysis, and the difference is entirely a denominator choice nobody wrote down.

Completeness is a per-field property, not a record score

A common response is a completeness percentage per record — this listing is 82% complete. It is close to useless, because it averages fields of wildly different importance and smears markets together. A record missing an optional remark and a record missing the sale price are not 82% and 82%.

The useful unit is a coverage rate per field, per market, per source, per vintage. That is a table, maintained deliberately, and it is the artifact that lets you answer the questions completeness actually raises: is this field usable in this market at all; did coverage change in March because the source changed something; is the trend I am looking at a change in the world or a change in reporting.

Coverage changes, and it changes history

Coverage is a property of a vintage, not a constant, and the day it improves is the day your trend lines move for reasons that have nothing to do with property.

A source adds a field to its export in March. Coverage for that field goes from 40% to 85% overnight. Every aggregate computed over the populated subset shifts, and if the newly populated records differ systematically from the previously populated ones — which they will, because the earlier population was whoever happened to fill it in — the shift has both a size and a direction that look exactly like a market event.

The reverse is just as common and less often noticed. A source narrows what it publishes, a license renegotiation removes a field, a county changes systems and stops emitting a value. Coverage falls, the populated subset changes composition, and a metric moves.

This is knowledge time wearing different clothes. What a platform knows about a parcel changed in March; what was true about the parcel did not. Keeping those two clocks separate is the discipline the temporal gap already demands, and absence is simply the case where the earlier state of knowledge was “nothing.”⁹

Every aggregate needs its denominator attached

If coverage varies by market, then any cross-market comparison built on a sparse field is partly a comparison of reporting practice. Average days on market across two metros, where the field is populated on 95% of listings in one and 60% in the other, is not a like-for-like figure — and the gap will be stable enough to look like a real regional difference for years.

The remedy is procedural rather than clever. Every published aggregate carries the count it was computed over and the coverage rate of the fields it depends on, in the same view, not in a footnote or a data dictionary nobody opens. A number without its denominator is an assertion; a number with one is evidence.

This is the same discipline as resolving what a metric means before anyone queries it. A coverage-aware metric definition states the population, the eligibility rule, and the handling of unknowns once, centrally, so two teams cannot compute “pool penetration” two ways.⁴

What this does to a language model

A model asked whether a property has a pool, handed a record with an empty pool field, will usually say no. It is not malfunctioning. Natural language has no idiomatic way to express an unstated boolean, the training distribution is full of confident answers, and nothing in the record it was given marked the field as unstated rather than negative.

Prompting does not fix this reliably, and treating it as a hallucination problem misdiagnoses it. The honest answer — “that is not recorded for properties in this county” — is only available to the model if the data contract it queries can express it. That means unknown has to be a value the query layer returns, with the reason attached, rather than an empty cell the model must interpret.

This also belongs in the evaluation set as its own category. A test suite of answerable questions will never catch a system that answers unanswerable ones confidently, so include records with each of the five absence types and assert that the response declines rather than guesses — weighted by what a wrong answer costs, since “no pool” in a listing description and “no flood history” in a disclosure are not comparable errors.⁷

When to impute, and when to refuse

Imputation is legitimate. Treating it as a universal fix is not. The distinction that holds up in practice is what the value will be used for.

For ranking, scoring, and model features, imputing is often correct — a recommendation engine needs a number and the cost of a slightly wrong one is low. For anything a person will read as a fact, anything that feeds a disclosure, and anything leaving your platform through an API, imputed values must be labeled as derived and must never be presented as observations.

That labeling is a provenance obligation, not a nicety. An imputed value re-exported without its derivation becomes an observed fact in the next system, and after two hops nobody can tell which figures were measured and which were inferred.⁸ The rule worth enforcing at the boundary: a derived value carries its method, its inputs, and its as-of date, or it does not leave.

What to record

Concretely, the field-level model that makes all of the above expressible is small.

The seventh question

The six original gaps describe what it takes to trust a value you have. This one describes what it takes to be honest about the values you do not, which turns out to be most of them in any national property dataset.

The failure mode is characteristic of the whole series: nothing errors, nothing alerts, and the platform produces numbers that are precise, internally consistent, and describing a population that does not exist. It is the same shape as reading a vendor ingestion date as an ownership date, or treating two sources with matching field names as agreeing. An unexamined convention quietly becomes a claim.