Home / Platform / Mapper

Consolidate, cleanse and unify.
Without building a warehouse.

Bring separate systems together by saying what their columns mean — then read one unified record set straight out of the connections. No target schema to design, no copy to keep in sync, and no correction you cannot undo.

Drag-and-drop mapping Cross-source merge Computed on read Idempotent, re-runnable
Data consolidation, in motion

Three systems, three names for one key.
One record set out.

An illustration: a CRM, an ERP and a billing system each call the customer something different. Say once what the columns mean, and the data is already consolidated — including the customer that only one system knows about. Press Replay to watch it again.

The Mapper · watch it done, then try it yourself

Drop two columns on one object.
That is the whole join declaration.

Five real models from the BUSINESS knowledge area. Watch the three drops that merge them — then drag a column onto a grid object yourself, or tap one, then tap the other. Dropping a second column onto the same object declares that the two mean the same thing.

Mapper · quadrant “Governance, Business & Finance” · KA BUSINESS
objects 0 links 0 join keys 0 / 3
Source panel · 5 models
The grid · one object per real-world thing
Nothing has been altered. Adding a model to the workspace is a read — the sources are neither consumed nor tombstoned, and remain independently queryable throughout.

The three join keys are the only modelling decisions in the entire procedure. Concepts that appear in only one source — PRICE, JOB TITLE, POSTAL / ZIP CODE — go onto objects of their own: they contribute columns without contributing relationships.

Forty years of the same three problems

The warehouse way,
and the Mapper way

The warehouse way

  • Design the destination before you understand the dataA target schema has to be agreed up front. Every source that arrives later either fits it or forces a redesign.
  • Copy everything, then keep the copy in stepExtract, transform, load — and now the same fact lives in two places, drifting apart between runs.
  • Cleanse inside the pipeline, where nobody can seeCorrections happen in transit. The original is gone, the blast radius was never shown, and reversing it means a restore.

The Mapper way

  • Describe meaning, not structureDrag a source column onto what it MEANS. A meaning that already exists elsewhere is recognised and bridged automatically.
  • Nothing is copied — values are already sharedA value is stored once and every record carrying it points at that one entry, so two systems naming the same thing are already joined.
  • Cleansing is consented, audited and reversibleSee exactly which systems and how many records a correction will touch — before it happens. The original is retained in the ledger.
How the join actually happens

No key was declared
anywhere

Because a value is stored once per concept, an order carrying CU1061 and a customer record carrying CU1061 hold associations to the same item. Testing whether two records are related is an identity comparison, not a string comparison — it is exact, it is case-consistent, and it costs nothing.

Join keys are discovered, not declared: an identical value in an identical concept is an identical item.
See the store model →

What the merge writes

A star schema, plus a manifest recording where every column came from.

A Nexus and a Group

The Nexus is the hub — one item per record. The Group holds the column order. Together they make the model a star schema rather than a bag of concepts, which is what makes it queryable as a table.

One concept per grid object

Concepts are reused by name when merging into an existing model, so re-running a merge never duplicates them.

A provenance manifest

Each column concept carries a single item of the form __MAP|BUSINESS|CUSTOMER ID, recording the knowledge area and source column it draws from. Provenance is not documentation that can drift — it is data, stored beside the values.

The part most systems get wrong

The unmatched rows
are the finding

The reconstruction is a full outer join. A record that found no partner still appears. An inner join would have silently deleted all four of these findings — and they are frequently the most valuable output of the exercise.

29

Customers with no order

Acquired, never converted.

18

Products never ordered

Dead stock in the catalogue — 18 of 70.

11

Reps with no order

Inactive or newly hired.

10

Regions with no customer

Territories with no presence.

These rows have blanks because there is nothing to fill them from. A product that was never ordered has no order date, no quantity and no customer — the absence is not a defect in the merge, it is a fact about the business. The Recordset view shows the fully-linked rows by default, with a single control to reveal the unmatched ones. Nothing is discarded, and the count of what is being held back is always on screen.
↕️

Sortable columns

Every header sorts; a second click reverses. Numeric columns sort numerically (778 before 1,160, not after it), dates chronologically, text case-insensitively. Blank cells always sink, so reversing a sort reorders the data rather than raising a wall of empty cells.

📄

Paged at 500

Matching the engine's own page size, with a jump-to-range menu. Sorting applies to the whole result and the page is taken from it — never a sort of only the visible page.

📤

CSV export

The entire current view, in the current sort order, RFC 4180 quoted.

Consolidation, on real data

Two unrelated systems,
one shared key

A vehicle fleet and a power-grid asset register, held in different parts of the business.

System A · Fleet

KEY · VEHICLEID
DEPOT · MODELYEAR
its own quadrant of the business
SHARED
KEY
the only thing they have in common

System B · Grid assets

ASSET · SITE · FUEL
MW · OPERATOR
a different quadrant entirely
0 → 0
source rows resolved into unified records, on read
10
columns in one record set
0
rows copied · 0 changes to either source
full outer
an unmatched row is still returned, never dropped

What did NOT happen

  • ✕ No target schema was designed.
  • ✕ No rows were copied into a new store.
  • ✕ No pipeline was scheduled, and none can now drift.
  • ✕ Neither source system was altered in any way.

Why it cannot fall out of date

The unified view is computed when you read it, from the links themselves — so it cannot fall out of date with its sources. There is no materialised copy, which means there is nothing to refresh, nothing to reconcile, and nothing to monitor for freshness.

re-running a merge is idempotent
The Mapper grid in the product
The merge grid, in the product
The merged model as a graph
The merged model, as a graph
What this replaces

Every arrow is a mouse action
or a sentence — not a script

ConventionalAtomicDB
Destination schema, designed and migratednone — the grid is the schema
ETL / ELT job, written and testednone
Join keys declared in SQLnone — shared values are the keys
Scheduler and freshness monitoringnone — retrieval reads live state
Rebuild when a source adds a columndrag the new concept onto the grid
Provenance tracked in documentationstored as data, in the manifest
Engineering timeminutes, by the person who owns the data
The person who understands what CUSTOMER ID means is the person who performs the merge. That is the substantive change: the modelling decision stays with the domain expert instead of being translated, imperfectly, into someone else's code.
Notes, limits and honesty

A capability document that
omits limits is a brochure

The engine returns at most 500 records per request and reports the true total alongside them. The Mapper pages through until it holds the complete set; where a ceiling is reached, it states the shortfall on screen rather than reconstructing quietly from part of the data.
The merge does not consume or tombstone the datasets it draws from. They remain independently queryable, and the merge can be re-run or widened at any time.
Concepts are reused by name, links are added never duplicated, and records already carried are skipped — so merging again after a source has grown adds only what is new.
Because relationships come from shared values, two datasets that share no value cannot be related by the Mapper, however obviously they belong together to a human reader. The remedy is the same as the rest of the procedure: place a concept both datasets populate onto one grid object.

The worked example on this page was executed against a live AtomicDB instance on 19 August 2026. Record counts, column counts, join keys and unmatched-row breakdowns are measured values, not illustrations.

Now clean a dirty value → Ask the merged model a question