IRC Section 41(d)(1)(B)(ii) and Section 41(d)(3) define the permitted-purpose test.
The research must be undertaken to develop or improve a business component. A business component is a product, process, computer software, technique, formula, or invention that the company holds for sale, lease, license, or use in its own trade or business.
The improvement must relate to one or more of four qualifying dimensions: function, performance, reliability, or quality. Style, taste, cosmetic appeal, and seasonal design changes do not qualify, even if they took significant engineering time.
The work has to be at the business-component level. Generic 'platform improvements' or 'we made the app better' will not survive an exam. Auditors expect named components with observable boundaries.
Each dimension has a recognizable signature in commit history. The binder cites the specific signatures.
Function. The component does something it did not do before, or does something materially different. Adding a new authentication flow, a new file-export format, a new webhook event type, a new query language - these are function improvements as long as they are not cosmetic surface treatments of existing function.
Performance. Measurable speed, throughput, latency, or resource-efficiency improvement. Cutting p95 API response time from 800ms to 200ms, doubling background-job throughput, halving cloud spend per request - all are performance improvements with benchmark evidence.
Reliability. Reducing failure rate, improving uptime, hardening against partial outages, recovering gracefully from upstream errors. The evidence is typically incident post-mortems plus the commits that closed out the root cause.
Quality. The trickiest dimension. Quality means improvement to the technical output of the component itself: more accurate search results, more correct invoice rendering, lower false-positive rate on a fraud-detection model. It does NOT mean visual polish or copy refinement.
Style, taste, and seasonal design changes are explicitly out. So is internal-use software absent a high-threshold-of-innovation showing.
An auditor's first question is what the component is. Vague answers lose credibility before the technical merits are reviewed.
Strong: 'OAuth2 device-flow authentication service for our mobile clients, v1.0 through v1.4, MIT-licensed integration with the Auth0 SDK, owned by the platform team, released February through August 2026.' Specific scope, observable boundary, named owner.
Weak: 'The platform.' That is the entire company. An auditor will ask which part, which team, which calendar period - and if the answer is 'all of it,' the binder fails the permitted-purpose test on Day 1.
The binder always names components with version range, scope, and owner. If a commit cluster cannot be named that way, it does not cluster.
Every claimed business component has to satisfy all four parts. Each part has its own page:
R&D Binder maps every commit cluster to a named business component and one or more qualifying dimensions, with PR-number evidence. Your CPA sees the mapping; your auditor sees the trail.