What the statute says
IRC Section 41(d)(1)(B)(i) sets the hard-science requirement.
The activity must fundamentally rely on principles of the physical or biological sciences, engineering, or computer science. The statute is exclusionary by design: anything that does not rest on those disciplines is out, no matter how creative or how much labor went into it.
Social sciences, arts, humanities, and pure economic or pricing analysis are explicitly excluded. So is research conducted to improve management practices or to gather marketing intelligence.
For software companies the discipline is almost always computer science. The work then needs to draw on one or more recognizable subdomains.
Computer-science subdomains the binder typically cites
Naming the subdomain shows the activity is technological, not anecdotal. The list below is the set of subdomains R&D Binder maps SaaS commit clusters into.
Distributed systems. Consensus, replication, partitioning, consistency models (linearizable, sequential, eventual), failure-detection, leader election. Any service that scales out across multiple nodes is operating in this subdomain.
Information retrieval and search. Inverted indexes, ranking functions (BM25, learning-to-rank), query expansion, semantic embeddings, vector search. Most product-search features pull from this subdomain.
Machine learning and NLP. Model training, fine-tuning, retrieval-augmented generation, prompt engineering, evaluation harnesses. Increasingly common in SaaS feature work.
Compilers and language processing. Lexing, parsing, type systems, code generation. Custom DSLs, query languages, and templating engines fall here.
Cryptography and authentication. Key exchange, symmetric and asymmetric encryption, OAuth, OIDC, JWT issuance, password hashing schemes. SaaS auth work is heavy in this subdomain.
Concurrency and parallel processing. Lock-free data structures, async runtimes, work-stealing schedulers, actor models. Backend job processors and real-time systems live here.
Operating systems and networking. Process supervision, TCP and HTTP tuning, custom protocols, container orchestration internals. Infrastructure work that touches the platform layer.
Software engineering as a discipline. Test architecture, fault-injection, formal-method-adjacent design (property testing, model checking). Recognized as a CS subdomain under the modern reading of Section 41.
What 'evidence of principles applied' looks like
Auditors want to see the specific algorithm, data structure, or protocol named with rationale, not 'we wrote code.'
Strong signal: a design doc, ADR, or PR description that names the algorithm (e.g., 'we evaluated Raft against multi-leader replication and chose Raft for the consistency guarantee'). The binder cites the specific document and the SHA.
Weak signal: commit messages that only describe what was done (e.g., 'add retry logic'). The binder will flag these as low-evidence and pair them with a stronger artifact if one exists.
If no artifact exists, the binder asks the engineering lead to add a brief retroactive 'why' note. Contemporaneous documentation is the standard an examiner expects; near-contemporaneous reconstruction with named authors is a weaker but acceptable position for the first binder.
The other three parts of the four-part test
Every claimed business component has to satisfy all four parts. Each part has its own page:
← Previous: Permitted Purpose Next: Elimination of Uncertainty →
Get documentation built to survive an exam
R&D Binder cites the specific computer-science subdomain (distributed systems, IR, NLP, compilers, etc.) and the principles applied per business component. Auditors get the technical grounding they need without you re-explaining.