From our field lineage

Can you explain where one property field came from?

A source URL on the record is not enough. To explain a delivered value, you need the exact observation, original assertion, transformation rule, competing assertions, and any identity decision that connected it to the property.

How we retain field evidence

The lineage stored for each delivered value.

01

Source assertion

URL · external ID · captured value

02

Transformation

Input · rule version · normalized value

03

Selection decision

Competing assertions · recency · confidence

04

Delivered field

Preferred value with a durable evidence reference

01

Store enough context to reproduce the source claim

We preserve the source, source URL, loaded URL, external ID, collection time, and canonical source URL when one exists. We also record the acquisition or parser version whenever it can change how the source content becomes a field.

The observation envelope travels with the offer or remains reachable through a durable reference. A URL in a support note fails as provenance: pages change, identifiers get recycled, and the exact value seen at collection time disappears.

02

Record the input and rule behind every derived value

For unit conversion, currency handling, enum mapping, geocoding, and calculated fields, we retain the input, output, rule name, and rule version. A derived price per area points to the exact compatible price and area observations used to calculate it.

When several offers contribute to a preferred field, we keep the competing assertions and the selection rule, including observation time and confidence where relevant. The preferred value is a view over evidence, not a replacement for it.

03

Design lineage around the questions incidents produce

During an incident, we need to answer: which source asserted this price, when did we observe it, what parser produced it, did another source disagree, was the area converted, and which match attached the offer to this property? Each answer should come from structured fields, not a manual reconstruction from logs.

This model also supports targeted repair. If one enum rule was wrong, we can find the affected fields and recompute them without recollecting unrelated sources or rewriting the original observations.

04

Follow sampled fields all the way back to evidence

We sample delivered records and trace high-impact fields—price, typed area, status, contact, and preferred source—back to their observations. We then repeat the trace after a parser migration, source removal, property split, and rematch.

Provenance completeness is measurable: required delivered fields with a valid observation path divided by required delivered fields sampled. We report that alongside field completeness because a populated field without evidence is a different kind of missing data.

  • Trace values after parser and normalization-rule changes.
  • Confirm a property split does not orphan offer evidence.
  • Keep source disagreement queryable after choosing a preferred value.
  • Measure lineage completeness separately from field completeness.

Field lineage

The evidence required to explain five common fields.

FieldRetain beside itQuestion it must answer
PriceCurrency, source text and observed timeWho asserted this amount, and when?
AreaOriginal number, unit and conversion ruleWas this converted or source-stated?
StatusSource state and observation continuityActive according to which observation?
Preferred valueCompeting assertions and selection ruleWhy did this source win?
Property linkMatch evidence and confidenceWhy are these offers grouped?

Provenance health

The four failure points in a field-level audit trail.

01

Audit completeness

Required fields with a usable observation path

02

Lineage survival

Evidence retained after rematches and parser changes

03

Rule coverage

Derived values carrying transformation versions

04

Disagreement visibility

Conflicting assertions still available for review