Validation review

Each result belongs to a batch and carries a source record identifier, outcome, rule and any failed field. Severity and failure reason help the operator distinguish a row that needs correction from a row that can be accepted. The operator compares row-level outcomes with the batch row, accepted and error counts before advancing the batch for review.

• Row outcome. Inspect accepted, rejected and pending results against their parent batch.
• Failure detail. Use the source record identifier, rule, field and severity to locate the error.
• Batch totals. Compare row, accepted and error counts before presenting a revision.

The Import Operator reviews results in the context of the batch that produced them. A rejected result identifies the source row and may include a failure reason; that is the starting point for a correction request. The Validation Steward groups recurring failures by rule and failed field to decide whether a definition or mapping needs attention. The Independent Reviewer should see the accepted partition and the exceptions for the same source revision, rather than a total copied from a different run.

The validation steward checks repeated failures by rule and source field. They can tell whether the sender supplied incorrect data or the mapping needs revision. An operator should retain the source reference and sequence so a corrected row can be found in the next submission. The independent reviewer reads the resulting partition rather than relying on a summary alone.

Agree whether the sender corrects the source or the Validation Steward changes a mapping when a field fails. Retain each source record identifier so the next revision can be compared with the rejected row. Before moving a batch from parsed to validated, the Import Operator checks its row count, accepted count and error count against the recorded results. A pending outcome remains visible until its disposition is understood.

Suppose a batch contains rows rejected for a required target field. The operator opens the rejected results, verifies the source record identifiers and asks for corrected values. After parsing the corrected revision, they compare its accepted count and error count with the prior run, then present that exact revision to the reviewer.

Open the rejected source rows from the first revision and compare them with the corrected submission. Check the failed field and failure reason for each, then confirm the new accepted and error counts. Present the revised batch number and revision to the Independent Reviewer with the corresponding results; do not reuse the earlier decision.

• Rejected Rows — Read failed fields and reasons for rows that need correction.
• Pending Results — See row outcomes still waiting for a final disposition.

See the related process and the data model to rehearse this handoff with a real submission.