Demystifying 'Original Contributions' for Devs: How to Prove Your Code Changed the Industry

A researcher claiming this criterion points at published papers and a citation count. What do you point at?

Your best work is a pull request merged into a framework millions of people use without knowing your name. Or an internal architecture that quietly carries a company's whole product. Nothing about it looks like the academic evidence USCIS sees every day, and that mismatch is why "original contributions of major significance" is the criterion where software engineer petitions most often bleed out.

It's also, when built correctly, the backbone of a tech EB-1A. The evidence exists, sitting in your dependency graphs, deployment metrics, and design docs.

The work is translation: turning engineering artifacts into the specific kind of proof an immigration officer is trained to credit. That translation is this article.

What the Regulation Actually Asks

The regulatory language is one sentence: evidence of your "original scientific, scholarly, artistic, athletic, or business-related contributions of major significance in the field."

Read it as two separate tests, because officers do.

Test one: original. You made something new - an algorithm, an architecture, a technique, a tool. Not competent execution of known patterns, but something that didn't exist before you.

Test two: major significance in the field. The field changed because of it. Not your team, not your employer. The field.

The most common way this criterion dies is passing test one and failing test two. The officer agrees the work is original, then writes the sentence every RFE response attorney knows by heart: the petitioner has not established that the contribution rises to the level of major significance in the field as a whole. Your company benefiting is expected. Your industry adopting is evidence.

There's a second layer. Under the Kazarian framework that governs EB-1A adjudication, meeting three criteria is only step one; step two is a final merits determination asking whether the whole record shows sustained acclaim and standing in the small percentage at the top of the field. Your original contributions evidence does double duty, so building it properly pays twice.

And the climate matters. Case-tracking data reported by immigration firms put EB-1A RFE rates near half of filings in early 2026, with approval rates that dipped into the low 30s percent in late 2025 before recovering into the 40s. Practitioners report that tech petitions draw elevated scrutiny precisely because so many arrive looking identical: a few papers, a judging stint, a high salary, and generic letters. A genuinely built original-contributions section is how a petition stops looking like a template.

The Translation Problem

Here's a line from a typical engineering resume: "Optimized service latency by 40% through a novel caching layer."

To you, that sentence is impressive. To an adjudicator, it's unusable. It has no scale (40% of what, affecting whom?), no field impact (did anyone outside your employer change how they work?), and no verification (says who?).

Every claim in this criterion needs four components, and most engineer-written drafts have one:

1. The artifact. What exactly did you create? Name it, date it, document it.
2. The originality proof. What existed before, and what did you do that was new? Patents help here; so do design docs, talks, and publications that timestamp the idea.
3. The adoption proof. Who uses it now, outside your direct orbit? Numbers, names, and dates.
4. The field-impact proof. What do practitioners do differently because this exists? This is the "major significance" half, and it's the one that decides the criterion.

Keep that four-part structure in mind as we walk the two hardest evidence sources: open source and internal systems.

Open Source: Stars Are Attention, Not Impact

GitHub stars are the first thing every engineer reaches for and the weakest thing in the stack. A star is a bookmark. Officers have seen starred repositories with zero production users, and practitioners report denials noting exactly that gap: popularity metrics without documented downstream use.

Build the evidence as a ladder, where each rung is harder to dismiss than the last:

Rung 1 - usage volume. Package downloads over time (npm, PyPI, crates, Maven), with a chart, not a screenshot of one number. Sustained or growing curves matter because the final merits step cares about "sustained".

Rung 2 - the dependency graph. Projects that depend on yours, especially named, recognizable ones. A framework used by other frameworks is field-level infrastructure by definition.

Rung 3 - named adopters. Companies or major projects that use your work in production. Engineering blog mentions, conference talks by other companies referencing your tool, changelogs that credit it, migration guides written by strangers.

Rung 4 - independent commentary. Coverage in industry publications, newsletters, podcasts, or widely read technical blogs written by people you've never met. This doubles as evidence for the published-material criterion, and its absence is one of the most commonly cited RFE gaps.

Rung 5 - letters from adopting engineers. A staff engineer at an unrelated company explaining, in specific terms, what your library replaced and what it would cost them to lose it. One of these outweighs five letters from colleagues.

One honest boundary: a handful of merged PRs into a famous project is participation, not contribution of major significance. What moves the needle is being the author or maintainer of a distinct, attributable piece of work - a subsystem, a feature the release notes highlight, a library - that the field then leaned on.

Internal Systems: The Confidentiality Playbook

The other classic dev situation: your most significant work is proprietary. The architecture you designed processes billions of events a day, but there's no repository to point at and an NDA between you and the evidence.

Proprietary doesn't mean unprovable. It means the proof arrives through different doors:

