Software and manufacturing R&D in the UAE: evidence playbooks that survive review

1. Software and deep tech: where the evidence lives

Software R&D files tend to fail in one of two ways. Either they are too thin: a slide deck with feature roadmap items and no connection to technical uncertainty, or they are too broad, claiming an entire engineering programme as R&D when only a subset of the work genuinely involved novel investigation. Getting the boundary right, and then documenting within that boundary thoroughly, is the central challenge.

The good news for software teams is that the evidence of genuine R&D, if it was genuinely done, already exists in the tools they use every day. The architectural decision records that explain why a new approach was chosen over the alternatives are novelty evidence. The sprint epics created when a team begins investigating an unknown performance characteristic are uncertainty evidence. The load-test runs archived in CI, showing the six configurations that failed before the seventh worked, are systematic-investigation evidence. None of this needs to be created specifically for the credit claim; it needs to be captured in a way that can be exported, linked to the relevant project, and read by someone who was not in the room.

Architecture decision records deserve particular attention as a documentation asset. A good ADR describes the problem being solved, the options that were considered, the criteria against which they were evaluated, and the reasoning for the chosen approach. That structure directly answers the Frascati questions about novelty, creative approach, and why known methods were insufficient. Teams that write ADRs routinely have significantly better R&D evidence than teams that do not, even when the underlying engineering quality is similar. If your team is not writing ADRs yet, starting before you begin a qualifying project, not after, is the right time.

Automated test history is another consistently underused evidence source. Flaky test investigations, performance regression analyses, and reliability investigations all involve the systematic pursuit of a technical answer to a question that was not known at the outset. The CI logs for a three-month investigation into why a distributed system intermittently fails under specific load conditions can be extraordinarily strong Frascati evidence if the investigation itself was genuinely uncertain, that is, if the engineers did not know what was causing the failure when they started.

Security and resilience engineering deserves mention specifically because it is frequently either over-claimed or under-claimed. Routine patching, applying known security controls, and responding to CVEs are not R&D. Qualifying work might include designing a novel threat model for a new deployment architecture, systematically evaluating attack surfaces that have not been previously analysed for your specific system configuration, or engineering new reliability mechanisms for distributed coordination problems. Those efforts can be R&D if framed correctly and documented contemporaneously.

An illustration: machine-learning model drift in production

A fictional fintech team in Dubai discovers that the fraud-detection models they deployed perform well during regular business hours but show systematic degradation in Gulf-region weekend transaction patterns, a characteristic they had not anticipated and that had not been documented in the research literature for their specific market segment. They spend twelve weeks running structured retraining experiments: varying the training data window, adjusting feature engineering for regional temporal patterns, testing ensemble configurations, and evaluating cross-market transfer approaches.

This is genuinely uncertain work: the team does not know at the start which retraining approach will work, or whether any single approach is sufficient without architectural changes to the serving pipeline. The evidence that supports a Frascati file for this project is the experiment logs with dataset hashes and evaluation metrics archived per run, the feature-flag records showing which configurations were deployed in which sequence, and the postmortems written when accuracy targets were missed. Crucially, those postmortems should explain what the measurement showed and what that implies about the model's behaviour, not just "experiment failed, tried something else." The analysis of failure is often the strongest demonstration that the investigation was genuinely systematic.

2. Manufacturing and materials: where the shop floor is the lab

Industrial R&D teams often have a structural advantage over software teams in one respect: their evidence is physical. Temperature curves, tensile test results, dimensional measurements, and metallographic analyses are inherently dated, instrument-specific, and hard to fabricate. The challenge in manufacturing R&D is not usually that the evidence does not exist; it is that the records were not structured as R&D evidence at the time they were created.

A team running furnace trials to solve a micro-cracking problem in a new alloy composition produces extraordinary R&D evidence: per-batch parameter settings, deviations from target, defect measurements, and the decision logic that drove the next trial. The same information captured as routine quality-control data, without the framing of what question each trial was designed to answer and what the result implied for the next step, is much weaker Frascati evidence. The difference is not what the team did; it is how the records characterise what the team did.

