Two Issued Client Reports Swapped Source-Lineage Maps: Restore Both Evidence Chains

A wrong data lineage map on a client report is an evidence problem first. If Report A points to Report B's extracts or transformations, both reports are suspect until you can show the actual path from source to issued output.

Treat the reports as separate evidence chains. Preserve the issued files and delivery records, together with the accepted lineage maps and current source snapshots. Do not overwrite the original artifacts while investigating.

Provenance is a record of the people involved in producing or delivering data, along with the relevant entities and activities. The W3C model is useful here because it separates the data objects and their associated processing steps and responsible parties that belong in a report trail.

• Freeze distribution and any scheduled follow-up or downstream client action tied to either report.
• Assign one incident owner for the evidence review and one approver for client communications.
• Set a review deadline based on the earliest client decision that relies on either report.

What should be preserved before rebuilding the lineage maps?

Keep the issued version of each report immutable. Record its complete identification and delivery record, plus any conclusion or action the client was asked to take.

Preserve the source extracts exactly as reviewed, including the extraction time and query-or-export identifier, plus the source system and hash. Then preserve every transformation version that could have produced the issued output.

Do not start from the current dashboard or a refreshed export. A new export may be useful for a later update, but it cannot prove what supported an already issued report.

How do you restore each source-to-report evidence chain?

Start with the issued report, then work backward. For each table or chart, as well as every recommendation or client action, identify the output artifact that supplied it. From that output, identify the transformation version and the exact source extract used.

Use hashes to distinguish artifacts with similar names. A filename is a label. A hash helps establish whether the preserved extract and transformed output, together with the issued file are the same artifacts that were reviewed.

Record an accepted map and an observed map separately. The accepted map is the lineage path people believed at issue time. The observed map is the path supported by preserved artifacts. A swap is established only when the observed evidence differs from the accepted path.

• Create one row per report output, not one row per report title.
• Attach the exact source extract and transformation version to every output row.
• Record how each artifact was produced, reviewed and approved.
• Mark missing evidence as missing. Do not fill a gap with a likely source.

Which conclusions need to be retested after the maps are corrected?

Retest every conclusion that names a trend or exception, or any recommendation, priority or client action. The right test is narrow: can the corrected lineage chain support this exact statement in this issued report?

Classify each conclusion as retained, qualified, corrected, or unsupported. Retained means the corrected chain supports the issued wording. Qualified means the core point remains but the wording, scope, or confidence must change. Corrected means the issued statement was wrong. Unsupported means the preserved evidence cannot recertify it.

The W3C PROV constraints describe validation as consistency checking for a history of objects and interactions. Apply the same discipline to the ledger: an extract cannot support a report output if the recorded transformation path does not connect them.

• Retained: keep the conclusion and document the corrected source-to-report path.
• Qualified: state the narrower conclusion and the limit created by the lineage issue.
• Corrected: replace the affected conclusion and identify the prior statement precisely.
• Unsupported: withdraw the conclusion until a separately sourced analysis can support it.

When should both reports be qualified, corrected, or reissued?

Reissue a report when the corrected map changes a material conclusion or client action, or a figure, scope or confidence level. Also reissue when you cannot recertify material content from preserved evidence.

Qualify a report when the corrected chain supports the substance but not the full scope of the issued wording. The qualification should name the affected section and state the narrower interpretation.

Do not reissue merely because the internal map was messy if the corrected chain fully supports every material output and conclusion. In that case, fix and document the lineage record and review, then retain the issued report.

For regulated data integrity contexts, the FDA's drug CGMP guidance says data should be reliable and accurate and that organizations should use meaningful, risk-based strategies to prevent and detect integrity issues. That guidance is specific to drugs, but the practical correction pattern here is a recommendation: preserve the evidence while assessing impact and clarifying the client-facing record.

How should recipients be told about a dual-report correction?

Send a separate notice for each affected client and report. State the report identification and issue details, the affected sections and corrected-version link or delivery method, and whether any client action should change.

Do not call the issue a data error if the source values were correct and the problem was the lineage map. Say what happened in plain terms: the report was linked to the wrong evidence chain during review.

If a client acted on an affected conclusion, put that action first in the notice. State whether to pause it, reverse it or reconsider it. If no action is required, say that directly.

Keep the internal incident ledger more detailed than the client notice. Clients need the impact and correction. The internal record needs hashes and transformation versions, plus review notes and recipient delivery proof.

• What changed: name the affected conclusion or figure, or the recommendation.
• What did not change: name any conclusions that passed recertification.
• What happens next: provide the corrected report or the expected reissue date.
• Who to contact: name the accountable person for questions.

How can you stop a source-lineage swap from recurring?

Make the lineage map a release artifact, not a working note. The report cannot pass review until its source extracts and transformation versions, plus output hashes and approvers are attached to the report ID.

Require a two-sided check before issue. One reviewer traces from the report backward to sources. Another traces from the preserved source extracts forward to the output. The paths must meet on the same transformation identifiers and hashes.

Use immutable report IDs and client-period keys in filenames and extract manifests, together with transformation outputs and delivery records. A human-readable name helps operators. A unique identifier helps prevent an artifact from being attached to the wrong report.

Do a post-issue spot check on the first release after changing the process. The goal is to verify the release control, not to create a false sense of certainty from a checklist.