Two Visible LinkedIn Reposts Swapped Source-Post Links: Reconcile Both Amplification Signals

A source-post swap is an attribution problem, not a cosmetic one. Treat the two reposts as a permutation: repost A should bind to source A, repost B should bind to source B, but the visible evidence indicates A points to B and B points to A.

Do not infer the original pairs from topic similarity alone. Retrieve both repost records and both candidate source-post records. LinkedIn documents post retrieval by post URN and shows that a reshare record exposes its parent and derived root in `reshareContext` LinkedIn Posts API.

Which records form the two original visible pairs?

Create one immutable evidence row per repost before changing anything. The IDs, author, commentary, visible source preview, timestamp, and any dependent action records belong in that row.

The ledger below is a reconciliation template, not evidence that any placeholder ID exists. Replace every bracketed value with data retrieved from the two visible reposts and their candidate source posts.

Which author, claim, comment, qualification, and reporting records must be checked?

Cross-check every record that used either source binding. Start with the repost author, the source author, the repost commentary, the source commentary, the source preview, and the timestamp captured at review. Keep exact text snapshots so the reviewer can distinguish a link error from a later content edit.

Then review the downstream records that may have inherited the wrong source: attribution fields, moderation notes, claims or qualifications tied to the source post, comment records, analytics labels, report rows, and any client-facing summary. Preserve the original IDs and links in the ledger even when a downstream record needs correction.

Do not copy a claim from one source post to the other because the subjects sound similar. A correction should change only the erroneous binding and the records whose attribution depends on it. Mark records with insufficient evidence as unresolved rather than guessing.

• Fetch both repost records by their exact URNs.
• Fetch both candidate source-post records by their exact URNs.
• Compare each repost's `reshareContext.parent` to the expected source-post URN.
• Record every dependent record ID, current attribution, required correction, owner, and verification result.
• Keep a before-and-after export or screenshots where your system permits it.

How do you restore both source bindings safely?

First, freeze automated reporting or downstream updates for these two reposts if they could spread the incorrect attribution. Save a dated evidence snapshot of the current state. Then identify the supported correction route in the system that created or stores the repost relationship.

LinkedIn's documentation shows `reshareContext.parent` as the required relationship when creating a reshare, and describes `root` as a read-only field derived from the parent LinkedIn Posts API. That means the repair target is the parent relationship. Do not attempt to treat the derived root as an independent source binding.

If the platform or your internal system cannot edit an existing relationship, use the approved remediation route for that system. Record whether the correction was an update, replacement, archive-and-recreate action, or escalation. Do not imply that any route is available until the relevant permissions and product behavior are confirmed.

• Correct repost A so its recorded parent is confirmed source A.
• Correct repost B so its recorded parent is confirmed source B.
• Update only the dependent attribution records that point to the wrong source.
• Leave unrelated comments, reporting rows, and historical audit entries intact.
• Require a reviewer to compare the final state against the saved evidence snapshot.

How should each corrected repost be retested?

Test the reposts separately. A successful check for repost A does not prove repost B is correct. Retrieve repost A after its correction and verify its ID, author, commentary, parent, derived root, and visible source preview against the ledger. Repeat the same test for repost B.

Use the reader-visible representation when the issue was detected in a public or shared view. The Posts API documentation says that `READER` is the default retrieval view for the published version, while `AUTHOR` can expose a latest version that has not yet been published LinkedIn Posts API. Record which view was used for every test.

Close the incident only after both rows show the expected parent, the expected source author and content snapshot, and corrected dependent attribution. The reviewer should sign off on each repost independently.

• Retest repost A by exact URN and capture the returned parent and root.
• Retest repost B by exact URN and capture the returned parent and root.
• Open each visible repost and compare its displayed source preview with the ledger.
• Re-run only reports and attribution jobs affected by the two corrected bindings.
• Record test time, runtime, reviewer, result, and any unresolved record IDs.

What should the final reconciliation record contain?

The final record should preserve both the initial swapped state and the corrected state. It should name the two repost IDs, the two source-post IDs, the evidence used to establish each original pair, each dependent record reviewed, each write made, and the independent retest result for each repost.

LinkedIn's legacy UGC Post documentation also describes response context with parent and root fields for response content, while noting that the Posts API replaces the legacy UGC Posts API for creating posts LinkedIn UGC Post API. Keep the API family and URN type with the evidence so a reviewer does not query the wrong record type.