Proof, Not Adjectives: A Senior Engineer’s L-1B, Approved After RFE
Proof, Not Adjectives: A Senior Engineer’s L-1B, Approved After RFE
An L-1B approval for a senior software engineer transferring from a European parent company to its United States subsidiary. The RFE questioned all three specialized knowledge requirements and said, in effect, that the original support letter described a capable engineer using company tools, not someone with knowledge that was special or advanced. We answered with the company's own records: design documents, version control history, a named engineer by engineer comparison, and a measured timeline of how long the knowledge actually took to acquire. Approved in under four weeks.
An L-1B approval for a senior software engineer transferring from a European parent company to its United States subsidiary. The RFE questioned all three specialized knowledge requirements and said, in effect, that the original support letter described a capable engineer using company tools, not someone with knowledge that was special or advanced. We answered with the company's own records: design documents, version control history, a named engineer by engineer comparison, and a measured timeline of how long the knowledge actually took to acquire. Approved in under four weeks.
November 03, 2026
November 03, 2026
Petition Type | Processing | Status | Field |
L-1B (Specialized Knowledge) | Premium | Approved after RFE | Event Ticketing Technology |
Case Background
Case Background
The L-1B lets a company transfer an employee from a foreign office to a U.S. office when that employee has specialized knowledge of the company's products, processes or procedures. USCIS looks at three things: whether the person worked abroad in a specialized knowledge role for at least one continuous year, whether the U.S. role requires that knowledge, and whether the person actually holds it. Here is the case:
A senior software engineer with a master's degree in computer science, two U.S. patents from a prior employer, and about eight years of platform engineering before joining the company
At the company for roughly twenty months at filing, where he designed and built three internal systems: the engine that connects the platform to external distribution partners, the central authentication service, and the ticket insurance framework
The U.S. subsidiary had no engineering team. He would be its first engineer, supporting U.S. partners that currently route every technical question overseas
Filed in early July under premium processing. The RFE arrived three weeks later
The L-1B lets a company transfer an employee from a foreign office to a U.S. office when that employee has specialized knowledge of the company's products, processes or procedures. USCIS looks at three things: whether the person worked abroad in a specialized knowledge role for at least one continuous year, whether the U.S. role requires that knowledge, and whether the person actually holds it. Here is the case:
A senior software engineer with a master's degree in computer science, two U.S. patents from a prior employer, and about eight years of platform engineering before joining the company
At the company for roughly twenty months at filing, where he designed and built three internal systems: the engine that connects the platform to external distribution partners, the central authentication service, and the ticket insurance framework
The U.S. subsidiary had no engineering team. He would be its first engineer, supporting U.S. partners that currently route every technical question overseas
Filed in early July under premium processing. The RFE arrived three weeks later
What the RFE Said
What the RFE Said
The RFE did not dispute the employment, the corporate relationship, or the one year abroad. It went after the knowledge itself, from three directions:
Using tools is not the same as having specialized knowledge. It said the record showed hands on experience with the company's tools and methodologies, but not that he was responsible for designing or developing them. It assumed those tools were built by other people and used widely across the organization.
The support letter asserted, but did not prove. It quoted the original letter's line about his in-depth understanding of proprietary architecture, internal APIs and authentication frameworks, and said no corroborating documentation backed it up.
No comparison, no timeline. It asked four concrete questions: what the knowledge is, the minimum time required to obtain it, how he obtained it, and why the position requires it. It also asked how many people in the organization held equal knowledge, with personnel records to support the answer.
Read plainly, the RFE was saying the filing described a good engineer doing good work, and that is not what the L-1B is for.
The RFE did not dispute the employment, the corporate relationship, or the one year abroad. It went after the knowledge itself, from three directions:
Using tools is not the same as having specialized knowledge. It said the record showed hands on experience with the company's tools and methodologies, but not that he was responsible for designing or developing them. It assumed those tools were built by other people and used widely across the organization.
The support letter asserted, but did not prove. It quoted the original letter's line about his in-depth understanding of proprietary architecture, internal APIs and authentication frameworks, and said no corroborating documentation backed it up.
No comparison, no timeline. It asked four concrete questions: what the knowledge is, the minimum time required to obtain it, how he obtained it, and why the position requires it. It also asked how many people in the organization held equal knowledge, with personnel records to support the answer.
Read plainly, the RFE was saying the filing described a good engineer doing good work, and that is not what the L-1B is for.
Our Strategy
Our Strategy
Define the knowledge once, then answer every question against it. The RFE asked about the same knowledge from three angles. We opened the response by naming the three systems and the specific behaviours inside them that exist only in code, so every later section pointed back to one definition.
Concede what should be conceded. The RFE was right that general software skill is not specialized knowledge, and right that performing well does not prove it. We said so, and built the case on what he acquired at the company on top of that base.
Replace assertion with records. Every claim in the original letter was re-stated with a document behind it: the design specification he wrote, the commit history, the line attribution, the partner correspondence.
Measure instead of describe. Rather than saying the knowledge takes a long time to acquire, we showed exactly how long it took him, from the company's own version control dates.
Answer the suggested items that do not exist. Where the RFE invited training records, curricula or contracts we could not provide, we said why, so the record held an answer rather than a gap.
Define the knowledge once, then answer every question against it. The RFE asked about the same knowledge from three angles. We opened the response by naming the three systems and the specific behaviours inside them that exist only in code, so every later section pointed back to one definition.
Concede what should be conceded. The RFE was right that general software skill is not specialized knowledge, and right that performing well does not prove it. We said so, and built the case on what he acquired at the company on top of that base.
Replace assertion with records. Every claim in the original letter was re-stated with a document behind it: the design specification he wrote, the commit history, the line attribution, the partner correspondence.
Measure instead of describe. Rather than saying the knowledge takes a long time to acquire, we showed exactly how long it took him, from the company's own version control dates.
Answer the suggested items that do not exist. Where the RFE invited training records, curricula or contracts we could not provide, we said why, so the record held an answer rather than a gap.
How We Answered
How We Answered
He Designed the Systems
We started with what he did not build. The distribution engine existed before he joined, and the commit history showed who built it. Then we showed what he did design: six written design specifications across the three systems, each with a version history carrying his name, and the implementation that followed. Version control records showed him as the majority author of the distribution service, the principal author of the authentication service, and the near sole author of the first insurance provider integration. He had added every distribution partner type admitted to the platform since his third month.
Nobody Else Holds This Knowledge
The engineering manager who supervised him, and who had built part of the engine himself, compared him by name to every other engineer with substantial knowledge of any of the three systems. The company turned that into a one page matrix from its own records. Seven engineers held substantial knowledge of at least one system. None of the other six held it in more than one. The two engineers who originally built the distribution engine had moved to other domains and were no longer developing it. In the U.S. entity, there was no engineer at any level. The answer to the RFE's question about how many people held equal knowledge was zero.
How Long It Actually Takes
This was the piece that turned description into proof. From the company's version control dates, we showed that an engineer arriving with a master's degree, two patents and eight years of experience still needed eleven weeks before his first change to the distribution engine, three and a half months before his first independent partner integration, seven months before his first design specification, and eighteen months before a platform wide design. No training, course or manual exists for any of the three systems. That absence, which could have looked like a gap, became evidence: the knowledge can only be gained through experience inside the company, and the record measured how much.
The Foreign Role and the U.S. Role, Duty by Duty
Letters from the engineering manager abroad and the CEO of the U.S. entity each broke the position into duties with a percentage of time on each. Three quarters of the role abroad, and ninety percent of the U.S. role, was work on the three systems or with the partners connecting to them. The general payments and team duties were stated and expressly not claimed as specialized. For the U.S. position, we walked through what admitting a single partner actually involves, step by step, with the partner email threads already in the record showing him doing exactly that.
Commercial Impact
One U.S. pipeline agreement, in the high six figures annually, had been contingent on a partner integration he designed and built. The deal record and the internal announcement crediting him were in the record. Partner launches in the U.S. market, each a distributor type he added, and the monthly transaction volume flowing through the engine showed the knowledge was not academic.
He Designed the Systems
We started with what he did not build. The distribution engine existed before he joined, and the commit history showed who built it. Then we showed what he did design: six written design specifications across the three systems, each with a version history carrying his name, and the implementation that followed. Version control records showed him as the majority author of the distribution service, the principal author of the authentication service, and the near sole author of the first insurance provider integration. He had added every distribution partner type admitted to the platform since his third month.
Nobody Else Holds This Knowledge
The engineering manager who supervised him, and who had built part of the engine himself, compared him by name to every other engineer with substantial knowledge of any of the three systems. The company turned that into a one page matrix from its own records. Seven engineers held substantial knowledge of at least one system. None of the other six held it in more than one. The two engineers who originally built the distribution engine had moved to other domains and were no longer developing it. In the U.S. entity, there was no engineer at any level. The answer to the RFE's question about how many people held equal knowledge was zero.
How Long It Actually Takes
This was the piece that turned description into proof. From the company's version control dates, we showed that an engineer arriving with a master's degree, two patents and eight years of experience still needed eleven weeks before his first change to the distribution engine, three and a half months before his first independent partner integration, seven months before his first design specification, and eighteen months before a platform wide design. No training, course or manual exists for any of the three systems. That absence, which could have looked like a gap, became evidence: the knowledge can only be gained through experience inside the company, and the record measured how much.
The Foreign Role and the U.S. Role, Duty by Duty
Letters from the engineering manager abroad and the CEO of the U.S. entity each broke the position into duties with a percentage of time on each. Three quarters of the role abroad, and ninety percent of the U.S. role, was work on the three systems or with the partners connecting to them. The general payments and team duties were stated and expressly not claimed as specialized. For the U.S. position, we walked through what admitting a single partner actually involves, step by step, with the partner email threads already in the record showing him doing exactly that.
Commercial Impact
One U.S. pipeline agreement, in the high six figures annually, had been contingent on a partner integration he designed and built. The deal record and the internal announcement crediting him were in the record. Partner launches in the U.S. market, each a distributor type he added, and the monthly transaction volume flowing through the engine showed the knowledge was not academic.
The Outcome
The Outcome
Approved, less than four weeks after the response was filed, with no further requests.
L-1B RFEs on specialized knowledge are among the most common in employment immigration, and the reason is almost always the same. The original letter describes the knowledge in adjectives: deep, proprietary, extensive. The officer cannot verify an adjective. What the officer can verify is a design document with a date, a commit log with a name on it, and a manager's comparison that names the other engineers and says what each one knows. Nothing about this engineer's knowledge changed between the filing and the approval. The documentation did.
Approved, less than four weeks after the response was filed, with no further requests.
L-1B RFEs on specialized knowledge are among the most common in employment immigration, and the reason is almost always the same. The original letter describes the knowledge in adjectives: deep, proprietary, extensive. The officer cannot verify an adjective. What the officer can verify is a design document with a date, a commit log with a name on it, and a manager's comparison that names the other engineers and says what each one knows. Nothing about this engineer's knowledge changed between the filing and the approval. The documentation did.
What L-1B Applicants and Employers Can Take From This Case
What L-1B Applicants and Employers Can Take From This Case
Define the knowledge in one place and precisely. If you cannot say what it is in a paragraph, the officer cannot find it in the record.
Separate general skill from company specific knowledge, and claim only the second. Conceding the first makes the second more credible.
Show design and authorship, not use. Design specifications, version histories and line attribution answer the question of who built what better than any letter.
Compare by name. A matrix of who knows which system, prepared from company records, is the comparison the RFE is actually asking for.
Measure the time to acquire the knowledge from real dates, and tie it to the person's credentials. It turns a claim into a number.
Give percentages of time per duty, and say which duties are not specialized. Honesty about the ordinary parts of the role makes the specialized parts stand out.
If training records do not exist, say so and explain why. The absence of training can be evidence that the knowledge is only learned on the job.
Define the knowledge in one place and precisely. If you cannot say what it is in a paragraph, the officer cannot find it in the record.
Separate general skill from company specific knowledge, and claim only the second. Conceding the first makes the second more credible.
Show design and authorship, not use. Design specifications, version histories and line attribution answer the question of who built what better than any letter.
Compare by name. A matrix of who knows which system, prepared from company records, is the comparison the RFE is actually asking for.
Measure the time to acquire the knowledge from real dates, and tie it to the person's credentials. It turns a claim into a number.
Give percentages of time per duty, and say which duties are not specialized. Honesty about the ordinary parts of the role makes the specialized parts stand out.
If training records do not exist, say so and explain why. The absence of training can be evidence that the knowledge is only learned on the job.
Why Employers and Transferees Trust OpenSphere
Why Employers and Transferees Trust OpenSphere
OpenSphere prepares L-1A, L-1B and other employment based cases for companies moving key people into the United States, and for the engineers, managers and specialists they move.
Experience turning a support letter's claims into a documented, corroborated record
RFE responses that answer every question the officer asked, in the order asked, with the exhibit that proves it
Case strategy that concedes the right points so the real argument stands on its own
Whether you are planning an intracompany transfer or holding an RFE that questions whether the knowledge is really specialized, OpenSphere can help you build a record that proves it.
Get your free visa evaluation at opensphere.ai
Note: Client details have been anonymized to protect confidentiality while preserving the essential facts of the case.
OpenSphere prepares L-1A, L-1B and other employment based cases for companies moving key people into the United States, and for the engineers, managers and specialists they move.
Experience turning a support letter's claims into a documented, corroborated record
RFE responses that answer every question the officer asked, in the order asked, with the exhibit that proves it
Case strategy that concedes the right points so the real argument stands on its own
Whether you are planning an intracompany transfer or holding an RFE that questions whether the knowledge is really specialized, OpenSphere can help you build a record that proves it.
Get your free visa evaluation at opensphere.ai
Note: Client details have been anonymized to protect confidentiality while preserving the essential facts of the case.