Every object validated against target rules before it is submitted, every load reconciled after it lands, and every rejection tracked as an exception with an owner. The output is a pack that shows the migration was complete, not a log that says the job finished.
Validation asks whether this record will be accepted. Reconciliation asks whether everything that should have arrived did. A migration needs both, and most failures come from doing only the first.
Validation runs before submission. Mandatory fields present, values within the target's allowed sets, references resolvable, effectivity ranges non-overlapping, components existing at the revision the structure expects. Catching these in staging costs minutes; catching them in a Fusion import job costs a cycle, because the rejection list arrives after the load window has been spent.
Reconciliation runs after. Counts and control totals compared across three stages, source to transformed to target, per object family, so a shortfall is visible as a number rather than discovered later by a user who cannot find a part. Record-level tracing then answers the specific question: this part number, where did it go, and what did each stage do to it.
Exceptions bind the two together. Every rejected or unmapped object becomes a tracked item with a reason, an owner and a status, and the exception list is a programme artefact that shrinks cycle over cycle rather than a log file that gets regenerated.
What the pack is made of when quality and audit ask for evidence.
Target business rules applied in staging, so a load submits data that has already passed the checks the import will run.
Counts and control totals by object family across all three stages, with differences explained rather than tolerated.
Follow one part number, one change order or one drawing from source row to target record through every transformation applied.
Every rejection with its reason, owner and status, tracked across cycles so progress is measurable.
Results compared between rehearsals, so an unexpected difference points at a rule change or a data change rather than a mystery.
The document set that evidences completeness, produced from the run rather than assembled by hand afterwards.
Five checkpoints, each cheaper than the one after it.
Quality issues found while there is still time to fix them at source: orphans, duplicates, invalid references, inconsistent population.
Transformed output validated against target rules in staging, before any import job is submitted.
Import rejections captured with their reasons and turned into tracked exceptions rather than left in a job log.
Counts, control totals and relationship checks compared against the source baseline by object family.
The pack produced, circulated and signed, with the exception register attached and its trend across cycles visible.
Pre-load validation is the cheapest place to catch a problem. A rule breach found in staging costs minutes; the same breach found by a Fusion import job costs a cycle, because the rejection arrives after the window has been spent.
These six categories run against every transformed record before a payload is generated.
Three levels of rigour, with very different outcomes at audit.
A handful of parts opened in the target. Finds obvious breakage, proves nothing about the other hundred thousand records.
Says how many rows were processed and how many failed. Says nothing about the records that were never submitted.
Counts, control totals and record-level traces across source, transformed and target, with every gap owned and explained.
Four classes of check. Structural integrity, meaning components resolve at the revision the structure expects, AML entries point at manufacturer parts that exist, and attachments are bound to real objects. Target rule compliance, meaning mandatory fields, allowed value sets, formats and lengths match what the target accepts. Temporal consistency, meaning revision effectivity does not overlap and change effective dates can be replayed in order. And completeness, meaning counts and control totals reconcile across the three stages of the migration.
Validation is predictive and runs before submission: will this record be accepted. Reconciliation is retrospective and runs after: did everything that should have arrived actually arrive. Programmes that only validate can pass every rule and still be short several thousand records, because a record that was never submitted never fails a rule. Programmes that only reconcile find out about rule breaches after a load window has been spent.
Each source object carries a stable key through the pipeline, and DataVault retains the source snapshot, the transformed record and the target result for each stage. Given a part number, a change order or an attachment, you can see the source row as extracted, the transformation rules applied and their output, the payload submitted, and the resulting target record or the rejection with its reason. That is what answers a specific question about a specific record, months later.
They become tracked exceptions rather than silent losses, which is the important distinction. Each carries a reason, a category, an owner and a status. Exceptions route to whoever can resolve them: a source data fix, a mapping rule change, or an explicit business decision to exclude the record. The register is reviewed each cycle, and the trend across cycles is the real measure of whether the migration is converging.
Partly, and it is worth doing. Structural integrity, temporal consistency and source data quality are all source-side and can be checked as soon as extraction runs. Target rule compliance needs the target configuration, since allowed value sets and mandatory fields depend on how the target has been set up. Running the source-side checks early typically removes a large share of the issues before the target is even available.
Aggregate reconciliation by object family across source, transformed and target stages, with differences explained. A sample of record-level traces covering each object family. The exception register with its status and its trend across cycles. Checksum verification results for attachments. And the run evidence: timings, volumes and the rule versions applied. It is generated from the run rather than assembled afterwards, which is what makes it evidence rather than a summary.
Book a call and we will walk through an actual reconciliation pack: what is compared, how a record is traced, and what your quality and audit teams would be signing.