Which “data mapping”? Three meanings, one page
The phrase is overloaded, and most of what ranks for it answers a different question. Privacy data mapping inventories where personal data lives across a company, for GDPR records-of-processing. Runtime data integration wires live systems together and executes transformations in a pipeline. This page is about the third meaning: source-to-target field mapping — the design document an integration or migration team produces before any record moves, saying which source field feeds which target field, under what rule. That document is usually a spreadsheet, it is usually built by hand from two systems’ specs, and it is the part AI can genuinely accelerate — if it can be trusted.
How Crossary drafts a mapping from spec documents
Crossary maps the spec, not the data: it reads both sides’ specification documents — Excel, PDF, CSV, JSON, XML, XSD, SQL, or YAML — rather than connecting to live systems or sampling production records, so in most cases nothing sensitive is ever uploaded. From there:
- It extracts a field inventory from each side — every field, its object, type, required flag, and description, each traceable to the document it came from.
- For every target field it proposes a mapping row: source field or expression, the rule in plain English, and the verbatim quote from your documents the suggestion is based on.
- Each row carries a self-rated confidence — a triage cue for ordering your review, not a guarantee of correctness.
- When nothing fits, it abstains instead of guessing: the row becomes an honest gap with a clarifying question, because a wrong mapping is worse than an honest gap.
- A human reviews every row — accept, edit, reject, or mark needs-info — then a deterministic validation pass runs. Validation checks structure and key semantics (type compatibility, source-field references, cardinality) — it is not a full correctness sign-off.
- Export is a reviewed .xlsx mapping workbook that round-trips: edit it in Excel, Google Sheets, or Numbers, re-import it, and no reviewer note is lost and no moved row is silently overwritten.
What makes an AI-drafted mapping trustworthy
A language model will always produce a mapping. The failure mode that matters is the plausible-but-wrong row — a confident suggestion that reads fine in review and fails in production. Crossary’s position is that trust comes from mechanics, not model quality claims: evidence you can check, uncertainty that is allowed to say so, and a human decision on every row. The suggestion is drafted by AI; the mapping is decided by a person, and the export records who signed off. The full reasoning — including why confidence scores alone are not enough and when a model should refuse to answer — is in the engineering write-up: LLM data mapping: confidence, evidence, and knowing when to abstain.
Questions, answered straight
Does Crossary move or transform my data?
No. It produces the mapping document — the design deliverable your implementers build from. Execution stays in whatever tool your team already uses.
Do I have to upload production data?
In most cases, no. Crossary works from specification documents. If a spec can only be partially read, the run says exactly how much was dropped rather than reporting a full ingestion it didn’t do.
How accurate is the AI?
Accuracy is benchmarked internally against curated real-world cases, and the honest answer is that no figure transfers cleanly to your documents — which is why every suggestion ships with its evidence, why the AI abstains rather than guessing, and why nothing is final until a person reviews it.
What happens to my documents?
Uploaded files and the database are EU-hosted; spec content is sent to our AI provider (US) for inference — the subprocessor list names every service involved — and your mappings never train a shared model. Approved field pairs can feed a private, workspace-scoped mapping library that only your workspace benefits from.