KASPR IDENTIFIER HANDOFF EXERCISE / 13 OCTOBER 2026
All 14 records are fictional, synthetic and DO NOT CONTACT. Do not upload the exercise to Kaspr, LinkedIn, a CRM or any other vendor. No account, extraction, enrichment or import was run.

Purpose: distinguish route-compatible person identifiers from source membership and contact-data usefulness. This is a local teaching acceptance exercise, not a Kaspr acceptance guarantee or a contact-data yield benchmark.

Files:
1. kaspr-handoff-synthetic-raw.csv: 14 original observations, never overwritten.
2. kaspr-handoff-synthetic-decisions.csv: all original cells plus explicit disposition, accepted_public_url and reason.
3. kaspr-handoff-synthetic-accepted.csv: K01, K02 and K09, with original cells retained.
4. kaspr-handoff-synthetic-held.csv: K03, K04, K05, K07, K08, K10, K13, K14.
5. kaspr-handoff-synthetic-omitted.csv: K06 and K11 rejected for this route; K12 omitted as K01's repeat. Original records stay available.
6. kaspr-handoff-synthetic-thin-payload.csv: three teaching columns, three accepted exercise rows. request_ref explicitly marks every row synthetic/do not contact. These are our demonstration headers, not an asserted Kaspr or Leadsforlinked export schema. Recheck destination field mapping; support for retaining arbitrary request_ref was not live tested.
7. kaspr-handoff-requirements-worksheet.csv: blank real-evidence fields. Replace example prompts with your own requirements and record actual checks.
8. kaspr-handoff-workbench-keys-expected.csv: exact expected keys returned by the unchanged local LeadWorkbench.normalizeLinkedInProfileURL function for each raw identifier, plus the separate manual CSV-route disposition. Replay checks the production module directly; no workbench change or vendor eligibility test is implied.

Exercise rules:
Require a confirmed standard HTTPS www.linkedin.com/in/ person identifier. ACw opaque identifiers, blank values and unconfirmed formatting repairs stay held. Do not rewrite Sales Navigator identifiers. K02's separate URL is supplied by fictional source review. K09's separate canonical URL is independently confirmed within the fictional exercise; its raw tracking URL is retained. This exercise is deliberately stricter than mere URL syntax.
Conflicting observed names for the same accepted candidate URL hold both observations (K07/K08). A repeat of the same confirmed person/name (K12) is omitted from the payload, while its original row remains in the ledger. Other-host and company URLs are rejected for this person route.

Expected local results: 3 accepted, 8 held, 2 rejected for this route, 1 repeated observation omitted. These are authored practice outcomes, not real coverage or conversion rates. No row contains a found or verified email or phone. Accepted identifiers do not satisfy a mandatory email/phone brief by themselves.

Generic matching is not provider CSV eligibility. The unchanged local workbench returns a matching key for K04's /in/ACw opaque identifier, while Kaspr's documented CSV route excludes that form. It also normalizes K10 and K13 for matching, although this manual exercise holds them without separate identity confirmation. K02's raw SalesNav string yields no generic key, while its separately confirmed public identity can enter this exercise's thin payload. Keep these decisions separate; do not modify the workbench to encode one provider's requirements.

For real work: keep source files and provenance separately; inspect the actual exported column names; verify the receiving tool's current mapping/entitlement; resolve identities with source evidence; review required contact data after enrichment; retain held/conflicting observations; hand over only the separately approved payload.