The Jira board shows 112 tickets. Nineteen were rolled back. Six are labeled “failed experiments.” To the CEO, it looks like “normal development.” To the tax rules, it’s a live demo of the four‑part test.
This article is about turning that test into a practical field guide founders, CTOs, and CFOs can use in real conversations—not a legal lecture.
1. The Four‑Part Test in Plain English
When you strip away code sections and jargon, the core questions are:
What are we trying to improve? (Permitted purpose, business component.)
Are we solving a technical problem? (Technological in nature.)
Were we genuinely unsure how to do it at the start? (Elimination of uncertainty.)
Did we try alternatives and learn from the results? (Process of experimentation.)
If you can answer “yes” to these with decent evidence, you’re on the right track. If you can’t, forcing a claim usually creates audit risk with limited upside.
The Jira board as a live example
Take that 112‑ticket sprint:
Business component: a core API that needs to respond 3x faster under peak load.
Technical nature: software engineering and computer science.
Uncertainty: at kickoff, the team doesn’t know whether sharding, caching, or a new queue design will actually get them there, or at what cost.
Experimentation: they try multiple architectures, run load tests, roll back failed attempts, and iterate until performance stabilizes.
Your job as a CFO isn’t to tag every ticket. It’s to recognize that this arc—uncertainty plus structured iteration—is exactly what the rules are talking about.
2. Step 1 – Permitted Purpose: “What Are We Improving?”
The test starts with the business component and its permitted purpose.
Ask:
What specific product, feature, process, or subsystem are we working on?
Are we trying to improve its function, performance, reliability, or quality?
Examples:
Manufacturing: a new welding process to reduce defects and rework.
SaaS: a recommendation engine that must be both more accurate and faster.
DoD: a radar subsystem that must detect smaller targets at longer range.
If all you can say is “we’re keeping the lights on” or “we’re doing routine maintenance,” you probably don’t have a good candidate project. If you can point to a concrete improvement goal, you might.
Field guide cue: Write the purpose in one sentence: “We are trying to [improve X metric] for [this product/process].”
3. Step 2 – Technological in Nature: “Is This a Technical Problem?”
Next, the work must rely on hard science or engineering disciplines, not just aesthetics or marketing.
Ask:
Which disciplines are actually in play? Mechanical, electrical, or industrial engineering. Computer science, data science, or software engineering. Physics, chemistry, materials science, or similar.
Examples that fit:
Calculating structural stresses, modeling heat transfer, simulating fluid flow.
Designing algorithms for routing, optimization, or signal processing.
Tuning statistical and ML models using data and math, not guesswork alone.
Examples that generally don’t:
Choosing a color scheme or layout purely for aesthetics.
Running focus groups to test customer preferences.
Copy‑editing marketing collateral.
Field guide cue: If your engineers can’t explain the work using technical principles they learned in school, and instead explain it as “we picked whichever looked nicer,” it probably doesn’t qualify.
4. Step 3 – Elimination of Uncertainty: “What Didn’t We Know?”
The third element focuses on uncertainty at the outset of the project.
Key question:
At the time we started, were we uncertain about whether we could achieve the goal or how to do it?
Break it into the three uncertainties from Article 2:
Capability uncertainty – can we achieve that performance at all?
Method uncertainty – which approach will work in our environment?
Design uncertainty – which configuration or design variant meets all constraints?
Examples:
“We don’t know if we can hit 99.99% uptime with our current stack and budget.”
“We don’t know if we can keep vibration under spec with available materials and space.”
“We don’t know which control algorithm will stabilize the system under all operating conditions.”
What doesn’t count is fake uncertainty:
“We were uncertain which of three stock paint colors customers would like.”
“We weren’t sure which marketing slogan would convert better.”
Field guide cue: Capture a one‑line “uncertainty statement” for every candidate project: “At the start, we did not know whether/how we could [achieve X] given [constraints].”
5. Step 4 – Process of Experimentation: “How Did We Learn?”
Finally, there must be a systematic process of testing alternatives and drawing conclusions.
Ask:
Did we formulate alternatives?
Did we test or model them?
Did we analyze the results and adjust?
Experimentation can include:
Prototypes and pilot runs.
Bench tests, lab tests, or environmental tests.
Simulation, modeling, and then real‑world trials.
Controlled changes to code, parameters, or configurations with measurement.
It doesn’t have to be elegant science; it does need to be structured enough that you can:
Identify what changed.
See what was measured.
Show how the next iteration responded to those results.
Field guide cue: For each project, jot down 2–5 “experiments” in sentence form: “We tried [approach A], measured [metric], learned [result], and then moved to [approach B].”
6. What Is Not Required (Lose These Myths)
Many teams quietly disqualify themselves because they assume a higher bar than the rules actually set.
You do not need:
Patents.
Academic publications.
Breakthrough inventions.
Successful outcomes on every project.
Failed projects often still qualify if they meet the four elements. The critical question is whether you genuinely did technical work with uncertainty and a process of experimentation—not whether the market loved the result.
Field guide cue: If a project was technically hard, involved real trial‑and‑error, and failed for technical reasons, it may still belong in your R&D project list.
7. Guardrails: What Clearly Does Not Count
To avoid overreaching, keep a short blacklist in every qualification discussion.
Generally out:
Post‑production tweaks and break‑fix that follow established procedures. Example: fixing bugs using known patterns with no uncertainty.
Routine quality control and inspection of standard products. Example: running standard QC tests with no changes to design or process.
Cosmetic UI changes and branding work. Example: font, color, or layout choices unrelated to performance or function.
Market research and customer preference studies. Example: A/B testing landing page wording for conversion.
Non‑U.S. activities. Example: engineering work taking place entirely outside the U.S., even if coordinated by a U.S. team
These activities may be vital to the business, but they’re usually not R&D for credit purposes.
Field guide cue: When in doubt, ask: “Is this work changing the technical underpinnings of the product or process, or just observing/servicing what already exists?”
8. “Don’t Be This Headline”: When Good Work Loses on Evidence
There are real cases where companies did genuinely innovative work but lost most or all of their credit in disputes because they could not tie time and costs to the qualifying work.
Typical failure pattern:
The company describes impressive engineering achievements—new systems, advanced algorithms, complex manufacturing processes.
But when asked: Which employees worked on which projects? What portion of their time was spent on qualifying activities vs other work? Which supplies and contract costs mapped to R&D vs production?
They respond with vague estimates and generic percentages unsupported by records.
Courts and exam teams have repeatedly disallowed or sharply reduced credits when:
Job titles were used as the sole basis for including 100 percent of wages (e.g., “all engineers count”).
There were no project‑level records tying people to specific experiments or phases.
Documentation looked like it was prepared after the fact, with no connection to contemporaneous systems (tickets, time sheets, project codes).
The lesson is not “don’t claim credits.” It’s “don’t claim credits you can’t support.”
Field guide cue: For each project on your R&D list, ask:
“Can we show which people worked on this and roughly how much of their time?”
“Can we point to real artifacts (tickets, CAD, test reports) that prove the experimentation story?”
If the answer is “no,” either improve the records or be conservative about what you include.
9. Turning the Test into a Meeting Checklist
You don’t need a 40‑page memo to apply this test day‑to‑day. You need a short, repeatable conversation.
In your next quarterly R&D review with product, engineering, or operations, walk through each candidate project with four questions:
Permitted purpose:
What specific product/feature/process did we work on?
What performance, reliability, or quality improvement were we aiming for?
2.Technological nature:
Which engineering or scientific principles did we rely on?
3.Uncertainty:
What did we not know at the start (capability, method, design)?
4.Experimentation:
What alternatives did we try?
How did we test and measure?
What changed because of those results?
Capture answers in simple bullet points while people still remember the work. Later, those bullets can be turned into formal project write‑ups and documentation that support your R&D claim.
Used this way, the four‑part test stops being a piece of tax trivia and becomes a practical leadership tool: a way for founders, CTOs, and CFOs to consistently distinguish “real R&D” from everything else and to make sure the company actually gets credit for the hard technical work it’s already doing.
Go deeper: Guide 08, Non-Dilutive Capital, part of the CFO Guide Series: 24 one-page guides for CEOs and founders.
