Design documents, release notes, internal training material, project assignments and performance records that show the specialist's knowledge of the company's own system, together with a letter explaining why that knowledge is required at the U.S. site.
Let the company's own archive make the case
Hypothetical example: the telematics company keeps its architecture wiki, ticket history and firmware changelogs on internal systems. Export the pages the specialist wrote or maintained, the tickets they resolved on the pipeline, the internal courses they delivered to other staff, and any patents or trade-secret registers. Add a letter from the engineering director that ties each document to a task in the U.S. deployment plan. Include the customer agreement showing that the company assigns and supervises the work, the ownership chart linking the entities, and payroll for the qualifying year. Redact genuine trade secrets where necessary but keep enough to show the knowledge is real. Translate any French-language material with a certified English translation. Records that describe general programming skill or standard cloud tooling do not help and can dilute the file.
Hypothetical example: a forest-inventory software analyst has internal screenshots but no records explaining the system's unusual features. Build a document set that includes an accessible technical overview, training history, access permissions, peer comparisons, foreign payroll, and a U.S. project plan tying the knowledge to named tasks. The company’s product documentation usually settles what is proprietary; the employee’s training and work products settle personal familiarity with it. Redact sensitive customer data where necessary, but do not redact the explanation into meaninglessness. Sequence the review by first proving the organizational system, then the worker's advanced knowledge, then the U.S. need. That order prevents a pile of confidential files from becoming an unsupported assertion.