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.