A research project has structure. It moves through phases, it passes milestones, it produces deliverables on a schedule, and it changes status as it goes. Anyone who has managed a grant knows this structure intimately — and yet almost none of it survives into the durable research record. The phases and milestones live in a proposal document and a project-management tool, and when the project ends they are forgotten, leaving behind only a scatter of outputs. This article asks what it would take for project metadata to travel — to become part of the research record rather than ephemera in a filing cabinet. It draws on the research-lifecycle domain.
The vocabulary of project structure
Start with the concepts, because they are stable across funders even when the names vary. A project phase is a defined sub-period of a project with its own deliverables — the structure that lets a three-year grant be planned as a sequence rather than an undifferentiated block. A milestone is a scheduled point at which a specific outcome is achieved: a target, not a task. A deliverable is a scheduled output, often tied to a milestone. A work package is a grouped set of activities, the organising unit familiar to anyone who has worked on an EU-funded consortium. And a project status — proposed, awarded, active, suspended, completed, discontinued — captures where the whole activity currently stands.
These are not exotic concepts. They are the ordinary furniture of project planning, and they are common to nearly every substantial research grant. What is missing is not the concepts but a shared, structured way of recording them that outlives the proposal.
Why this structure evaporates
The reason project structure rarely reaches the research record is that it is captured in the wrong places. Phases and milestones are written into the proposal — a PDF — to satisfy the funder at application time. They are then re-entered, in a different shape, into whatever project-management tool the team uses to run the work. Neither of these is part of the durable, identifier-anchored record. The proposal is archived and forgotten; the project-management tool is decommissioned when the project ends. The structure was real and useful throughout the project’s life, and then it simply disappears, because nothing was responsible for preserving it as data.
The cost of this evaporation is subtle but real. When a project’s phases and milestones are lost, the record retains what was produced but not when, against what plan, or in what sequence. A reviewer assessing whether a project delivered against its objectives cannot easily compare the planned milestones with the actual outputs, because the planned milestones are gone. The narrative of how the project unfolded — which is exactly what a final report or an impact assessment needs — has to be reconstructed from memory.
What “metadata that travels” means
For project metadata to travel, three things have to be true. First, it has to be structured rather than locked in prose: a milestone recorded as a dated, named, status-bearing entity, not a sentence in a proposal. Second, it has to be anchored to a persistent identifier, so that it has a stable home and can be referenced from elsewhere. Third, it has to be updated through the lifecycle, so that the record reflects what actually happened — a slipped milestone, a re-scoped phase, a change of status — rather than freezing the plan as written at award.
The natural anchor is the project’s RAiD. A Research Activity Identifier gives the project a stable identity across its lifecycle, and its structured record is the right place to hang the phases, milestones, and status that the project moves through. The deliverables link out to the outputs they produced (by DOI); the milestones carry dates and statuses; the project status updates as the work proceeds. The data-management plan, anchored by its DMP ID, is itself a kind of living project document that should evolve with the phases rather than freezing at award — the same principle applied to the data plan that a travelling project record applies to the project as a whole.
The living-record principle
The deepest shift here is from a frozen plan to a living record. Research administration has historically treated the proposal as the canonical statement of a project’s structure: written once, approved, and thereafter immutable. But a project is not immutable. Milestones slip, phases are reordered, scope changes, and a record that freezes the original plan becomes steadily less true as the project proceeds. The machine-actionable data-management plan community has already made this argument for DMPs, and the same logic applies to project structure generally. Metadata that travels is metadata that stays true, because it is maintained rather than archived.
A caveat against over-formalising
A note of restraint. The goal is not to turn every research project into a heavyweight, fully-specified work-breakdown structure policed by metadata. Research is not pure project management, and much valuable research is genuinely exploratory, with phases and milestones that are loose by design. The aim is a light shared vocabulary — enough structure to record the phases, milestones, and status that a project genuinely has, in a form that travels — not a mandate to plan research as if it were construction. A vocabulary that forced exploratory work into rigid milestones would be worse than none. The right amount of structure is the amount the project actually has, recorded so that it survives.
Where the dictionary fits
The concepts — phase, milestone, deliverable, work package, status — are stable and shared, but their representations are not. Every funder names them differently; every CRIS structures them locally; every project-management tool has its own model. A shared, operational vocabulary for these lifecycle concepts, with clear definitions and the status values enumerated, is what would let project metadata mean the same thing as it moves between the proposal, the CRIS, the RAiD record, and the funder’s report. Supplying that vocabulary is the convening role the CASRAI dictionary is built for.
What to do now
For research teams and offices: capture phases, milestones, and status as structured, dated entities anchored to the project’s RAiD, and update them as the project proceeds rather than freezing the proposal. For funders: accept and request project structure as machine-readable metadata, so that delivery against plan can be assessed without manual reconstruction. For standards work: define the lifecycle concepts lightly and federate to RAiD and the DMP standards, resisting the temptation to over-formalise.