Most R&D management systems are built around projects and work packages. That is where the activity happens, where time is logged, where deliverables are tracked. It is also, in most companies, where R&D evidence disappears.
The problem is not that work packages are the wrong unit of capture. The problem is that they are disconnected from the technologies they are advancing. A work package assigned to a project produces a project record. A work package connected to a core technology produces R&D evidence. The difference between those two outcomes is the difference between a claim that holds up and one that doesn't. Between a knowledge base that persists and one that walks out the door.
The Architecture of Connected R&D
The Core Technologies framework establishes a three-level architecture: core technology areas at the top, projects and investigations in the middle, work packages and activities at the base.
In this architecture, each work package is not just assigned to a project, it is also connected to one or more core technology areas. The connection is explicit: this work package is advancing this technology, in this specific direction, against this state of the art.
That connection does several things at once. It ensures the work package contributes to a technology-level record, not just a project-level one. It makes the R&D evidence contemporaneous. It is captured at the time the work happens rather than reconstructed afterwards. It makes the knowledge searchable and retrievable by technology area, not just by project. And it creates the link that makes the work fundable: the chain from work package to investigation to core technology to state-of-the-art advancement is the chain that a tax credit claim or grant report needs to trace.
How it Works in Practice Across Sectors
In manufacturing, a work package investigating a new materials joining technique connects to the core technology area covering joining and assembly processes. The work package records what was attempted, what was known at the outset, what the challenge was, and what was found. That record accumulates against the technology, building a history of what has been tried and learned.
In software, a work package developing a novel approach to a data processing challenge connects to the core technology covering the relevant algorithm or infrastructure area. The investigation records the gap in existing approaches, the experiments conducted, and the outcome. When the next sprint addresses a related challenge, it builds on the technology record rather than starting from scratch.
In industrial automation, where R&D frequently arises in the delivery of customer projects, the connection between work packages and core technologies is what transforms project delivery activity into claimable R&D. The same work, without that connection, is just a cost of delivery.
In MedTech, where multiple technology areas interact in every device development programme, the connection ensures that investigations spanning materials science, device engineering, and validation methodology are each captured against the right technology rather than being absorbed into a single project record that cannot be disaggregated for claim purposes.
The IP Connection
The technology-to-work-package connection also creates the foundation for IP management. When investigations are connected to named core technologies, the output of those investigations, such as new approaches, novel techniques, protectable methods, is automatically associated with the technology area that generated it.
This makes IP identification proactive rather than reactive. Rather than asking at year-end what might be protectable, the company has a running record of what has been developed in each technology area, what is genuinely novel, and what decisions were made about protection. The history file for each core technology is also, effectively, an IP audit trail.
What this Means for R&D System Owners
The practical implication is that the R&D management system needs to support two connections: work packages to projects (which most systems do), and work packages to core technologies (which most systems do not).
Building that second connection does not require replacing existing tools. It requires establishing the core technology taxonomy (the named list of technology areas) and creating the mechanism for engineers to connect their work packages to the relevant areas as they work, rather than after the fact.
ReaDI-Watch is built around this architecture. If you would like to see what it looks like in practice, specifically what a well-governed core technology record looks like for a company at a similar scale and sector to yours, the next article covers that directly.