The Semantic Consistency Problem: When the Same Real Estate Field Means Different Things

Two databases can expose a field called DaysOnMarket, LivingArea, Pending, or Bathrooms and still be describing different business realities. That is the semantic consistency problem.

This article is the second technical deep dive into the six gaps introduced in “The Real Estate Data Intelligence Gap: Why More Data Still Does Not Mean Better Decisions.”¹ The first deep dive focused on property identity. This one addresses the next foundational question:

That question affects nearly every national or multi-market product: listing search, comparable sales, AVMs, investor analytics, market statistics, lead scoring, underwriting, portfolio intelligence, data APIs, and AI agents.

Same field name does not mean same meaning

Real estate data integration traditionally begins with a mapping exercise:

This can make a warehouse look standardized while hiding a deeper problem. The values may have different definitions.

One MLS may pause days on market when a listing enters a temporary off-market status. Another may not. One may reset DOM after a relist under certain conditions. Another may use cumulative days on market. A vendor may reconstruct exposure from historical events using its own rules.

RESO’s Data Dictionary reflects this reality directly: the standard DaysOnMarket field is defined as the number of days a listing is on market “as defined by the MLS business rules.” The related CumulativeDaysOnMarket field is also governed by local MLS business rules.⁴

So even after every provider maps to the same standard field name, a national analysis can still compare unlike values.

Why semantic inconsistency is endemic to real estate

Real estate data evolved locally. MLS organizations, county assessors, recorders, municipalities, lenders, title companies, portals, and data vendors were built to solve different operational problems under different local rules.

The result is not merely messy data. It is context-dependent meaning.

RESO solves a major part of the problem—but not all of it

The Real Estate Standards Organization’s Data Dictionary exists specifically to create a common real estate language. RESO defines resources, fields, lookup values, data types, and definitions so systems can exchange listing information more consistently.²

RESO describes Data Dictionary 2.0 as a major step toward consistency across MLS systems, broker tools, and consumer applications. The current Data Dictionary organizes data into resources, groups, fields, and controlled lookup values; the emerging 2.1 documentation continues that model with explicit names, definitions, data types, lengths, and enumerations.²³

That standardization is essential. Without it, every integration becomes a custom translation project.

But semantic consistency requires one additional layer: understanding where standardized fields deliberately preserve local business meaning, where values remain open-ended, where measurements need source context, and where calculations differ.

Listing status: the vocabulary can be standard while the workflow remains local

Status is one of the clearest examples of semantic normalization.

RESO’s StandardStatus provides a controlled set of listing states such as Active, Active Under Contract, Coming Soon, Pending, Hold, Withdrawn, Closed, Canceled, and Expired. For example, RESO defines Active Under Contract as an accepted offer where the listing remains on market, while Pending means an accepted offer where the listing is off market.⁵

This resolves a huge vocabulary problem because local systems have historically used terms such as:

RESO itself notes that the interpretation of Hold and Withdrawn depends partly on whether a system uses both statuses. That is a useful reminder: standard lookup values do not eliminate all local workflow semantics.⁶

A national search experience may safely normalize several local statuses into “Pending.” A market-liquidity model, however, may need the exact local transition history, showing availability, contract state, and calculation rules. The semantic requirement depends on the use case.

Days on market is a calculation, not just a number

Days on market is often consumed as though it were a universal integer. It is better understood as the output of a business rule.

The RESO Data Dictionary distinguishes DaysOnMarket, CumulativeDaysOnMarket, DaysInMLS, DaysOnSite, and SimpleDaysOnMarket. That distinction matters because each metric describes a different clock or calculation.⁴

A data platform that collapses these into one field called dom has created apparent simplicity by destroying meaning.

A better semantic contract for calculated fields

Square footage is not one concept

Few real estate attributes look simpler than square footage. In practice, “area” can refer to several materially different measurements.

RESO distinguishes LivingArea, BuildingAreaTotal, above-grade and below-grade finished area, and a dedicated GrossLivingAreaAnsi field for livable area measured using ANSI guidelines. It also carries the measurement source in a separate field, with units expressed through a shared area-units lookup.⁷

Now add source differences:

Choosing one value and calling it square_feet may be convenient, but a valuation model or comparable-sale engine needs to know which measurement concept and source it is using.

Bathrooms show why data type and business definition both matter

Bathroom counts are another surprisingly subtle example.

RESO’s BathroomsTotalInteger is defined as a simple count of bathrooms. A property with two full bathrooms and one half bathroom is represented as three in that field—not 2.5. RESO separately supports full, half, quarter, three-quarter, and partial bathroom concepts.⁸

That means a legacy field containing 2.5 cannot simply be cast into the standard integer field without changing its meaning.

The correct transformation may require decomposing source fields, applying local rules, or retaining the original value as a source-specific attribute rather than forcing it into an incompatible standard field.

Even a bedroom can depend on local policy

At national scale, a “bedroom” appears to be an obvious semantic concept. Yet legal, appraisal, MLS, assessor, and marketing definitions can diverge.

The RESO Data Dictionary acknowledges this explicitly in BedroomsPossible, which includes BedroomsTotal plus rooms that may function as bedrooms but are not defined as bedrooms per local policy.⁷

This distinction is critical for:

• search filters;
• AVM features;
• comparable-property selection;
• permit and code-compliance analysis;
• occupancy analysis;
• AI-generated property descriptions.

A model trained on “bedroom count” without source semantics may learn different meanings in different markets.

Amounts without frequency are semantically incomplete

Association fees, land-lease amounts, rent, taxes, and recurring costs illustrate another pattern: a number needs a time basis.

