CONTEXT(CLONE)
Sign in

Cross-check a source-to-target mapping before migration

For: Data migration lead or solution architect moving a legacy system to a new platform

Pattern: Cross-examinationNeeds scaleDesigned for 40 to 2,000 agents
Get early accessSign in to use

The pain today

The mapping sheet has thousands of fields, filled in by different people from column names. Wrong mappings surface after cutover, when balances or statuses no longer reconcile.

The ask

“I attached the source and target data dictionaries, the mapping sheet and the transformation rules. For every field, check independently whether the mapped target matches in meaning, type, units and allowed values. Show me the mappings the two checks disagree on.”

Plain words, as you would say it to a colleague. Edit it to fit your case before you send it.

What you attach or connect

  • Source data dictionary
  • Target data dictionary
  • Mapping sheet
  • Transformation rules and code lists

The unit of work

One worker task per one field mapping.

Why a swarm fits

Each mapping needs two field definitions and one rule. Thousands of mappings are independent, and two model families checking each one separately exposes mappings that only look right by name.

Not for

Testing migrated data. It checks the written mapping against written definitions; reconciliation runs still need real data.

The decision tree

6 typed decisions, each with an action for every answer

At fixed moments in a run, the engine puts one narrow question to a decision model. The decision model never writes text: it answers yes or no with a probability, picks from listed options, or gives a score, about a small slice of the material. The engine then does exactly what this tree says, which is what makes the run auditable. The thresholds are the template's design values, not measured results.

  1. Planner, while planning

    Scope checkA choice among options

    Before work starts on a unit

    Do both the source field and the mapped target field have a written definition to compare?

    Sees only: One mapping row with the two dictionary entries, if any

    Why: A mapping with no definitions cannot be verified and is reported as such, not guessed.

    • Both definedthenAccept
    • One or both undefinedthenMark unresolved
    • Row is not a field mappingthenSkip this unit

  2. Before workers, before a task runs

    Small worker or strong modelYes or no, with a probability

    Before a task runs

    Can this mapping be checked from the two definitions alone, with no code list, unit conversion or derived value involved?

    Sees only: One mapping row, its transformation rule and both definitions

    Why: Value-by-value code list checks and conversions go to the stronger model; plain fields stay cheap.

    • Yes: 0.60 or higherthenAccept
    • Unsure: 0.40 up to 0.60thenEscalate to a strong model
    • No: below 0.40thenEscalate to a strong model

  3. After workers, the judge checks

    Evidence checkA choice among options

    After a worker answers

    Do the quoted source and target definitions describe the same business fact, measured in the same unit and at the same point in its life?

    Sees only: The quoted source definition, target definition and transformation rule for one mapping

    Why: Separates a wrong mapping from a right mapping that still needs a conversion.

    • Same meaningthenAccept
    • Different meaningthenReject and retry
    • Same meaning, type or unit differsthenMark unresolved
    • Definitions too thin to saythenMark unresolved

  4. Reconciler, while merging

    Conflict checkYes or no, with a probability

    While reconciling

    Did the two independent checks reach different verdicts on this field mapping?

    Sees only: Both families' verdicts and quoted reasons for one mapping

    Why: Mappings that look right by name are where families disagree, and where cutover defects hide.

    • Yes: 0.70 or higherthenEscalate to a strong model
    • Unsure: 0.30 up to 0.70thenEscalate to a strong model
    • No: below 0.30thenAccept

  5. Run control, between rounds

    Retry or stopYes or no, with a probability

    After a rejection or low confidence

    Do the written definitions and code lists contain enough to settle the disagreement, without asking someone who knows the legacy system?

    Sees only: Both verdicts, both definitions and any code list for one mapping

    Why: Disputes that need legacy knowledge go to people instead of burning more model calls.

    • Yes: 0.85 or higherthenEscalate to a strong model
    • Unsure: 0.50 up to 0.85thenMark unresolved
    • No: below 0.50thenMark unresolved

  6. Accountable person, before anything is settled

    Person decidesYes or no, with a probability

    Before anything is reported as settled

    Is this rejected or disputed mapping for a field that carries a balance, a status, a date that drives processing, or a mandatory target value?

    Sees only: One rejected or disputed mapping with both definitions

    Why: Fields that break reconciliation after cutover are decided by the migration lead and data owners.

    Accountable: The migration lead and the business data owners approve every change to the mapping.

    • Yes: 0.40 or higherthenAsk a person
    • Unsure: 0.15 up to 0.40thenAsk a person
    • No: below 0.15thenAccept

The fleet: who does what

Model tiers by role, not brands: you choose the models. Strong reasoning models plan and reconcile, small fast models do the wide work, and the judge is a decision model from a different family, so it does not share the workers' blind spots.

  1. Planner

    A strong reasoning model splits the sheet by subject area and attaches the right definitions and code lists to each mapping.

    Decisions here:1. Scope check

  2. Workers

    Two sets of small fast workers from different families check each mapping independently, quoting both definitions.

    Designed for 40 to 2,000 agents, one worker task per one field mapping. Each worker receives only its own unit.

    Decisions here:2. Small worker or strong model

  3. Judge, from a different model family

    A decision model from a third family settles disagreements the definitions resolve and keeps the rest open.

    Decisions here:3. Evidence check

  4. Reconciler

    A strong reasoning model reports agreed, rejected and disputed mappings by subject area.

    Decisions here:4. Conflict check5. Retry or stop

  5. Accountable person

    The migration lead and the business data owners approve every change to the mapping.

    Decisions here:6. Person decides

Checked before anything is accepted

  • Each verdict quotes the source and target definitions it compared
  • Type, unit and allowed-value mismatches are reported separately from meaning
  • Code list mappings are checked value by value
  • Fields with no definition on either side are marked unverifiable

What comes back

  • Mappings both checks accept, with quotes
  • Mappings both checks reject, with the mismatch named
  • Disputed mappings for the migration lead
  • Unmapped mandatory target fields and unverifiable fields

What to measure

  • Share of rejected mappings the migration lead confirms
  • Mapping defects found in test cycles that the run missed
  • Analyst hours per subject area
  • Cost per mapping checked

Names of measures only. No result is claimed for this template.

Templates open in the workspace chat with the ask filled in. Nothing runs until you send it.

Get early accessSign in to use

More in Data and analytics

Find conflicting definitions across the data dictionary

For: Data governance lead or analytics engineering manager

Active customer, net revenue and churn are each defined several ways across tables, models and dashboards.

Pattern: Map, verify, reduceNeeds scale6 decisionsDesigned for 40 to 1,500 agents