Evidence Building
Documenting Software Tools as O-1A Original Contribution Evidence
Researchers who have developed software tools used across their field can build a strong O-1A original contributions argument — but only if the petition translates adoption and impact into terms that satisfy the major significance standard. Here is how to assemble that evidence.
The original contributions criterion and software tools
The original contributions criterion under 8 C.F.R. § 214.2(o)(3)(iii)(5) requires evidence of original scientific, scholarly, or business-related contributions of major significance in the field. For researchers and scientists who have developed software tools — computational pipelines, analysis packages, simulation frameworks, or data processing libraries — this criterion is frequently the strongest available, but also the most commonly underdeveloped in the petition. The challenge is that software tool development does not always produce the citation footprint of a peer-reviewed article, does not fit neatly into the awards or memberships criteria, and requires the petition to make an explicit argument about the tool's impact that would be unnecessary for a traditional publication.
USCIS adjudicators evaluating original contributions claims for software tools are typically not specialists in computer science, bioinformatics, or the specific scientific domain in which the tool was developed. The petition cannot assume the adjudicator will independently recognize the significance of a widely-used package in a specialized field. What the adjudicator can evaluate is the evidence assembled to support the claim: download statistics, user communities, citations to the tool's publication or documentation, adoption by research groups at named institutions, incorporation into commercial or governmental workflows, and expert declarations explaining why the tool's contribution to the field is significant. Each piece of that evidence addresses a different aspect of the major significance standard.
Software tools that have become standard infrastructure in a research community — tools that other researchers cannot easily conduct their work without — represent the strongest case for original contributions evidence. Tools that are used but could be easily replaced, or that solve problems previously addressed by other tools in the same way, present a weaker argument for major significance. The petition's job is to locate the tool on this spectrum by providing evidence of adoption, impact, and relative irreplaceability, and to do so with documentary evidence that goes beyond the petitioner's own characterization of the tool's importance.
What the regulation requires for software tool contributions
The regulatory language original scientific, scholarly, or business-related contributions of major significance has three operative components. Original means the contribution must be novel — not an incremental improvement on existing tools without a meaningful advance in capability, methodology, or accessibility. Contributions in the regulation's broader framing benefits from showing a pattern of original contribution rather than a single tool in isolation. Major significance is the most demanding component: it requires evidence that the contribution has had a real, measurable effect on the field — not just that it was published or released, but that other researchers have actually used it and that the field has benefited from its availability.
USCIS policy memos and AAO decisions have consistently interpreted major significance to require evidence beyond the mere assertion that the contribution is important. The core requirement from AAO decisions on original contributions is that the evidence must show the field has recognized the significance of the contributions, not just that the petitioner considers the work significant. For software tools, that recognition can take several forms: citation of the tool in peer-reviewed literature, adoption by research groups that publish using the tool, inclusion in curated resource lists maintained by professional organizations, and expert testimony from credible researchers who use the tool and can explain why it is important.
One practical implication of the major significance standard is that download counts alone, while useful as supporting evidence, are insufficient. Downloads show that people have retrieved the tool; they do not show that researchers use it actively, that it has replaced or improved on previous approaches, or that the field's work is meaningfully different because the tool exists. A tool with 10,000 downloads and a dozen published papers from independent research groups that rely on it as part of their methodology provides stronger evidence of major significance than a tool with 100,000 downloads and no follow-on publications. The petition should prioritize evidence of active, substantive use over aggregate access metrics.
Evidence that software tool contributions support effectively
Papers that cite the tool or its documentation are the most directly analogous to citation evidence for traditional scholarly articles. When a research group publishes a paper describing a methodology that relies on the petitioner's tool, that paper is evidence the tool has been adopted in the field and is considered sufficiently reliable and useful for independent researchers to build scientific work on it. The petition should include a list of papers that cite the tool, organized to highlight the most significant citing papers — those published in high-impact journals, those from well-known research groups, and those that relied on the tool for their primary methodology rather than as an ancillary component.
For tools that have been incorporated into broader software ecosystems — integrated into established platforms used by the research community, or adopted as dependencies by other widely-used packages — documentation of that integration is strong original contribution evidence. When a major platform, consortium, or governmental agency has incorporated a researcher's tool into their infrastructure, that adoption decision reflects an institutional judgment that the tool meets a standard of quality and utility warranting integration. Letters from the technical leads of those platforms or agencies, describing the tool's role and why it was selected, are particularly effective supporting evidence.
User community metrics, when appropriately contextualized, can support the original contributions argument. Package repositories — PyPI, CRAN, Bioconductor, GitHub — typically publish download statistics that can be compared to other tools in the same category. If the petitioner's tool has significantly more downloads than comparable tools, or has accumulated a large number of stars or forks relative to the field, those metrics are relevant indicators of adoption. The petition should present these metrics with context — what the distribution of download counts looks like for similar tools in the field — so the adjudicator can evaluate whether the numbers are exceptional or ordinary for that research ecosystem.
Evidence USCIS regularly discounts in software tool submissions
USCIS regularly discounts evidence of software tool development when the petition does not distinguish between use and significant impact. A tool that has been downloaded thousands of times but where the petition provides no evidence of how it is actually used, or what research it has enabled, fails to establish major significance. Similarly, a tool used within the petitioner's own research group and by close collaborators — rather than by genuinely independent researchers who adopted it based on its merits in the field — does not demonstrate the kind of broad field-level recognition that the major significance standard requires. The petition must show that the tool's adoption extends beyond the petitioner's own professional network.
README files, GitHub repository descriptions, and the petitioner's own descriptions of the tool's capabilities and importance are generally not given significant weight as original contribution evidence. These materials are self-authored and their claims are not independently verified. What matters is third-party recognition: citations in peer-reviewed literature, adoption by independent research groups, institutional integration, and expert assessments from credible witnesses who have no personal stake in the petitioner's application. A petition that provides extensive documentation of what the tool can do — technical documentation, performance benchmarks, feature descriptions — without corresponding evidence of how the field has responded to the tool is misallocating its evidentiary resources.
Evidence of recognition confined to a single institution or research community closely affiliated with the petitioner receives limited weight. If the only researchers who have adopted the tool are former supervisors, graduate students, or members of a consortium the petitioner co-founded, the adoption pattern is ambiguous — it may reflect collaborative infrastructure rather than independent peer recognition. The petition should specifically highlight adoptions by researchers who have no prior direct relationship with the petitioner, who learned about the tool through publication or professional channels rather than through personal connection, and who chose to use it because it was the best available solution for their research needs.
Presenting borderline software tool evidence
For tools with moderate adoption — used by dozens of independent research groups rather than hundreds, cited in a meaningful number of papers but not widely — the most effective strategy is to combine evidence of adoption with expert testimony contextualizing the tool's significance within the specific research ecosystem. An expert who can describe how this tool has become one of the standard options for researchers doing a particular type of analysis, and that researchers in the field routinely choose between these options based on specific workflow needs, is positioning the tool as part of the field's infrastructure without overstating its dominance. That contextual claim, corroborated by adoption documentation, may be sufficient to establish major significance.
Where the tool's adoption is limited but the technical contribution is genuinely novel — where it introduced a methodological advance not available before — the petition can frame the original contributions argument around the novelty and rigor of the underlying approach rather than the breadth of adoption. Expert testimony from researchers who can evaluate the tool's technical innovation, and who can explain why the approach is methodologically significant even if the tool has not yet been widely adopted, supports a forward-looking argument: not that the tool has already transformed the field, but that it represents a contribution of the kind that leading researchers recognize as important.
A tool with limited external adoption but that has been used as the basis for an important publication — a paper that introduced the methodology the tool implements and that has itself been cited significantly — can present the original contribution argument through the publication rather than through the tool's independent adoption. In this structure, the publication is the primary original contribution evidence, and the tool is presented as the mechanism by which the methodology was made available to the community and subsequently adopted. Tool download statistics then become secondary corroborating evidence rather than the primary demonstration of major significance.
Building and auditing your software contribution file
The documentary foundation for an original contributions argument based on software tool development typically includes: a publication or technical report describing the tool, preferably in a peer-reviewed venue; a citation report showing papers that cite the tool or its associated publications; download statistics from package repositories accessed over a meaningful time period and compared to comparable tools in the same category; evidence of institutional or platform adoption, such as letters from technical leads or records of integration into named platforms; and expert declarations from credible researchers who use the tool and can speak to its significance. The petition should present these materials in an organized exhibit structure with clear cross-referencing to the cover letter's narrative.
The self-audit question for software tool evidence is whether the documentation demonstrates that independent researchers — researchers with no prior relationship with the petitioner — have chosen to rely on this tool for their own research because it was the best available solution. If the adoption evidence is largely confined to the petitioner's own institution, collaborators, or supervised students, the evidence does not clearly establish major significance at the field level. The audit should specifically look for citing papers from institutions with no prior affiliation with the petitioner and expert letters from researchers the petitioner did not personally recruit to write on their behalf.
Before submission, confirm that the publication describing the tool — if one exists — is correctly characterized in the petition, that its venue is properly identified as peer-reviewed or otherwise, and that the citation count attributed to it is accurate and sourced from a recognized database. If the tool has not been formally published in a peer-reviewed venue, the petition must rely more heavily on adoption evidence and expert testimony, and the cover letter should address directly why the tool's impact constitutes a major original contribution notwithstanding the absence of a peer-reviewed publication specifically describing it. Addressing that gap proactively is preferable to receiving an RFE asking the petitioner to explain it.
What we typically gather for this kind of case
| Document | Where to source | Why it matters |
|---|---|---|
| Peer-reviewed publications | Web of Science / Scopus exports | Anchors original-contributions and authorship criteria |
| Citation analysis | Google Scholar profile + ESI top-1% data | Quantifies major significance in the field |
| Salary benchmark | BLS OEWS for SOC code + locality | Documents high-salary criterion at 90th-percentile or above |
| Critical-role letters | Direct supervisor + program director | Establishes role's importance, not just title |
What we see go wrong, again and again
- 01Treating extraordinary ability as a credentials checklist rather than a story of field-wide impact.
- 02Submitting bibliometric data (h-index, citation counts) without explaining what makes those numbers high relative to peers in the same sub-field.
- 03Relying on letters from collaborators or co-authors rather than independent experts who can speak to influence.