Case study sample · Step 2 of 2 · R&D qualification under deadline
R&D Qualification Workflow & Traceability Pack
Feature evaluation, issue-level evidence, allocation logic, and accountant-facing output.
Executive readout
Northfield Analytics had three business days to prepare a leadership-ready view of R&D tax-credit qualification. The same coverage and traceability pack was estimated at roughly four weeks to produce manually. The work began by becoming familiar enough with the relevant tax-credit criteria to evaluate work credibly, then building a repeatable framework leaders could trust. AI accelerated classification and synthesis against Jira evidence. Human reviewers remained responsible for the final call. Overall status: Ready for accountant review.
Evaluation framework
Each feature and child issue was assessed against explicit criteria before any model output was treated as input to a decision.
| Criterion | Question asked | Minimum evidence |
|---|---|---|
| Technical uncertainty | Was the work attempting to resolve uncertainty that could not be determined in advance? | Design notes, spikes, experiment logs, or architecture decision records. |
| Process of experimentation | Did the team evaluate alternatives or test hypotheses? | Iteration history, prototypes, test results, or rejected approaches. |
| Qualified purpose | Was the work directed at new or improved functionality, performance, or reliability? | Feature description, acceptance criteria, or delivery summary tied to capability change. |
| Evidence sufficiency | Is the source material complete enough for a reviewer to agree or disagree? | Linked Jira items with dates, owners, and identifiable scope. |
Workflow design
| Step | What happens | Human / tool role |
|---|---|---|
| 1. Frame | Apply evaluation framework and issue classifications to the work inventory. | Human lead defines criteria, exclusions, and allocation rules. |
| 2. Gather | Pull approved Jira evidence for each candidate feature and child issue. | Systems of record only; no unapproved uploads. |
| 3. Assess | Model drafts feature summaries, issue classifications, and recommended allocations. | AI accelerates first-pass analysis against known sources. |
| 4. Review | Named reviewer checks assessments, partial allocations, and missing evidence. | Human sign-off required before inclusion in the workbook. |
| 5. Publish | Populate feature tables, issue traceability, calculations, and accountant narratives. | Human lead approves what leadership and finance will see. |
1. Feature-level R&D evaluation
Illustrative extract showing why a percentage is recommended instead of labeling an entire feature as R&D.
| Tax year | Feature | Technical uncertainty | Experimentation | Recommended R&D % | Rationale |
|---|---|---|---|---|---|
| 2025 | Feature A – Authentication Enhancement | Team evaluated multiple approaches for securely supporting a new authentication workflow. | Prototype work, implementation alternatives, integration testing, and technical spikes were documented. | 70% | Significant engineering effort related to resolving technical uncertainty; routine rollout and regression work excluded. |
| 2025 | Feature B – UI Refresh | No meaningful technical uncertainty identified. | Standard implementation and visual QA. | 0% | Primarily styling and routine implementation work. |
| 2026 | Feature C – AI-Assisted Search POC | Uncertainty around model integration, response quality, latency, and architecture. | Multiple technical approaches evaluated through proof-of-concept work and testing. | 85% | Most development activity supported experimentation; deployment and routine QA excluded. |
2. Issue-level evidence behind a feature
Illustrative drill-down for Feature A – Authentication Enhancement.
| Work item | Classification | Evidence | R&D treatment |
|---|---|---|---|
| Story 001 | Qualifying research | Compared two authentication approaches and documented limitations. | Include |
| Spike 002 | Experimental implementation | Prototype created to validate token handling and session management. | Include |
| Story 003 | Routine implementation | Implemented final selected approach after architecture decision. | Partial / exclude |
| Task 004 | QA / UAT | Regression testing of completed functionality. | Exclude |
| Task 005 | Deployment | Production release activities. | Exclude |
3. Allocation / effort calculation
Illustrative example for Feature D. Story points are used as an effort proxy, not actual employee time.
| Feature | Total effort | Qualifying effort | Recommended R&D allocation |
|---|---|---|---|
| Feature D | 120 pts | 84 pts | 70% |
Calculation logic: Qualifying R&D allocation = qualifying experimental/research effort ÷ reviewed development effort.
Underlying work was categorized into experimental implementation, qualifying research, routine implementation, QA/UAT, deployment, maintenance, and unresolved work. Partial allocations reflect issue-level treatment rather than treating every child item the same way.
4. Accountant-facing representative sample
| Feature | Platform Processing Modernization |
|---|---|
| Tax year | 2025 |
| Business component | Product platform |
| Recommended R&D allocation | 75% |
Technical uncertainty: The engineering team needed to determine whether the existing processing architecture could meet new scalability and reliability requirements. Several implementation approaches were considered.
Process of experimentation: Jira evidence showed technical spikes, alternative implementations, performance testing, and iterative changes before the final architecture was selected.
Qualifying activity: Architecture investigation, prototyping, experimental implementation, and technical validation.
Excluded activity: Routine implementation after the solution was established, regression testing, deployment, and production support.
Supporting evidence: Feature description, child stories, technical spikes, acceptance criteria, development history, testing records, and Jira comments.
5. Summary-level output
| Population | Result |
|---|---|
| Features reviewed | 294 |
| Features receiving an R&D allocation | 223 |
| Child issues / evidence items reviewed | 5,000+ |
| Primary evidence source | Jira |
| Allocation basis | Issue classification + effort proxy |
| Final determination | Subject to accountant review |
The full workbook contained hundreds of rows. This sample shows the progression from Jira evidence to classification, allocation, and accountant-facing output without reproducing the entire population.
Workbook excerpts
Illustrative workbook views showing how the same logic appears in a reviewable spreadsheet. All feature names, work items, effort values, and narratives are fictional and anonymized.
What made it work
- Framework before tooling: criteria and classifications were agreed before prompts were written.
- Percentages with rationale: leaders and accountants could see why 70% was recommended instead of treating a feature as all-or-nothing R&D.
- Traceability by design: every allocation could be followed back to issue-level evidence and source material.
- Human decisions preserved: the workflow produced recommendations subject to accountant review, not automatic conclusions.
- Time compression without credibility loss: roughly four weeks of manual work compressed into three business days because synthesis was assisted, not outsourced.
Decision requested
Confirm which feature allocations leadership will defend, which items need additional evidence, and whether to carry this workbook structure forward for the next qualification cycle.
All names, counts, and observations in this sample are illustrative. This is an example of the deliverable format, not a claim of client results.