Manufacturing execution system (MES) data and quality-control records are the evidence backbone for industrial R&D claims. Lot numbers, operator notes, parameter setpoints, and deviations form a timestamped chain that connects intentions to outcomes. Statistical process control charts, histograms of defect rates across trial batches, and failure mode analyses are not just quality records; they are systematic-investigation records when framed within the context of a specific R&D objective with defined success criteria.

Where manufacturing R&D claims most often weaken is in the separation between investigation activities and scale-up or production activities. Qualifying R&D ends when the technical uncertainties are resolved, when the team knows the answer to the questions they set out to investigate. The scale-up of a proven process, even if it is complex and expensive, is generally not R&D under Frascati criteria. Claiming production costs as R&D costs is a common error that advisers and reviewers are specifically trained to identify.

An illustration: composite structure bonding process development

A fictional aerospace supply chain company in the Khalifa Industrial Zone is developing a new surface preparation process for structural bonding of carbon fibre assemblies intended for regional aircraft programmes. The required peel strength exceeds what current surface treatment standards reliably achieve in high-humidity Gulf conditions, creating a genuine technological uncertainty. The team runs a structured programme of 24 trial panels across six surface treatment variants, measuring peel strength, void density, and environmental degradation across a simulated service cycle.

The R&D evidence for this project is the trial matrix itself: the hypothesis behind each variant, the parameter settings and process conditions for each panel, the measurement results, and the decision record explaining why variants 1 through 4 were abandoned and what those results implied about the failure mechanism. The project crosses into production and scale-up once the team has a confirmed process that reliably meets the peel strength target; the investigation and qualification work up to that point is eligible. The subsequent volume production is not. Keeping that boundary clear in the records is essential.

3. Cross-industry habits that cost nothing but discipline

Across both sectors, the teams with the strongest R&D evidence share a few practices that have less to do with tooling than with how engineering culture treats documentation.

The most important is treating failure documentation with the same seriousness as success documentation. In most engineering organisations, postmortems are written for production incidents and then quietly forgotten. In an R&D context, the record of a failed approach, what was tried, what was measured, and what that implies, is often the most valuable piece of Frascati evidence in the file. A project with no documented failures may be a project with no genuine uncertainty, or it may be a project where the team did not capture what actually happened. Reviewers know both are possible and will look for the distinction.

The second habit is linking costs to work at the project level from the beginning, not at year-end. Every engineer working on a pre-approved R&D project should have their time attributable to that project through a consistent record, timesheet, ticket allocation, or payroll system project code. Every significant cost incurred on the project should be traceable from the financial record to the qualifying activity. This linkage does not need to be perfect: approximations and allocations are common in R&D claims across every jurisdiction, but it needs to exist and it needs to be documented before the year closes.

The third habit is treating the UAE R&D Council project code as the spine of the evidence file, not as a separate compliance task. Once approval is granted for a project, that project identifier should appear in Jira, in the commit history, in the time-allocation system, and in the financial records. The ability to pull all records associated with a specific approved project, across all the systems where engineering work happens, is what allows a coherent file to be assembled at claim time without a months-long reconstruction exercise.

4. Where AutoDoc fits in industry-specific workflows

AutoDoc integrates with the systems where evidence already lives (Jira, GitHub, Linear, Notion, and others) for software teams, and with structured export workflows for manufacturing and industrial clients whose evidence is in MES, QC, and ERP systems. The output is a project-level evidence structure mapped to Frascati criteria, linked to the pre-approved project identifiers, and ready for adviser review.

The goal is to make UAE Frascati documentation a by-product of shipping, or of running the furnace trials, rather than a parallel project that consumes engineering resources at year-end. That is the same thesis that drives our SR&ED work in Canada, where the cost of building documentation contemporaneously is consistently lower, and the defensibility of the result is consistently higher, than documentation assembled retrospectively.