Technical guides
Property data engineering guides
We write these guides from the failure modes and acceptance checks behind our own property-data pipeline: false merges, lost source evidence, broken observation continuity, silent schema drift, and deliveries that look successful before the rows are inspected.
Start with your problem
What are you trying to fix or verify?
Why a listing ID cannot identify a property.
The identity model we use to separate source listings, commercial offers, physical properties, and reversible matching decisions.
Read guide → 02 · From our matching pipelineHow to deduplicate listings without merging different homes.
How to resolve duplicate property offers across portals without collapsing distinct units or losing source-level evidence.
Read guide → 03 · From our observation historyWhen a listing disappears, you still do not know it sold.
How we turn accepted listing observations into price, status, removal, and reactivation events without overstating what happened.
Read guide → 04 · From our field lineageCan you explain where one property field came from?
The field-level evidence we retain so a normalized property record can be audited after conversions, source conflicts, rematches, and parser changes.
Read guide → 05 · From our cross-country schemaOne property schema should not erase how local markets work.
How we make property records comparable across countries while preserving local categories, address structures, area meanings, and missing values.
Read guide → 06 · From our acceptance processA property API demo can pass while the dataset fails.
The acceptance matrix we use to test property API coverage, persisted rows, freshness, identity, provenance, recovery, and billable delivery.
Read guide →Apply it to a real workflow
Start with one market, one decision, and explicit acceptance criteria.
We will map the required sources, fields, freshness, identity, and delivery boundary before defining the integration.