From source data to enterprise knowledge
A real company rarely has one perfect database.
CRM knows an account one way. ERP may know the same company another way. Documents may refer to it by name. Each system has its own IDs, fields and timing.
Metrolane keeps those source systems intact — and then builds a shared enterprise view above them.
Start with the source, not the answer
Suppose CRM says:
and ERP says:
Those records may describe the same organization.
But Metrolane does not simply merge them into one row.
It first preserves what each system actually said.
Then it creates the enterprise interpretation separately.
One organization, as the systems hold it and as the enterprise reads it
Underlined keys open the real record beside this lesson.
extract
map
The source systems keep their own truth.
The canonical layer gives the enterprise a shared language.
One enterprise identity. Three source records.
Kestrel Auto Retail appears in Metrolane as:
All three resolve to
The source records do not disappear.
They remain independently inspectable.
Entity resolution is not integration
Two records can represent the same enterprise entity without being connected by a business-system handoff.
is a known CRM → ERP relationship. How do these source records interact?
Do these source records represent the same real enterprise entity?
Those statements answer different questions.
What happens between source and canonical?
The path is deliberate.
- Source record
- Connector extraction
- Raw landed representation
- Mapping / projection
- Canonical result
- Record and field lineage
Where required, add: entity resolution, survivorship.
Each layer answers a different question.
Connector — What did we extract?
A connector reads from a source system through a controlled extraction interface. It does not decide what the data means to the whole enterprise. Its job is to bring source information across without pretending it is already canonical.
Raw ingestion — What exactly arrived?
Before interpretation, Metrolane keeps a landed representation of what the connector extracted. That gives us a point between what the source said and what the enterprise later concluded.
Mapping — What does this source field mean in enterprise terms?
A mapping translates source-native structure into canonical meaning. For example: ERP Customer Invoice → mapping rule → Canonical Invoice. This is explicit rather than hidden inside UI code.
Entity resolution — Which source records represent the same thing?
Entity resolution creates the source-record → canonical-entity decision. For Kestrel, CRM and ERP records resolve to the same canonical Organization. The source IDs and canonical ID remain different ID spaces.
Survivorship — Which source supplies a canonical attribute?
Even when several source records represent the same entity, they do not all have equal authority for every field.
For Kestrel:
So canonical data can deliberately combine authoritative contributions from different systems.
Follow one invoice from source to canonical
A complete Data Journey — CINV-2026-000001
- ERP Customer Invoice CINV-2026-000001
- Connector / extraction
- Raw landed representation
- MAP-INV-ERP-CUSTOMER
- Canonical Invoice CINV-2026-000001
- Field lineage
A canonical business object can have a primary source record and additional contributing records.
Cross-System Journey vs Data Journey
These often appear close together, but they are not the same.
This explains a business handoff.
This explains a data transformation.
Metrolane keeps both visible because they answer different questions.
Chapter takeaway
- Source systems preserve operational truth.
- Canonical data creates shared enterprise meaning.
- Resolution links source identities to enterprise identities.
- Survivorship decides field authority.
- Lineage explains where canonical facts came from.