A property record does not have one truth. It has a sequence of truths—and the sequence matters.
- Business problem
- A property record does not have one truth. The date a change became effective, the date a source recorded it, the date the platform received it, and the date a model used it are four different clocks.
- Why it matters
- Collapse them and historical analytics become unstable, listing exposure and days on market are miscalculated, ownership timelines are wrong, corrections overwrite the evidence behind them, and models learn from information that was not available at the decision point — offline accuracy that does not survive contact with production.
- Architecture response
- Bitemporal modeling: store events and project state instead of maintaining current-state tables, separate corrections from real-world changes, make source precedence temporal, let late-arriving data change history without rewriting it, and support point-in-time reconstruction on every data product that matters.
- What Databright Cloud Solutions does
- We design bitemporal models, event histories, point-in-time APIs, correction handling, late-arrival policies, and the training-data discipline that keeps offline model accuracy honest in production.
This article is the third technical deep dive into the six gaps introduced in “The Real Estate Data Intelligence Gap: Why More Data Still Does Not Mean Better Decisions.”1 The first deep dive addressed Property Identity. The second addressed Semantic Consistency.
Once a platform knows which property a record belongs to and what each field means, the next question is unavoidable:
That is the temporal truth problem.
Current-state tables erase the story
Most operational systems are optimized to answer:
What is the value now?
A property-intelligence platform often needs to answer something much harder:
What was the value on March 15, what changed on March 20, when did the source publish the correction, and would a model running on March 18 have known about it?
Consider a listing whose price changes several times:
If the warehouse keeps only:
Status = Closed · ListPrice = $825K · ClosePrice = $810K
it has lost the market path that produced the transaction. That path may be the most valuable information for pricing models, seller-behavior models, market-liquidity analysis, lead scoring, and comparable-property selection.
The five clocks of property data
The easiest way to reason about temporal truth is to stop treating every timestamp as the same thing.
When the real-world condition became true: contract date, transfer date, permit-completion date, price-effective date, parcel-change date.
A date supplied by an agent, assessor, recorder, permit office, vendor, or other originator to describe when the event occurred.
When the source system itself committed or published the change.
When Databright Cloud Solutions or another downstream platform received, processed, validated, and accepted the observation.
The point in time at which an API, report, valuation, underwriting decision, AI model, or user consumed the data.
These clocks can differ by minutes, days, weeks, or months.
That difference is not noise. It is part of the truth.
RESO already distinguishes business dates from system timestamps
The RESO Data Dictionary—the industry’s shared vocabulary for listing data—contains an important temporal distinction that is easy to overlook.5
For listing lifecycle events, RESO includes business-oriented dates such as OnMarketDate and OffMarketDate, while also defining transactional timestamps such as OnMarketTimestamp, OffMarketTimestamp, PendingTimestamp, PriceChangeTimestamp, StatusChangeTimestamp, OriginalEntryTimestamp, and ModificationTimestamp.2
The difference is meaningful. RESO describes the date fields, where possible, as reflecting the date entered by the agent for when the change occurred, while the timestamp fields represent the transactional time automatically recorded by the MLS system.2
A platform that stores only one updated_at column destroys that distinction.
A listing is an event stream, not only a row
RESO Data Dictionary 2.1 includes resources specifically designed for history and events. HistoryTransactional represents transactional listing history with previous and new field values, while EntityEvent provides an event-log approach to changes.3
HistoryTransactional includes concepts such as:4
- the field that changed;
- the previous value;
- the new value;
- the modification timestamp;
- the originating system;
- the source system;
- the related resource key.
This is a stronger analytical foundation than repeatedly overwriting a listing row.
Corrections are not the same as real-world changes
Suppose a listing originally reports:
Living Area = 2,800 sq ft
On June 10 the agent corrects a data-entry mistake:
Living Area = 2,300 sq ft
Did the house physically lose 500 square feet on June 10?
No.
The source assertion changed. The physical condition may have been 2,300 square feet all along.
Compare that with a permitted addition completed on June 10:
Living Area changes from 2,300 to 2,800 sq ft because construction was completed.
Both scenarios create a different value in the current table. They represent fundamentally different temporal semantics.
The previous observation was wrong or incomplete; the underlying real-world state may not have changed.
The real-world property, contract, ownership, price, or status actually changed.
A historical value is reinterpreted because better evidence arrived later.
The source data stayed the same but a platform calculation or model version changed.
A trusted temporal model should distinguish all four.
Listing lifecycle intelligence requires the entire sequence
Consider this sequence:
A current status of Closed contains almost none of the behavioral information above.
The sequence can answer:
- How long was the property actually marketable?
- How many contracts failed?
- Did the price reduction occur before or after the first pending period?
- Was the listing temporarily held off market?
- How long did it take to secure the final buyer?
- What information was available when a comparable analysis was run?
Relisting makes “days on market” a temporal identity problem
Suppose the same property is listed, withdrawn, and relisted under a new MLS ID.
There is no universal answer without business rules.
The platform should therefore preserve:
- source-reported DaysOnMarket;
- source-reported CumulativeDaysOnMarket;
- the underlying listing status events;
- the relationship among relisted MLS records;
- its own normalized exposure metric if it chooses to calculate one.
That keeps source truth separate from analytical truth.
Ownership is especially sensitive to effective time
Public-record ownership illustrates why the date an event enters a database is not necessarily the date the event became legally or economically relevant.
Sacramento County explains that property subject to a qualifying ownership change is reassessed as of the date of change in ownership; the assessor reviews recorded deeds and determines market value as of that transfer date.6
California’s property tax rules go further: when a transfer is evidenced by a recorded document, recordation is presumed to be the ownership-change date, but evidence can establish a different effective transfer date, such as when escrow conditions were satisfied.7
If a property database simply uses the vendor ingestion date as the “ownership date,” historical ownership analytics can be wrong.
Authoritative sources can legitimately disagree for weeks
Different government systems update on different schedules.
Alameda County notes that newly recorded parcel changes can take several weeks to appear in its online parcel viewer.8 Sacramento County similarly states that assessor-map changes and the GIS parcel viewer are not simultaneous and that GIS updates can lag assessor map changes by up to four weeks.9
For a period of time, this situation may be perfectly legitimate:
The system should not blindly declare one source “wrong.” It should model the evidence and its timing.
Permits and construction have their own timeline
New construction demonstrates another multi-clock sequence.
Los Angeles County states that new construction is assessed at current market value as of the date the construction is completed, while the assessor commonly discovers construction through permit information sent to the office.10
A renovation can therefore have at least these moments:
The government authorizes work, but the property may not yet have changed physically.
The real-world state is changing, but final improvements are not complete.
The improvement becomes materially complete.
The taxing authority learns about the completed improvement.
The new characteristic or value appears in a downstream public-record feed.
A model asking “Did the remodel exist at loan origination?” needs the completion/effective timeline—not merely the latest assessor row.
Parcel lineage also needs effective dates
The Property Identity deep dive discussed parcel splits, mergers, combinations, and renumbering. Temporal truth determines when those relationships should apply.
A transaction from the prior year may correctly refer to APN 100. A current search may correctly return 101 and 102. Both are true within their temporal context.
Late-arriving data should change history without rewriting history
One of the hardest cases is evidence that arrives after its effective date.
Example:
Ownership transfer becomes effective.
Document is recorded.
Assessor processes the transfer.
Commercial vendor publishes the ownership update.
Your platform ingests it.
After February 3, the platform may know that the ownership was effective January 10.
But it must not pretend that it knew that on January 11.
This is why property intelligence needs bitemporal modeling
A simple temporal table stores a validity period such as:
valid_from · valid_to
That is useful, but property intelligence often needs a second dimension:
known_from · known_to
Together, these produce a bitemporal record.
Microsoft’s system-versioned temporal-table documentation illustrates the broader database pattern: a current table plus a history table allows point-in-time reconstruction using row validity periods.11 Microsoft also warns that transaction-time validity may not be sufficient when data arrives with significant delay—a key reason property platforms often need explicit business-effective time in addition to system time.12
What a bitemporal property record looks like
Consider an ownership fact:
Owner = ABC Holdings LLC
Instead of storing only:
property_id · owner_name
store something closer to:
The canonical property entity.
The resolved ownership party.
When the ownership is believed to have been legally/economically effective.
When the platform possessed and accepted this version of the claim.
The source-provided event date if distinct from the canonical validity window.
When the originating source recorded the change.
When the data platform received the observation.
Recorder, assessor, MLS, vendor, document number, feed version, and confidence.
Store events and build state projections
The strongest architecture uses both:
Immutable observations of what changed, when, where it came from, and what evidence supported it.
Query-optimized representations of the property, listing, ownership, or parcel state during a validity interval.
For example:
This approach allows the platform to rebuild projections when business rules improve without discarding the original evidence.
Source precedence must also be temporal
A common data platform rule looks like:
Assessor beats MLS.
That can be dangerously simplistic.
Suppose an MLS listing reports a permitted bedroom addition today, while the assessor feed is still six months behind. For the current physical configuration, the newer MLS evidence may be more useful. For tax-assessed characteristics as of the previous roll date, the assessor may remain authoritative.
Source precedence should therefore depend on:
- the field;
- the question being answered;
- the source-effective date;
- the source's expected latency;
- the observation date;
- the evidence type;
- the confidence of the match.
“Best source” is often a function, not a constant.
Every important data product should support point-in-time reconstruction
A mature property platform should be able to answer requests such as:
What was this listing’s status, asking price, and cumulative history as of 4:00 PM on February 3?
Who was believed to own the property when a foreclosure notice was filed?
What square footage and bedroom count were supported by evidence at loan origination?
Which APN represented this land before the subdivision?
What features were actually available to the AVM when it produced a valuation six months ago?
Point-in-time correctness is essential for machine learning
Temporal mistakes create one of the most damaging forms of model leakage.
Suppose a foreclosure-prediction model is trained using a dataset reconstructed today. The current record contains:
- a later ownership correction;
- a permit discovered after the prediction date;
- a final sale price;
- a subsequent lien;
- a property characteristic corrected months later.
If those values are included in a training row representing an earlier prediction date, the model is being trained on the future.
This is not a minor modeling detail. It determines whether offline accuracy survives in production.
Generative AI needs temporal context too
An AI assistant asked:
should not answer using facts learned in April unless it clearly labels them as later evidence.
A temporally grounded answer should distinguish:
- facts known during the January listing;
- events that occurred afterward;
- corrections entered later but effective earlier;
- inferences generated by the model;
- the date of each underlying source.
The result is not merely a better answer. It is an auditable explanation.
Temporal truth should be exposed through the API
Most property APIs expose only:
GET /property/{id}
A temporal property-intelligence API should also support patterns such as:
Return the platform’s reconstructed property state at a historical effective time.
Return the ordered event history with source, effective time, transaction time, and ingestion time.
Return only ownership evidence that the platform actually possessed by that historical knowledge time.
Return price and status changes rather than only the latest listing row.
Explain what changed between two moments and why.
Temporal data needs its own quality controls
Traditional data quality asks whether a value is present and valid. Temporal quality asks whether the sequence is plausible.
Does Pending occur after listing entry? Does Close precede contract? Are validity windows overlapping unexpectedly?
How often does evidence arrive materially after its source-effective date?
Which fields and sources are frequently restated after initial publication?
Are expected price/status transitions present, or did a feed deliver only snapshots?
How frequently do sources claim mutually incompatible states for the same effective interval?
How long after a source-effective event does the platform become aware of it?
Temporal expectations belong in data contracts
For each source, define expected temporal behavior.
How frequently should new source observations arrive?
What exactly does each date or timestamp mean?
Can prior values change? Does the source send correction events or only overwrite snapshots?
Can historical records arrive months later, and how should downstream state be recomputed?
Does disappearance mean deletion, suppression, expiration, licensing restriction, or source failure?
Which timestamps are UTC, local property time, source-system time, or date-only business values?
Recommended temporal property architecture
A practical implementation can use relational history tables, append-only event tables, lakehouse change tables, or a combination. The technology choice is secondary to preserving the two core questions:
- When was this assertion valid in the real-world/business timeline?
- When did our system know or believe it?
Recommended temporal fields
Not every table needs every timestamp, but high-value facts should carry enough temporal metadata to reconstruct history.
Immutable event or observation identifier.
Canonical property, parcel, listing, transaction, party, or other entity.
PriceChange, StatusChange, OwnershipTransfer, Correction, ParcelSplit, PermitCompletion, and similar.
The business-world validity period.
When the source system recorded the event.
When the source observation was collected.
When the platform received it.
The interval during which this platform version considered the assertion current.
Links a correction or revision to the earlier claim it changes.
Provider, source record, feed version, evidence artifact, transformation version, and confidence.
A practical implementation path
Retain source versions or change events before normalizing them into current-state tables.
Document which source fields represent business dates, source transactions, publication time, and ingestion time.
Begin with listing status/price, ownership, parcel lineage, permits, and mortgage/foreclosure events.
Materialize query-friendly histories with explicit validity intervals.
Support “as known at” reconstruction for models, regulated decisions, auditability, and historical analytics.
Allow new evidence to restate effective history without erasing the prior knowledge state.
Make temporal correctness reusable instead of rebuilding it inside each report or model.
Track history coverage, sequence errors, correction rates, source latency, and knowledge latency.
Temporal truth becomes a competitive data product
Once the platform can reliably reconstruct historical state, it can support products that are difficult to build from snapshot feeds:
Analyze relistings, failed contracts, price reductions, temporary holds, and cumulative market behavior.
Resolve transfers and owner changes according to effective dates rather than only latest-record snapshots.
Understand which improvements, characteristics, parcel configurations, and risks existed at a specific transaction date.
Recreate the exact feature set available when an AVM or underwriting model produced a result.
Detect meaningful changes—new lien, status change, price reduction, permit completion—and act on them immediately.
Separate contemporaneous evidence from facts learned later and show the evolution of a conclusion.
Truth in real estate is a timeline
A current-state row answers only the simplest question: what does the source say now?
A property-intelligence platform must answer more:
- What happened?
- When did it become effective?
- When did the source record it?
- When did we receive it?
- Was it a true state change or a correction?
- What did we believe before the correction?
- What information was available at the decision point?
- Can we reproduce the historical result?
Never overwrite the past merely to make the present easier to query. Preserve events, effective time, knowledge time, corrections, and provenance—then derive the current state from that history.
Deep Dive 01 established which real-world property a record describes.
Deep Dive 02 established what the fields actually mean.
Deep Dive 03 establishes when those claims were true and when they were knowable.
Sources and industry references
- Databright Cloud Solutions — The Real Estate Data Intelligence Gap: Why More Data Still Does Not Mean Better Decisions
- RESO Data Dictionary — Property Resource: lifecycle dates and transactional timestamps including OnMarket, OffMarket, Pending, PriceChange, StatusChange, OriginalEntry, and Modification timestamps
- RESO Data Dictionary 2.1 — Resource Summary: HistoryTransactional and EntityEvent resources
- RESO Data Dictionary — HistoryTransactional: previous/new values, modification time, originating system, and source system
- RESO — Data Dictionary: standardized real estate data language and interoperability
- Sacramento County Assessor — Change in ownership: reassessment as of the ownership-change date
- California Code of Regulations, Title 18 § 462.260 — Date of Change in Ownership: recordation rebuttably presumed to be the transfer date, rebuttable by escrow evidence
- Alameda County Assessor — Parcel-map processing delay after newly recorded changes
- Sacramento County Assessor — Assessor/GIS timing differences and parcel-viewer update lag
- Los Angeles County Property Tax Portal — new construction assessment as of completion and discovery through permit information
- Microsoft — System-versioned temporal tables: current/history tables, validity periods, and point-in-time reconstruction
- Microsoft — Temporal-table usage scenarios: transaction-time validity can be insufficient when data arrives with significant delay
This article provides data-architecture and technology perspectives, not legal, title, tax, appraisal, lending, regulatory, or investment advice. Effective dates and legal ownership rules vary by jurisdiction and transaction type. Production systems should preserve authoritative source evidence and domain-specific legal interpretation.