RESO separates AssociationFee from AssociationFeeFrequency, whose standardized values include weekly, monthly, quarterly, semi-annually, annually, one-time, and other periods.⁹

The same architectural rule applies broadly: preserve the original economic term and create a separate derived normalization for analytics. Do not replace the source meaning with the normalized output.

Standard fields can intentionally contain local values

Not every real estate concept should be forced into a global closed list.

For example, RESO defines MLSAreaMajor as a major marketing area defined by an MLS or other nongovernmental organization. Its lookup is open, meaning providers may use local values.¹⁰

This is good standards design: “marketing area” is inherently local. But it means a downstream platform should not assume that identical-looking values from two MLSs identify the same geography—or that two different names necessarily refer to different geographies.

A semantic layer may need:

• source namespace;
• local lookup code and label;
• canonical category where one exists;
• geographic geometry or boundary relationship;
• effective dates;
• crosswalk version;
• mapping confidence.

Property type taxonomy is a hierarchy, not a flat string

“Single family,” “detached,” “townhouse,” “condo,” “attached,” “residential,” and “multi-family” are frequently mixed across source systems as though they belong to one flat category.

RESO separates broader PropertyType from more specific PropertySubType values. Its subtype vocabulary includes categories such as Townhouse, Triplex, Timeshare, Tenancy in Common, and many others.¹¹

A strong canonical model should preserve this hierarchy rather than flattening every source into a single property-type label.

Otherwise a national analytics system can accidentally compare legal ownership form, physical structure type, MLS class, and architectural style as if they were one dimension.

Missing, unknown, not applicable, and false are different meanings

Semantic inconsistency also appears in absence.

Consider a field such as PoolYN:

Collapsing all four states into NULL destroys information. Replacing NULL with false manufactures information.

For AI and analytics, this difference is especially important. “No evidence of a pool” is not the same assertion as “the property has no pool.”

MLS semantics must coexist with assessor, mortgage, permit, and other standards

RESO is central to MLS interoperability, but a property-intelligence platform rarely operates on MLS data alone.

MISMO provides standardized business names, definitions, structures, enumerations, and relationships for mortgage-industry processes through its Reference Model and Logical Data Dictionary.¹² Assessors, recorders, tax agencies, permitting systems, insurance data, climate providers, and proprietary data vendors bring still other domain models.

The enterprise challenge is therefore not:

It is:

Build a canonical semantic model—not just a canonical schema

A canonical schema defines where data goes. A canonical semantic model defines what the data means.

For each important canonical concept, the semantic model should capture:

Not every mapping should be marked “equivalent”

A mature mapping registry should support different relationship types.

This prevents a common integration failure: forcing every local field into the nearest standard field merely because the names look similar.

Semantics need versioning

Definitions change. Lookup values are added or deprecated. MLS business rules evolve. Vendor methodologies are revised. Calculation logic changes.

The current RESO Data Dictionary itself illustrates continuous evolution: RESO cut over from its long-running Data Dictionary wiki to a rebuilt platform at dd.reso.org in May 2026, and publishes Data Dictionary 2.1 as a draft alongside the ratified 2.0 release.²¹³

A semantic layer therefore needs:

• effective-from and effective-to dates;
• mapping version;
• source schema version;
• standard version;
• calculation-rule version;
• migration history;
• backfill policy.

Otherwise a historical metric can silently change meaning after a mapping deployment.

Data contracts should include semantic expectations

Most data contracts focus on technical conditions: column exists, type is numeric, value is non-null, timestamp is fresh.

A real property-intelligence contract should also test meaning.

Measure semantic quality—not only technical data quality

Completeness and freshness remain important, but they do not tell you whether a value means what consumers think it means.

AI makes semantic mistakes look more convincing

Semantic inconsistency is particularly dangerous in AI because language models and predictive systems are excellent at producing coherent outputs from inconsistent inputs.

Imagine an AI agent answering:

Every number could be technically present in the source data while still being misleading:

• 47 days may be MLS-specific DOM rather than cumulative exposure;
• 2,400 may be total building area rather than living area;
• 2.5 may be a decimal bathroom convention rather than a RESO total-integer value;
• $420 may have lost a quarterly frequency during normalization.

The AI did not hallucinate. The semantic layer failed.

A trusted AI response should be able to retrieve not just a field value, but the governed meaning behind it: definition, source, unit, effective date, derivation, and confidence.

Recommended semantic consistency architecture

A practical implementation should include:

A practical semantic onboarding workflow

When a new MLS, county, or commercial provider is added, the process should be more rigorous than column mapping.

The business opportunity: semantic consistency becomes a reusable capability

Most property-data teams solve semantic problems repeatedly inside individual pipelines, reports, and applications. One engineer maps listing statuses for search. Another recreates the logic for an analytics warehouse. An AVM team invents a separate square-footage precedence rule. A customer-facing API exposes yet another interpretation.

The better approach is to make semantics a shared platform product.

This reduces duplicate transformation logic, speeds new-market onboarding, improves model consistency, makes API contracts clearer, and creates a defensible explanation for how national metrics were constructed.

Standardized data is the beginning—not the end

RESO and other standards organizations have solved an enormous interoperability problem by creating shared vocabularies, field structures, data types, and enumerations. Modern real estate platforms should embrace those standards rather than rebuild them.

But a national property-intelligence platform must go one step further.

The first Databright Cloud Solutions deep dive established that the platform must know which property a record belongs to.

This second deep dive adds the next requirement:

That is how a property-data platform moves from syntactically standardized records to semantically trusted intelligence.