Quantified business impact, in writing. A letter from someone with visibility into the numbers - a director, a finance partner - stating what the system carries and what it changed: transaction volumes, cost reductions, revenue enabled, incidents eliminated. Officers can't see your code, but they can credit sworn statements with specific figures.

The patent path. If the architecture contains something genuinely novel, a granted patent is independent, government-examined proof of originality - test one, solved by a third party. Then adoption evidence carries test two: a patent that's licensed or implemented in shipping products speaks to significance; a certificate alone does not.

The public shadow of private work. Most serious systems cast one: the engineering blog post about the architecture, the conference talk, the paper at an industry venue, the framework your team open-sourced as a byproduct. If your work has no public shadow yet, creating one is legitimate record-building - a talk proposal costs nothing and timestamps everything.

Derivative adoption. When other companies build systems visibly patterned on your published design, that's field impact. Letters from engineers elsewhere saying "we modeled our pipeline on the approach described in their talk" convert an internal project into an industry contribution.

The Jargon-to-Impact Translation Table

Officers are not engineers, and the petition that makes them do the translation loses. Do it for them, in exactly this direction:

The pattern in every row: number, scale, named external validation, and what the field did next. Write the claim so a reader with no technical background can repeat why it mattered.

Expert Letters: The Structure That Survives

Letters carry this criterion, and letters are where 2026-level scrutiny bites hardest. Practitioners report RFEs and denials specifically calling out letters that are heavy on praise and light on data, that come mostly from insiders, or that assert "major significance" without pointing to independent uptake. Officers also notice when three letters share sentence structures, because template letters read like exactly what they are.

A letter that works runs about one and a half to two and a half pages and does five jobs in order:

1. Establishes the writer. Role, institution, years in the field, recognitions - one paragraph on why this person's judgment about the field carries weight.
2. Establishes independence and knowledge. How they came to know your work, not you. "I have never worked with the petitioner; I encountered their system when my team evaluated it in 2024" is a credibility sentence officers look for.
3. Describes the contribution precisely. What you built, what problem it addressed, what existed before. Specific, dated, technical enough to be real, plain enough to be readable.
4. Proves the significance with checkable facts. What changed in the field: adoption they witnessed, numbers they can attest to, what their own organization did differently. This paragraph is the letter.
5. Connects to the standard. Why, in the writer's expert view, this constitutes an original contribution of major significance to the field - in their words, not a lawyer's boilerplate.

On the mix: aim for five to eight letters total across your petition, with at least half from genuinely independent experts - people who never employed you, never co-authored with you, and can say so. Your manager's letter isn't worthless; it's just evidence of employment, not of field impact. The letter from the engineer who adopted your work at a company you've never entered is the one that proves the field noticed.

Don't Win the Criterion and Lose the Case

One more structural point, because it catches strong engineers. Satisfying this criterion is part of step one - you still need three criteria total, and then the whole record faces the final merits determination: does the evidence, taken together, place you in the small percentage at the top of the field with sustained recognition?

This is why the same contribution should be built to feed multiple criteria: the independent blog coverage supports published material, the conference invitations support your speaking record, the adoption metrics support original contributions, and all of it together tells one sustained story. A petition that treats each criterion as a separate bucket of exhibits reads like a checklist. A petition where every exhibit reinforces the same narrative - this person's work changed how the field does X - is what survives step two.

If your record today is thinner than this article assumes, that's a planning input, not a verdict. Publishing the internal work, proposing the talks, and open-sourcing the reusable pieces over the next year is how genuine records get built, and your priority date can wait for evidence that's actually ready. Given what an RFE costs in time and odds, filing six months later with a real adoption story usually beats filing now with stars and hope.

There's also a nearer-term door: the EB-2 NIW self-petition asks for a nationally important endeavor and good positioning rather than top-of-field acclaim, and the evidence you're building for this criterion is exactly what its "well positioned" prong wants. Many engineers file NIW now, lock a priority date, and return to EB-1A when the record matures.

FAQ

Bottom Line

The original contributions criterion is two tests wearing one sentence: prove the work was new, then prove the field changed because of it. Engineers lose it by submitting attention metrics where adoption evidence belongs, by letting company impact stand in for field impact, and by filing letters that praise instead of attest. All three failures are fixable, and in a year when roughly half of EB-1A filings draw an RFE, fixing them before filing is the whole game.

Build every claim with the four parts - artifact, originality, adoption, field impact - translate the engineering into numbers a non-engineer can repeat, and spend your letter capital on independent experts with checkable facts. Then pressure-test the assembled record with an attorney who files EB-1As regularly; that review is cheap compared to an RFE. If you want a structured way to inventory all of it first, the petition prep template walks through this criterion evidence block by evidence block, alongside the other nine.

And if you're still weighing whether EB-1A is your fastest lane at all, the comparison tool runs it against NIW, PERM, and every other pathway for your country and situation with current data.