A mapping can run successfully and still change the judgment
An annotation taxonomy migration changes the rules used to describe records. A script that writes the expected number of rows has passed a transport check, not necessarily a semantic check. The receiving dataset must still mean what its users think it means.
Before migration, distinguish a rename from a split, merge or boundary change. A rename can preserve meaning. A split asks for a distinction the original label may never have recorded. That difference determines which records a lookup table can safely transform. This is technical guidance, not a report of a delivered client project.
Build fixtures around the semantic change
Create a small test set with an expected disposition for each kind of record. For an invented intent taxonomy, an old Account access label might split into Password reset and Account locked. A record whose text explicitly requests a password reset can support the narrower label after review. A record carrying only the old label cannot establish the new distinction.
Include an ambiguous record, a malformed record, an excluded record and a record whose old and new meanings genuinely agree. Do not assign the ambiguous case whichever new label makes the import succeed. Its expected disposition should be review required or another explicitly supported unresolved state.
Store the original record identifier, old label, old definition version, proposed label, new definition version and reason for the proposed transformation. Test whether those fields survive export and import, not just whether the receiving file parses.
Test splits and merges differently
For a split, assert that an automatic mapping requires sufficient record evidence. A missing source field must not silently become a default subclass. For a merge, check whether downstream users still need the old distinctions. Keeping the original label alongside the merged label can preserve information without pretending the two taxonomies are identical.
Boundary changes deserve fixtures on both sides of the revised rule. Ask qualified reviewers to apply both versions independently where feasible, then adjudicate disagreements with the source record available. Record whether disagreement reflects unclear instructions, missing evidence or an intentional semantic change.
Reconcile every source record
For a one-record-per-input design, each input should end in one mutually exclusive disposition: mapped, relabelled after review, excluded with reason, or unresolved. Check identifiers as well as counts. Equal totals can hide one duplicated record and one missing record.
If the migration intentionally creates multiple output rows, document that cardinality rule before evaluating the reconciliation. Do not call a changed row count corruption without checking the design. Keep rejected and unresolved records inspectable rather than dropping them from the evidence trail.
Preserve a comparison boundary
A quality score computed under the old definition and one computed under the new definition may answer different questions. A reviewed bridge sample can help explain the change, but it does not establish that all historical records are comparable. Report which comparisons remain defensible and which should be separated.
Pilot the transformation on a bounded, authorised sample before applying it widely. Retain original annotations and a tested recovery path. The relevant acceptance decision is whether the migrated meaning and documented exceptions meet the receiving workflow's needs, not whether the script completed without an exception.
Connect the mapping test to service scope
For broader preparation, annotation and evaluation decisions, explore XIVTech's AI data and evaluation workstreams in Australia. Confirm access, reviewer responsibilities and the proposed migration boundary during scoping.