How to Compare Claims and Supporting Evidence in LinkedIn Posts

Collect Public Post Data

Copy up to three known public post URLs directly into `startUrls` inside the LinkedIn Post Text and Engagement Metrics Data Task hosted on the LinkedIn Post Actor. Replace the entire existing example list manually. The Task accepts copied post links. It does not support keyword discovery, a full account archive, a browser extension, or a Google Docs integration.

Save the untouched source copy and track dataset outcomes separately from your analysis table. Keep any unavailable post text pending until you inspect it. One successful run does not prove all media or video transcripts are available. The Actor collects post data; it does not verify linked studies, check image evidence, validate spoken words, or write new content.

Each dataset row contains exact output fields: `inputUrl`, `url`, `postUrn`, `activityId`, `ugcPostId`, `authorUrl`, `authorName`, `text`, `headline`, `publishedAt`, `observedAt`, `captionUrl`, `transcript`, `status`, and `statusReason`. Missing values remain unknown. The `publishedAt` field may derive from public source metadata or an `activityId`. It is not guaranteed to be the author's exact original publication time. Keep `publishedAt` separate from `observedAt`, which records the exact collection time.

Eight Method Steps

1. Define the content decision: choose your reader problem and select known public reference posts for that problem, rather than collect a whole account.
2. Copy each post's exact URL into the Task. Save the source rows and outcomes. Keep unavailable text out of the comparison until checked. Preserve an untouched source copy and a separate analysis table.
3. Read each post. State its main claim in your own words. Save the claim's source passage in your private notes. Identify the audience, stated condition, and promised action. Do not treat an engagement count as proof of the claim.
4. Classify its support: worked example, linked primary source, personal experience, demonstration, assertion only, or unreviewed support. A personal story can illustrate a possibility; it cannot alone prove a universal result. A link is not checked evidence until you inspect the relevant source passage.
5. Review conditions and counterexamples. Does the claim apply only to a specific tool, sample, organization, or time? Is the key condition in the post or only in the linked source? Keep any visual evidence pending until actually inspected.
6. Make a cross-post matrix: post key, main claim, support type, condition, missing support, original question you can answer. Compare patterns of reasoning, not only wording or layout. Several repeated assertions are still assertions; do not count them as independent confirmation.
7. Choose an original angle from an actual evidence gap you can resolve with your own checked example or source. Write a short argument outline: proposed claim, known condition, support you have, counterexample to address, reader action. Do not copy a reference post's unsupported promise or produce a derivative post automatically.
8. Save the completed matrix and the reason for the chosen outline. Content drafting is a separate reader action. A reference sample can teach structure without being a representative survey of all LinkedIn content.

Worked Example of Claims and Support

All post identities and text are invented fictional examples. A reader wants to explain safer spreadsheet imports to a small team.

Claim and Support Matrix

Fictional Original Evidence Rows

Consider these four fictional evidence rows:

• Row one: O10, line one, item A
• Row two: O10, line one, item A copied import
• Row three: O11, line one, item A
• Row four: missing-order, line one, item A

Four rows contain one confirmed copied-key pair between row one and row two. Row three is distinct despite the same item. The last row has an unresolved key. Remove one confirmed import copy only after the source-key and value check. Preserve O10 original, O11, and the unresolved row as three retained observations. Do not call the unresolved row a unique order or a duplicate. The point is the checked argument's condition, not a second full deduplication tutorial.

Five-Part Original Argument Outline

1. Proposed claim: use checked keys for automatic duplicate handling and keep missing-key rows for manual review.
2. Known condition: keys must identify the intended order line.
3. Available support: the reader's own fictional worked example rows.
4. Counterexample to address: two same-looking items can be two separate orders.
5. Reader action: keep a separate unresolved ledger.

Support types change your writing choices. P2 provides an explicit condition that is useful. P1 offers a broad rule that needs repair. P3 cannot support a quantitative promise.