What counts as technological uncertainty for the R&D credit

Of the things that sink a research credit claim under examination, a weak uncertainty narrative is the most common and the most avoidable. It is also the section most people write badly, because the instinct is to describe how hard the project was. Difficulty is not uncertainty. The regulation is specific about what is, and writing to that specification is most of the work.

What the regulation actually says

The operative sentence sits in the section 174 regulations, and it is worth reading slowly:

Three distinct things, not one. Capability — can this be done at all? Method — we know it can be done, but not how. Appropriate design — we know it can be done and roughly how, but not which design achieves it.

The section 41 regulations echo the same framing for qualified research and add the point that the uncertainty has to exist at the outset. Note also the related “substantially all” requirement at § 1.41-4(a)(6): at least 80 percent of the activities, measured on a cost or other consistently applied reasonable basis, must constitute elements of a process of experimentation.

The three categories, concretely

Capability

You do not know whether the thing can be done at all with available technology. This is the strongest form and the easiest to defend, because the record of failure is itself evidence. If you ran out of performance headroom at 48 of a target 64, nobody has to take your word for the uncertainty.

“We did not know whether any available decode path could sustain the required stream count on a single machine.”

Method

You are confident the result is achievable, but not how to achieve it. Several approaches are plausible and the available information does not indicate which will work.

“Pooling hardware sessions across independent presentation surfaces was theoretically possible, but no available documentation addressed whether per-surface context costs would make it viable.”

Appropriate design

The weakest of the three on its own, and the one examiners probe hardest, because it shades into ordinary engineering choice. It holds when genuinely different designs exist and the information available does not establish which is appropriate — not merely which is tidier.

“Three session-allocation architectures were viable; available information did not establish which would degrade gracefully rather than fail abruptly under overload.”

What uncertainty is not

• Not difficulty. “This was a hard problem and took eight months” says nothing about what was unknown. Plenty of hard work involves no uncertainty at all.
• Not commercial or economic risk. Not knowing whether customers will buy it, or whether it can be built profitably, is not technological uncertainty.
• Not uncertainty you resolved by reading. If the answer was in the vendor documentation and you simply had not looked yet, the information was available to you.
• Not discovered mid-project. The test is uncertainty at the beginning of the research activities. Problems that emerged during a routine build are a different thing, and claiming them as founding uncertainties invites the question of what you actually set out to resolve.

Two things that help more than people expect

Both of these are in the regulations and both are routinely overlooked by companies talking themselves out of a legitimate claim.

You do not have to be advancing the state of the art. The research does not need to exceed, expand or refine common knowledge in the field. The question is whether the information available to you established capability, method or design — not whether somebody, somewhere, already knew.

You do not have to succeed. Qualified research does not require that the business component actually be developed or improved. A project that eliminated three approaches and shipped nothing still involved a process of experimentation. In documentation terms, failure is often the better record: an abandoned architecture with measurements attached is harder to dismiss than a success that looks, in hindsight, inevitable.

How to write it down

The format that survives scrutiny is a question, not a narrative. For each uncertainty, write the question you could not answer on day one, tag which of the three categories it falls under, and note how it was resolved or whether it remains open.

Three properties make this work. It is falsifiable — a question has an answer, and either you had it or you did not. It is dated implicitly to the project's start, which is where the test applies. And it points at evidence, so the uncertainty narrative and the experiment log corroborate each other rather than floating free.

Write them during the project. An uncertainty reconstructed two years later from memory reads exactly like one reconstructed two years later from memory, and examiners have seen a great many of those.

If the whole project does not qualify

One provision worth knowing. Where the activities as a whole do not meet the requirements, the test is applied to the most significant subset of elements of the business component (Treas. Reg. § 1.41-4(b)(2)), and keeps narrowing until either a qualifying subset is found or the most basic element is reached. This is the shrinking-back rule.

Practically, it means a large project that fails the test overall may still contain a subcomponent that passes. It is a reason to document at a granular level rather than describing one monolithic effort — and, conveniently, the same granularity Section G will require of you from tax year 2026.

This is information, not tax advice. It summarises published IRS material and Treasury regulations as of October 2026, and those change. Whether any particular activity qualifies for the credit depends on facts this page cannot know. Have a qualified CPA or tax counsel review any position before you file it.