What is Field Mapping?

Every integration, migration, and data onboarding project starts with a field mapping. For each target field, the mapping records which source field feeds it and what has to happen to the value on the way.

Typical entries:

  • a date in one format becomes a date in another, and a currency amount is converted
  • a status column with nine codes is translated into the four the business recognizes
  • two identifiers in different formats are normalized so records can be joined
  • a default or an exception rule covers the values that fit nowhere

The difficult part is rarely the conversion. It is finding out what a field means. Two fields with the same name can mean different things, two systems can disagree about which value is current, and the person who knows is usually not the person doing the mapping.

For an AI task, field mapping is also the first place task fit is decided. A field mapped by name but not by meaning, such as a region column that holds the sales rep’s region rather than the customer’s, produces a model that is confidently wrong on every row. So the mapping has to be checked against what the task needs: the fields the decision depends on, their units, the join keys, and the exceptions the business handles by habit.

It also has to be kept as a reusable asset rather than a project note. A forward deployed engineer rebuilds the same mapping at every customer when it lives in a notebook. A field profile recorded per use case, with meaning, keys, and exceptions, lets the next deployment start from it. In Syntitan, the preparation steps applied to a dataset copy are recorded as a project Version, so the same mapping and exception handling can be reapplied when the next file arrives. AI data preparation starts with the task explains how to decide which fields that profile must cover.

How is field mapping different from data profiling?

Data profiling describes what is in a field: its type, its missing values, its most frequent codes. Field mapping decides what that field means for the target and what has to happen to it on the way. The two depend on each other. A profile that shows nine status codes raises the question; the mapping answers it by saying which four the business recognizes and where the other five go.

  • Profiling: measured facts about the source, produced before anyone decides anything.
  • Mapping: decisions about meaning, conversion, and exceptions, written per target field.
  • Order: profile first, map second, then check the mapping against the task.

Where does field mapping break in AI work?

A churn model is trained on a customer table where account_status was mapped by name from a billing system. In billing, one code covers both “paused for non-payment” and “paused by the customer”, and the two groups churn at very different rates. The model learns one average and misses both. Nobody wrote the distinction down, because the billing team never needed to.

The check is simple to state. For every field the task depends on, confirm its meaning with the owner, its units and formats, the key it joins on, and the exceptions handled by habit. Record the result where the next file, and the next customer, can reuse it, as Syntitan does with the preparation steps kept as a Version.

Frequently asked questions

What is the difference between field mapping and schema mapping?

Schema mapping matches structures: tables, entities, and types. Field mapping matches individual fields and specifies the conversions, code translations, and rules that make their values mean the same thing on both sides.

Why does field mapping fail in AI projects?

Fields get mapped by name rather than meaning, exceptions the business handles by habit are left out, and the mapping is never checked against the result the task has to produce.

How do you keep field mappings reusable?

Record them per use case as a field profile with meaning, join keys, and exceptions, and version them with the data so the next file or the next customer starts from the last mapping instead of from zero.