A field value without provenance is not yet intelligence. It is only a claim whose origin and reliability are unknown.
- Business problem
- A field value without provenance is not intelligence. It is a claim whose origin and reliability are unknown — and the question that matters is no longer what the value is, but why the platform believes it.
- Why it matters
- Where a fact originated and where you received it are different questions, source authority varies by field, and every transformation creates a new claim. Without that record, corrections erase evidence, conflicting sources get silently overwritten, and no one can defend a decision after the fact.
- Architecture response
- A provenance envelope on every decision-critical fact: original supplier, receiving system, whether it was observed, reported, inferred, or modeled, the supporting evidence, the transformations applied, the last verification, and conflicting claims preserved rather than deleted — a claim store rather than overwritten columns, joined to the temporal model, with AI-generated attributes treated as first-class claims.
- What Databright Cloud Solutions does
- We design claim stores, provenance envelopes, evidence graphs, lineage capture, conflict resolution, review workflows, and the AI governance that makes a property fact defensible rather than merely present.
This article is the fourth 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 previous deep dives addressed Property Identity, Semantic Consistency, and Temporal Truth.
The foundational article defined the Source Provenance problem simply: users see a value but cannot easily determine who supplied it, how it was transformed, how confident it is, or when it was last verified.
A property field is a claim, not an unquestionable fact
Consider a simple property profile:
That presentation is useful to a consumer. It is inadequate for a trusted intelligence system.
The underlying evidence might actually look like:
Reported by the listing agent three days ago.
County assessor record last refreshed seven months ago.
Building permit shows a completed addition after the assessor’s prior update.
Model inferred an additional bedroom from floor-plan or image evidence at 0.91 confidence.
The canonical value may reasonably be four. But the useful intelligence is not merely bedrooms = 4. It is the evidence chain explaining why four is currently preferred over three.
“Where it originated” and “where we received it” are different questions
Real estate data frequently travels through data shares, aggregators, MLS platforms, syndication systems, broker systems, and commercial vendors before it reaches the final application.
RESO explicitly distinguishes OriginatingSystem from SourceSystem. The originating system is the system where the record originated—commonly the MLS where it was entered—while the source system is the system the record was obtained from, usually the one currently hosting it.23
If Databright Cloud Solutions receives the record from Vendor C, then Vendor C is an important immediate source—but it may not be the origin of the listing data.
RESO’s own data-share example makes the point: when one MLS shares records with another, OriginatingSystemName identifies the MLS where the record was entered while SourceSystemName identifies the system now hosting it. RESO calls OriginatingSystemName the field most commonly used to tell where records originate.2 These fields are set by the publishing system and travel with the data—though not every system populates them.42
Never replace the origin merely because the data passed through another provider.
Provenance and lineage are related—but not identical
Data teams often use lineage and provenance interchangeably. They overlap, but provenance is broader.
Which tables, jobs, transformations, models, and pipelines produced this output?
Who or what originated the claim, which evidence and activities influenced it, how it traveled and changed, and why it should be trusted.
OpenLineage provides an open standard for collecting lineage metadata about datasets, jobs, and runs, including the inputs and outputs associated with pipeline execution.8 That is extremely useful for answering engineering questions such as:
- Which job created this table?
- Which input datasets influenced it?
- Which pipeline run introduced the bad value?
- What downstream products will be affected if a table changes?
Provenance extends the question to the claim itself: was the bedroom count entered by an agent, ownership read from a recorder document, square footage supplied by an assessor, or a property-condition attribute inferred from imagery?
Provenance is a well-defined data-modeling concept
The World Wide Web Consortium’s PROV family provides a useful technology-neutral model for thinking about provenance. W3C defines provenance in terms of the entities, activities, and agents involved in producing, influencing, or delivering information. The model includes concepts for derivation, attribution, association, and time.56
W3C notes that provenance can help determine whether information should be trusted, how it should be integrated with diverse sources, how it was generated, and whether the process can be reproduced.75
Provenance should exist at more than one level
A common mistake is to attach one source label to an entire property record. A canonical property row can contain attributes originating from many different sources.
Where did this file, table, API payload, or feed originate?
Which source record generated this canonical listing, parcel, transaction, or permit record?
Which source supplied the specific bedroom, area, owner, price, or tax value?
Which evidence and transformation logic caused the platform to assert a canonical or derived conclusion?
Field- and claim-level provenance are the most valuable for explainability, but they are also the most frequently lost during conventional ETL.
Every value should declare how it was produced
Not all values are observations from authoritative records. A useful property platform should distinguish at least:
Directly measured or detected from a source artifact or sensor.
Supplied by a person, organization, MLS, assessor, recorder, or other source.
Derived through rules or reasoning from one or more observations.
Produced by statistical, machine-learning, computer-vision, or generative-AI models.
Generated from a deterministic formula such as equity, price per square foot, or annualized HOA cost.
Confirmed, corrected, or overridden by a trusted reviewer.
These categories should travel with the value. A consumer should be able to distinguish reported by MLS from model-derived from an image, even when both assertions agree.
Source authority is field-specific
There is rarely one universal “best property source.”
An assessor may be authoritative for the assessed record but lag a newly completed addition. An MLS may have more current marketed characteristics but include agent-reported attributes that have not been independently verified. A commercial vendor may provide valuable national normalization while remaining one or more transformations removed from the originating source.
Confidence is not the same thing as authority
Another common mistake is to compress every trust question into a single confidence score.
County assessor characteristic from the authoritative assessment record, last updated nine months ago.
Listing agent reports a renovated characteristic this week.
Computer vision reports 0.98 probability of a swimming pool from current imagery.
A permit or legal document explicitly supports the property change.
Source authority, freshness, match confidence, model confidence, verification status, and evidence strength should remain separate dimensions even if a product later computes a combined trust score.
Conflicting sources should be preserved, not erased
Suppose a property arrives with three plausible area values:
A provenance-aware platform stores all claims and records why one was selected for a particular data product instead of destructively overwriting the losing values.
A transformation creates a new claim with new provenance
If Databright Cloud Solutions changes a source value, the resulting value should not inherit the source label as though nothing happened.
The annualized value was not supplied by the MLS. It was derived by the platform from an MLS-supplied value. The same rule applies to estimated equity, AVMs, foreclosure probability, normalized market exposure, owner resolution, and AI-generated property summaries.
Capture transformation lineage automatically
Manual documentation cannot keep up with a modern data platform. OpenLineage provides an event-oriented model for recording Jobs, Runs, and Datasets, including the inputs and outputs involved in each pipeline execution.89
Instrumentation can capture engineering lineage automatically, while the property semantic layer adds domain-level metadata such as source authority, evidence type, match method, and confidence.
Provenance and temporal truth must be joined
Provenance without time is incomplete. RESO’s HistoryTransactional resource combines change history with originating- and source-system metadata. It preserves previous/new field values, modification time, the originating system, the source system, and related record identifiers.3
A property platform should be able to answer which provider supplied a value, when they supplied it, whether it was later corrected, which source supplied the correction, when the platform learned about it, and which downstream models consumed the earlier version.
Manual corrections must not break the evidence chain
Human review is often necessary for ambiguous property data. If a reviewer determines that an MLS APN is wrong, the platform should preserve the original claim, conflicting evidence, review activity, canonical resolution, reason, reviewer, and review timestamp—not merely update the final APN column.
Preserve the value exactly as supplied by the source.
Retain assessor, GIS, recorder, document, or other observations used in review.
Record the rule, reviewer, evidence, and reason for selecting the canonical value.
Allow later evidence to supersede the resolution without erasing its history.
AI-generated property attributes require first-class provenance
AI dramatically increases the number of property claims that are not directly present in structured source systems: roof-condition classification, renovation-quality scores, solar/pool detection, document extraction, distress indicators, property-history summaries, and investor recommendations.
Every model-derived claim should carry:
Image IDs, document IDs, structured records, and feature versions used.
Provider, model name, version, prompt/extraction specification where relevant.
Run identifier, timestamp, pipeline version, and material parameters.
Model confidence, validation state, fallback path, and known limitations.
Whether the result was accepted, rejected, corrected, or left unreviewed.
Provenance fits naturally into the property knowledge graph
The graph can answer what evidence supports a characteristic, which claims were derived from a source document, which models consumed a source, which canonical values change if a provider retracts a record, and which reviewer approved an exception.
A practical provenance envelope
A reusable provenance model can be attached to canonical facts rather than reinvented for every domain.
Unique identifier for the assertion or derived fact.
The property, parcel, listing, party, transaction, or other entity and the concept being asserted.
The asserted value and relevant measurement metadata.
The system or authority where the source claim originated.
The provider/system from which the platform directly received the claim.
Original source identifier used to retrieve or reconcile evidence.
Pointer to the record, image, document, map feature, or other supporting artifact where permitted.
Observed, reported, inferred, calculated, modeled, or human-reviewed.
Temporal context for the evidence and the platform’s knowledge.
The rule, SQL job, code version, model, or workflow that produced the canonical claim.
Separate indicators for probabilistic certainty and source authority.
Unverified, source-verified, cross-source-verified, human-reviewed, disputed, or superseded.
Consider a claim store instead of overwriting columns
For high-value or disputed fields, a claim-oriented design is often more robust than one canonical row.
The consumer-facing API can remain simple and fast. Internally, the platform retains the evidence necessary to explain the answer.
Expose provenance through the API
Most property APIs return a value such as "livingArea": 2480. A trusted API can also support:
Return relevant source observations and their provenance.
Explain why the canonical value was selected.
Return supporting source references the requesting user is authorized to access.
Return transformations and downstream dependencies.
This turns provenance from internal metadata into a user-facing trust capability.
Provenance should drive data quality
How often do independent sources disagree on a governed concept?
What percentage of critical claims are supported by independent or authoritative evidence?
What percentage of derived fields carry complete transformation lineage and version metadata?
What percentage of high-risk claims link to retrievable source records or artifacts?
Which providers or fields are frequently restated after initial delivery?
How often is a canonical value changed without a documented rule, reviewer, or evidence chain?
Provenance dramatically improves incident response
Suppose 40,000 properties suddenly have implausible square footage. With provenance, the platform can trace the affected output to a transformation version, its source input field, and the upstream change that triggered the issue.
The organization can then identify affected records, downstream products, model features, and historical outputs that require remediation.
Provenance is also the foundation for usage-rights enforcement
Source Provenance and Usage Rights are tightly connected. A platform cannot reliably enforce display, redistribution, retention, AI-training, derivation, or geographic restrictions unless it knows which sources contributed to an output.
If an AI feature is derived from three upstream sources with different licenses, provenance is what allows the platform to determine which policies may need to follow the derived asset.
Recommended property-provenance architecture
Across all four layers, capture origin, immediate source, temporal metadata, transformation lineage, evidence relationships, authority, confidence, verification status, conflicts, and limitations.
A practical implementation path
Stop dropping provider IDs, originating-system fields, source-system fields, source keys, and source timestamps during ingestion.
Represent every MLS, county, vendor, application, model, and human-review workflow as a governed source/agent.
For high-value domains, retain competing source claims rather than only the final selected value.
Capture dataset/job/run lineage automatically using platform-native capabilities or an open lineage standard.
Every derived value should identify the rule, code, query, model, or semantic mapping version that generated it.
Link claims to documents, records, images, authority classifications, confidence, and verification status.
Expose “why this value?” through internal tooling and APIs rather than keeping lineage in a separate catalog.
Use upstream source participation to determine which licensing and AI-use policies apply to downstream data products.
Provenance needs an operating model, not just a table
Capture pipeline lineage, source metadata, versions, and transformation execution.
Define source authority, resolve disputes, and maintain field-level trust policies.
Decide which provenance detail consumers need and where explainability should be visible.
Preserve feature lineage, training-data provenance, model versions, evidence, and derived-output confidence.
Provenance changes the economics of property data
Show why each important canonical attribute was selected and which evidence supports it.
Offer source, confidence, freshness, and verification metadata as part of enterprise contracts.
Compare new vendors by claims, corrections, coverage, latency, and agreement against existing sources.
Know which downstream attributes and products depend on a provider before replacing it.
Trace a recommendation through model execution, features, transformations, and original property evidence.
Carry upstream licensing context into downstream derived data, models, and AI experiences.
Trust requires an evidence chain
Real estate platforms have traditionally optimized for delivering a clean row quickly. The next generation needs to deliver a clean answer that remains explainable.
Preserve where every important claim originated, how it reached the platform, what evidence supports it, which transformations influenced it, when it was verified, which competing claims exist, and why the canonical value was selected.
The first three Databright Cloud Solutions deep dives answered:
- Property Identity: Which real-world property does this record describe?
- Semantic Consistency: What does this field actually mean?
- Temporal Truth: When was this claim true, and when did we know it?
Source Provenance adds the fourth:
That question is essential for analytics. It becomes indispensable for AI.
Sources and industry references
- Databright Cloud Solutions — The Real Estate Data Intelligence Gap: Why More Data Still Does Not Mean Better Decisions
- RESO — Data Topics FAQ: OriginatingSystemID/Name vs. SourceSystemID/Name in real estate data shares
- RESO Data Dictionary — HistoryTransactional: originating/source systems, previous/new values, record identifiers, and modification history
- RESO — 2026 tools guidance: originating- and source-system metadata travel with records when populated
- W3C — PROV Model Primer: entities, activities, agents, origins, derivation, trust, and reproducibility
- W3C — PROV-DM: the provenance data model
- W3C — PROV Overview: provenance, versioning, reproducibility, procedures, and derivation
- OpenLineage — Open framework and specification for lineage metadata collection around datasets, jobs, and runs
- OpenLineage — Run Cycle: event-based lineage updates with job, run, input, and output dataset metadata
This article provides data-architecture and technology perspectives, not legal, title, appraisal, tax, regulatory, licensing, or investment advice. Source authority, evidentiary weight, contractual usage rights, and permissible downstream use vary by jurisdiction, provider, data type, and agreement.