The Research Cockpit Playbook

A replication guide for integrated research data management platforms, initialized by the team at Eindhoven University of Technology and published openly for knowledge sharing and collaboration with other Dutch and European research institutions.

Status: v0.1 draft. A living document. Corrections, extensions, and forks welcomed.

Note

If you are a student or researcher looking for the Research Cockpit itself, you can find it at https://cockpit.research.tue.nl.

Table of contents

• Part 0 — About this playbook
• Part 1 — Why a research cockpit?
• Part 2 — Guiding principles
• Part 3 — Process-onboarding framework
• Part 4 — Process catalogue
• Part 5 — Product ownership in practice
• Part 6 — Getting started at your institution

Part 0 — About this playbook

This website and repository holds the Research Cockpit Playbook. It is set up to be the place where we can share and collaboratively evolve in an open format what the concept of the Research Cockpit is and how it can evolve with parties within TU/e and input from the broader research (support) community.

The Research Cockpit within Eindhoven University of Technology is a central portal for researchers to navigate research support and infrastructure. The Research Cockpit Playbook serves as open reference and exploration of the Research Cockpit as potential replicable concept. At Eindhoven University of Technology this concept is called the Research Cockpit, at other universities it might have it's own name.

Status

Status: v0.1 draft. A living document. Corrections, extensions, and forks welcomed

We are actively looking for feedback and input on content, framing and scoping to build towards a v1.0 release of this playbook.

For v0.1 the approach is consciously to provide a large variety of aspects involved in establishing the Research Cockpit to elicit feedback on the scope. Feedback on what should be removed or captured elsewhere is as valid as feedback and input on what you wish to have more detail on.

Contributions

Any type of feedback, input or questions are welcome. These can be transparently submitted through issues on the Github repository.

v0.1 writing methodology

In the period of building and establishing the Research Cockpit at Eindhoven University of Technology a large internal knowledge base was built out. The internal knowledge base spans conceptual thinking, process design elements, highly detailed configuration documentation and by now adds up to hundreds of pages. The methodology for writing the v0.1 draft was by having an Agentic AI system (Claude Code) compile various versions of the playbook from a local mirror of this internal documentation repository. Parts of the v0.1 playbook were written by hand while other parts were hand-picked from these AI-compiled versions of a playbook.

Summary

The Research Cockpit within Eindhoven University of Technology is a central portal for researchers to navigate research support and infrastructure. The Research Cockpit Playbook serves as open reference for the design of the Research Cockpit as replicable concept. At Eindhoven University of Technology this concept is called the Research Cockpit, at other universities it might have it's own name. Read the RESEARCH_COCKPIT_PLAYBOOK.md for more details.

Brief history

• 2023 - Concept definition within context of Research Data Infrastructure program.

• 2024 - Initial build-out & DMP/ERB go-live.

• 2025 - Adoption phase and more process onboarding (Data Agreements, Research Contracts, pre-DPIA & more).

• 2026 - Further system integrations & evolved project-based UI/UX.

  • Playbook initialized.

Who this is for

• Policy leads and research-data directors weighing whether to fund something like this at their institution.
• Product owners and service designers expected to scope, design, and shepherd the work.
• Technical implementers — JSM admins, platform engineers, automation developers — who will build it.

Playbook Scope

The Research Cockpit Playbook describes the concept in two layers.

At the content-layer, the playbook documents key processes essential to the concept and its role in the research life cycle.

On the structure layer, the playbook documents the systems and methodology of process integration & harmonization within a unified user experience.

At Eindhoven University of Technology, the initial version of the Research Cockpit has been realised through configurations on top of Atlassian Jira Service Management as platform. In this Playbook however we aim to be tool-agnostic.

Process documentation

In this playbook, we document the conceptual scoping of the processes and key design artefacts such as templates in use, workflow descriptions. Actual implementation data is captured separately.

Structure documentation

At this layer, we document the conceptual solution architecture of the systems in place to realize the Research Cockpit and the organisational capabilities required to build and maintain it.

At this layer it is as much about systems & technology as it is about roles & responsibilities between teams and people involved.

Part 1 — Why a research cockpit?

At its core, the Research Cockpit is about solving a two-sided problem that is universaly present at universities.

The two-sided problem: Researchers need a variety of organisational and infrastructural support, however have difficulty finding and receiving this across scattered teams within the university.

Support staff have difficulty reaching researchers at the right time in their process, often

The solution: The Research Cockpit serves as central portal where support & services are organised along the research (data) lifecycle. So that researchers can immediately find and navigate to the the relevant next steps and the right support staff is kept in the loop on what is currently happening.

---

Part 2 — Guiding principles

Warning

Summarised from internal documentation with AI

A cockpit platform touches a lot of offices, a lot of systems, and a lot of careers. Once it is live there will not be time to re-derive a design from first principles in every planning meeting. You will need a short list of commitments to point at. These are ours. Six principles, the closest thing the team has to a constitution.

P1 — Federate over centralise

Every process this platform coordinates is owned somewhere else in the organisation. The data steward who reviews DMPs does not report into the platform team. The ethics reviewer does not. The legal counsel reviewing a contract does not. Centralising decision authority alongside the platform fails twice over: it gets rejected by the offices that own the work, and it ignores that those offices know more about their work than the platform team ever will.

The platform's job is to coordinate, not to own. Each process has a single named process owner outside the platform team. They set the intake form, the approval criteria, the SLA. The platform provides the infrastructure (workflow engine, forms, identity, automations, documentation substrate) and the connective tissue between processes. When something about a process must change, the platform team proposes and the process owner decides.

This costs you speed on your own ideas and buys you adoption. It is the right trade.

NOTE:

Failure mode: a process owner disengages (illness, reorganisation, loss of interest) and the platform team fills the vacuum "just for now". Six months later the team owns a process it never wanted. Set a rule: if a process owner is absent for more than N weeks, the process pauses or transfers. It does not migrate silently.

P2 — Tight coupling of data, loose coupling of process

Two processes that share a researcher, a project, and a dataset will need to share facts about them. Two processes that share workflows will grind each other to a halt the first time either one needs to change.

Share the data, not the flow. The Data Management Plan and the Ethics Review Board both need to know whether the project involves personal data, which legal basis applies, what retention period is declared. Those facts live in a small set of shared custom fields, owned by the platform team, documented once, reused everywhere. When a fact changes, every process sees the new value.

The workflows stay independent. The DMP's intake form, status transitions, SLAs and approval rules are DMP's concern. ERB's are ERB's. They do not share state machines, approvers, or "statuses". When they need to coordinate, they coordinate through events: the DMP's automation notices personalData == true and fires a creation event into the ERB project. From that moment the ERB case has its own life.

This is the most consequential architectural choice in the platform. Every process owner, the first time they integrate, will ask for "just one shared status field so we can show a unified progress bar." Don't agree. Build the progress bar by reading events. The shared status field metastasises.

Part 5 shows the cross-process trigger from DMP to ERB. Part 6 shows the shared-field schema.

P3 — Researcher experience drives back-office design

The researcher is the only actor in the system whose time is not billed to the system. Designing for staff efficiency ships a tool that staff adopt and researchers avoid, which means staff end up chasing researchers, which means the tool fails at its actual job.

Design inside-out from the researcher's journey. A researcher who has declared in their DMP that they are handling medical data should not have to re-declare it when opening an ERB case. A researcher who has signed a data sharing agreement should be told, pro-actively, which storage environment is now available to them. A researcher who has registered a project should be able to see every downstream obligation attached to it on one page.

The back-office adjustments this demands — shared vocabularies, cross-process status propagation, pre-populated forms, unified notifications — are what make the platform a platform rather than a portal. The back-office pain is the work, not a side-effect of it. Pay it.

NOTE:

Failure mode: a process owner insists their intake form must ask a question the researcher already answered elsewhere, "for our records". The right answer is: we have the answer; we will show it pre-filled and the office can confirm it. The wrong answer is to ask again.

P4 — Recommend, provision, control: pick integration depth deliberately

Integrations between the cockpit and downstream research data infrastructure systems live on a scale from loosely coupled to tightly coupled. Choose consciously where each integration sits.

Recommend. The cockpit reads the researcher's context and suggests a downstream system (storage, TRE, code repository). The researcher, or another office, still provisions it. Lowest coupling, easiest to introduce, best for services you do not control.

Provision. On approval of a cockpit process (e.g. a signed-off DMP) the cockpit automatically creates the downstream resource: a Research Drive project, an Azure storage allocation, a TRE workspace. Medium coupling. Requires a clear lifecycle contract with the downstream system, since the lifecycle of the resource needs to fit the lifecycle of the cockpit process that provisioned it.

Control. The cockpit is the gate. The downstream resource cannot exist without a corresponding cockpit artefact. This is what lets you enforce policies like "sensitive data only lives in environments provisioned against an approved DMP." Highest coupling, highest policy leverage. Requires organisational buy-in, not just a technical integration.

Each deeper level is more valuable and more brittle. Do not "control" what you only need to "recommend". Do not get stuck on "recommend" for the services where "control" is the actual policy goal. Document the depth choice on every integration's own page.

P5 — Process maturity is a first-class concept

Not every process is ready for production. Some are ideas a single office has had about how their work could be better supported. Some are half-built. Some have been live for two years and are now the platform's stable core. A single platform hosts all of them simultaneously, and pretending they are all equal quality lies to users and exhausts the team.

Name the stages. Ours are Pre-scan, In development, Live, with an internal fourth stage — Retired / Archived — that we use too rarely but should use more. Show the current stage on every process's documentation page. Do not present a pre-scan process to researchers as if it were a service.

The maturity label is also a permission structure. A live process changes slowly, with change management and a changelog. A pre-scan process is a sketch; changing it every week is fine. A process that has been "in development" for eighteen months is a diagnosis: either it moves to live or it moves to retired, but it does not stay in development.

P6 — Documentation is infrastructure

Every non-trivial decision about a process — who owns it, what the intake form asks, which automations fire, what the SLA is, what changed last quarter — has to live somewhere that is findable, current, and owned. A pile of pages from 2023 with no named owner and no last-reviewed date is worse than no documentation, because it actively misleads.

We treat the documentation wiki as part of the system, not as a side deliverable. Concretely:

• Every process has a single canonical page, owned by the process owner, not the platform team.
• Every process page follows a common template so a reader can navigate unfamiliar processes on familiar rails.
• Review cadences are declared: process pages quarterly, architecture pages after each major integration, the glossary whenever a new term enters official vocabulary.
• A "complete" page has no unresolved placeholders, accurately reflects current deployment state, and links to related pages with working anchors.
• Archived pages carry a banner naming their replacement. They are not deleted — researchers and auditors sometimes need historical state — but they are clearly marked stale.

Part 7 treats this as an operational discipline. The short version: if the process page is wrong, the process is wrong, regardless of what the Jira configuration says.

How to use these principles

When a decision is easy, you will not need them. When a decision is hard, work through the list and see which ones apply. Most hard decisions turn on one or two; name them in the meeting, out loud. If two principles disagree on a real problem (and on real problems they sometimes will), prefer P1 over P3 over P2, then argue about it from there.

Fork this list. Replace P4 with a principle about your institution's specific research-data-infrastructure reality. Add a principle about multilingual support if you operate across languages. Drop P5 if your platform only ever hosts one process. The point is not these six; the point is having six.

---

Part 3 — Process-onboarding framework

Warning

Summarised from internal documentation with AI

Of the artefacts in this playbook, this is the one most worth borrowing.

Every time you onboard a new process to the cockpit (data management plans, ethics review, a data agreement type, a new intake form for researcher storage) you will be tempted to skip ahead. The process owner already has a form, someone already built an automation, you could be live in a week. Don't. Six months later the form will be asking three questions nobody reads, the automation will be silently misrouting cases, and you will have inherited a process you never designed. The cost of skipping the front end is paid at the back end, with interest.

ETDDDP — Extended Triple Diamond with Development and Deployment — is a staged framework for bringing a process from "someone has an idea" to "this is a live, supported service". It extends the classic Double Diamond design model at both ends to cover the pre-commitment and post-launch realities of a platform team.

Stage	Ends when…	Primary artefact
1. Pre-scan	stakeholders have committed to the work	Proposal for stakeholder commitment
2. Research	the problem is fully understood	Detailed problem statement
3. Design	a solution is agreed and feasible	Solution proposal
4. Development	the implementation is tested and ready	Tested implementation
5. Live	— (continuous)	Running service, changelog, monitoring

Stages are not always hit in sequence. A process with high pre-existing maturity (a long-running workflow that just needs to move onto the platform) can fast-track 2 and 3. A process more entangled than expected can drop back from 3 to 2. The naming of the stage is the point: everyone involved knows which stage they are in, which means they know what is and isn't being asked of them.

Stage 1 — Pre-scan

Decide whether to do this at all, and if so, with what ambition and what commitment from whom.

Identify the prospective process owner and the stakeholders who will be affected. Look up any existing workflow documentation; someone almost certainly has a folder of Word documents already. Run a complexity-and-maturity assessment: plot the candidate process on two axes — how complex is it (many actors, many branches, many dependencies), and how mature is it (how aligned are the owner and stakeholders on what it actually is). Mature-and-simple processes can be onboarded quickly. Immature-and-complex processes are multi-quarter engagements, if they should be taken on at all.

Output a short written proposal that names what the process is, who owns it, why now, what effort is estimated, and what is not being done. Get an explicit commitment from the process owner's line manager that the process owner has time for this. Make a go/no-go decision that is also a "go-now, go-later, or never" decision.

NOTE:

Pre-scan exits when the process owner is named and available, a sponsor with budget authority has said yes, the complexity-maturity plot puts the effort within team capacity for this quarter, and no neighbouring process has an imminent change that would make this one obsolete.

Failure mode: pre-scan gets skipped because "we already know what this is". Two quarters later, an unknown stakeholder surfaces a regulatory requirement that invalidates the design.

Stage 2 — Research

Understand the problem, not the solution. This is the hardest stage for technically-oriented teams to respect, because the team wants to build.

Map the as-is. Interview researchers, interview the staff currently doing the work manually, read the existing forms and emails. Identify the value question: for whom does this process create value, and how? For a cockpit process the primary answer should always be the researcher; the secondary answer is the office that owns the process. If you cannot articulate the researcher value, you are likely about to build an internal efficiency tool that pretends to be a researcher service, and adoption will suffer accordingly.

Outputs: a written problem statement with current pain points named and evidenced; a stakeholder map with named owners for each decision the process requires; a list of integration points with other processes already on the platform, explicit about which data fields will need to be shared; validated user stories, preferably small in number (a dozen is plenty).

The problem statement should be legible to someone outside the process owner's team. If a colleague from the DMP team cannot read the ERB problem statement and understand it, the problem is not yet well-posed.

Failure mode: research slides into design. Someone proposes a solution in an interview, it feels right, the team starts optimising it. Hold the line. No solutions in the problem statement.

Stage 3 — Design

Propose a solution that the process owner can commit to and the platform team can plausibly build.

Activities: user journey mapping for the researcher, workflow diagram for the back-office work, a data model (which custom fields, shared with which neighbouring processes, with which validation), automation sketches (which events fire, which cross-process triggers exist, which notifications go out), integration design for any downstream systems (storage provisioning, identity, document signing), a first pass at the intake form.

Two reviews are mandatory. Stakeholder review — each named integration-point owner has signed off that their side of the boundary is as described. Central architecture review — the platform team confirms the design fits the rest of the system, with particular attention to shared fields (P2) and integration depth (P4).

Outputs: a written solution proposal reviewed with the relevant stakeholders and central architecture; a feasibility assessment ("can the platform team actually build this within the allocated quarter?"); a go-ahead from the process owner, in writing.

Failure mode: design review surfaces integration conflicts that push the process back to research, but the team treats the go-live date as immovable. Quality is paid out of testing and documentation. Move the date.

Stage 4 — Development

Build, test, iterate.

The process owner's team drives content: form questions, portal copy, knowledge-base articles, approval-letter templates. The platform's technical team drives configuration: JSM workflows, custom fields, automation rules, integrations. The two halves meet in a sandbox environment. Researchers and back-office users are invited to test, ideally with real (or realistic) example cases. Findings feed back into form questions, automation logic, portal copy. A form a researcher bounces off is a form that fails the service.

Outputs: a tested sandbox implementation; user testing findings with decisions captured (adopted, deferred, rejected); knowledge-base articles in draft; a completed risk register naming what could break at go-live, how it would be detected, and how it would be rolled back; a rollout communications plan.

Development exits when the sandbox has been exercised end-to-end by at least one researcher and one back-office agent who were not involved in building it, the knowledge-base articles are good enough that a naive researcher can complete the flow from them alone, and the risk register is owned, not just written.

Failure mode: the sandbox becomes the production environment in disguise — real cases start flowing through "just to test". You lose the ability to break things safely. Keep the sandbox unambiguous.

Stage 5 — Live

Run the process reliably, and improve it.

The process is accessible to end users. Incoming requests are triaged into bug reports and feature requests (Part 7 describes how). Change management applies (also Part 7). A changelog is maintained publicly so researchers and staff can see what has changed recently and why.

This stage has no exit. It does have a recognition: if the process stops changing, stops having users, or stops having an owner, the platform team proposes retirement. Live is a sustained commitment, not a resting state.

Two common failure modes. Development continues unbounded. The process owner keeps asking for new fields, new branches, new automations. Without change management the system drifts. Institute a monthly change-request cadence with explicit triage. Nobody maintains it. The process owner moves roles, the successor is never properly onboarded, documentation decays. Institute ownership transitions: when a process owner leaves, there is a named handover with a checklist. Documentation review is on the new owner's calendar before they have the keys.

The complexity-and-maturity assessment, briefly

Run this at pre-scan and again at every annual review. Two axes, each a crude 1–5.

• Complexity. How many actors are involved? How many decision branches exist? How many systems does it touch? How many regulatory frameworks apply?
• Maturity. How well does the process owner understand their own process? How aligned are the stakeholders on what the process is? Is there consensus on acceptance criteria?

A low-complexity / high-maturity process is a candidate for fast-tracking — skip or compress stages 2 and 3. A high-complexity / low-maturity process is either a multi-quarter engagement or a "not yet". The assessment is a conversation tool, not a score that generates an automatic verdict; the point is that the team and the process owner agree on which quadrant they are in before committing.

---

Part 4 — Process catalogue

Warning

Summarised from internal documentation with AI

Six processes are live on our platform. Two — DMP and ERB — are described in depth because they carry the most weight and illustrate the patterns best. The other four are sketched as cards.

DMP — the Data Management Plan process

The DMP is the first cockpit process a researcher encounters when starting a project. It feeds most of the others, and it carries the largest share of automation complexity by a wide margin.

Purpose. Capture, in a single authoritative record, how a research project will handle data: what kinds of data, where it comes from, where it will be stored, who will access it, what legal basis applies, what happens to it when the project ends. The DMP is both a compliance artefact (funders increasingly require it; institutional research-data policy requires it) and a coordination artefact (downstream processes read it to know what they need to do).

Actors. Researcher drafts the DMP. Data steward reviews, asks clarifying questions, approves or returns. Supervisor (for student and PhD cases) confirms the DMP represents the project accurately. Platform automations fire cross-process triggers on approval, generate the approval letter, route to follow-up processes.

Intake. A single form, structured as a sequence of sections: project facts (linked to the research project registration where one exists), data facts (types, sources, volumes, personal-data categories), handling facts (storage, access, transfer, retention), and funder-specific questions (one section per funder template). The form is layered. An initial intake captures enough to create the case and route it; a secondary form, triggered once the data steward engages, captures the fuller record; a third form is used for updates over the project's lifetime. Asking a researcher to complete a 40-question form cold will empty the pipeline.

Workflow. Linear at first sight: draft → submitted → under review → approved or returned. In practice, under review cycles with the researcher through several rounds of clarification, which is why the rendering of comment history and change-tracking in the portal is a first-order UX concern. A returned DMP re-enters draft with the reviewer's comments attached. An approved DMP becomes an immutable record; subsequent changes create a new version linked to the old one, not a mutation of the original. The immutability is worth the engineering effort; it makes the audit story and the cross-process event story simpler.

The cross-process triggers. When a DMP is approved, automations inspect its content and fire zero or more follow-up process creations.

• If personalData ≠ "none" and the project is research (not student), fire an ERB case with the DMP context attached.
• If the data flow involves transfer to or from a non-institutional party, fire a Data Agreement assessment.
• If the data flow involves transfer outside the EEA, add a specific transfer-mechanism question to the Data Agreement assessment.
• If the project declares high-volume or sensitive storage needs, recommend the appropriate storage environment (P4: recommend, not provision, not control).

Each trigger carries a minimal event payload: the DMP reference, the relevant subset of shared fields, the researcher's identity, and a correlation id. The downstream process reads the event, pre-fills what it can, and engages the next reviewer. The researcher does not have to re-explain the data facts to the next office. That is the value.

Auto-approval with spot-check sampling. Not every DMP needs a data steward's hand. For projects with non-sensitive data, well-known storage patterns, and no external transfers, the risk profile is low enough that automated approval is defensible. Incoming DMPs are classified against a ruleset and clean ones are auto-approved. A random percentage is then flagged for spot-check; a data steward reviews them. This buys quality assurance on the ruleset (if spot-checks keep finding errors, the ruleset is wrong) and researcher trust (the auto-approval is not a rubber stamp because the sample cannot be predicted). The spot-check rate is a tunable parameter — start high (20–30%) while the ruleset is new and lower it as confidence grows.

Approval-letter generation. On approval the system generates a PDF approval letter and attaches it to the case. Two lessons learned the hard way: generate from a single canonical template, not from a Word-document copy-paste pipeline (the two will diverge, and the divergence will be found by an auditor); and treat the PDF generator as a testable component with examples-based tests covering each branch (funder-specific sections, personal-data sections).

Institutional exceptions. Some departments have carved-out rules that differ from the institutional default — for example, a department whose nature of work places all its student projects outside the standard ERB workflow. Each carve-out gets a row in a documented table (which rule, which department, why, when it was negotiated, who owns the review). When the rule changes, the table is the artefact that updates; automations read the table.

Approximate size and shape of the DMP configuration. ~50 custom fields, of which ~12 are on the shared spine. ~40 automation rules, covering auto-approval, cross-process triggers, spot-check sampling, approval-letter generation, reminders, and a long tail of edge-case handling. ~6 forms, covering intake, revision, update and approval-letter generation. Cross-process events emitted: to ERB, to Data Agreements, to storage recommendation, to project registration.

ERB — the Ethical Review Board approval process

ERB is the canonical downstream process and it is where the coordination value of the cockpit is most visible to researchers. The single most common piece of unsolicited positive feedback we hear about the cockpit is "I didn't have to re-enter my DMP information in the ERB form."

Purpose. Obtain ethics board approval for research involving human subjects, personal data, animal use, or other regulated categories, before research activity begins.

Actors. Researcher submits the ERB request. Supervisor (for student cases) confirms the request and takes on supervisory responsibility, which affects the approval pathway. ERB secretary triages incoming requests and routes to reviewers. ERB reviewers are the board members who evaluate the substantive questions. Platform automations handle the supervisor-confirmation loop, SLA reminders, routing.

Intake routes — two entry points.

• Via DMP — the majority. When the DMP declares personal data or another flag that requires ethics review, a DMP-triggered ERB case is created with the relevant context pre-filled. The researcher confirms, adds ethics-specific detail, submits.
• Direct — for projects without a DMP (e.g. a short study below the DMP threshold) or for retroactive cases. The direct route is the same form, with fewer pre-filled fields.

The dual-entry pattern is worth emphasising. Every downstream process on your platform should support both the upstream-triggered and the direct-intake path. The upstream-triggered path is the strategic one; the direct path is the pragmatic one. Supporting only the strategic path blocks legitimate work; supporting only the direct path loses the coordination value.

Supervisor-approval loop. Student and PhD research routes through a supervisor before reaching the board. The supervisor gets a notification, reviews the request, and either confirms (the case proceeds) or returns (the case goes back to the student with comments). Implementation: a workflow state (pending supervisor approval) and an automation that emails the supervisor with a direct action link. The supervisor's confirmation is modelled as a state transition on the student's case, not as a separate Jira case, so the audit trail stays in one place.

SLA management. ERB is the most SLA-sensitive of our live processes. Researchers have submission deadlines; the board meets on a cadence; missed clearances delay research. The ERB workflow is therefore instrumented with automated reminders at 7/3/1 days before the next board meeting's submission cut-off, and the expected decision date is surfaced on the case visible to the researcher. SLA fidelity is a feature users notice.

Upstream feedback to DMP. ERB sometimes reveals a risk the DMP did not adequately describe. The DMP revision trigger lets an ERB reviewer send the case back not only to the researcher but also to DMP for revision. Small cost in cycle time, large gain in record accuracy.

Approximate size and shape. ~15 custom fields, mostly shared with DMP. ~25 automation rules, covering intake routing, supervisor loop, SLA reminders, and the upstream DMP-revision trigger. ~6 forms. Cross-process events received from DMP; emitted back to DMP for revision and to storage recommendation for low-risk fast-track cases.

Process cards

Shorter descriptions of the other four live processes. Enough to orient, not enough to re-implement.

Data Agreements. Triggered from the DMP's data-flow section, or directly when a researcher knows they need a data sharing or joint-controller agreement. The process decomposes into four phases per the document-handling table in Part 4: information gathering (intake form, pre-filled from the DMP where possible), document drafting (typically cross-institutional; the hardest phase, often needing external-collaborator access to the documentation substrate), document approval (internal sign-off by the privacy team), document signing (qualified e-signature). Owned jointly by the privacy team and the data stewards. Characteristic shared fields: agreement type (Data Sharing / Joint Controller / other), other-party identifier, lawful basis. Characteristic automation: on DMP approval, if the DMP declares cross-institutional data flow, create a Data Agreements case with the data-flow facts pre-filled.

Research Contracts. Research contracts (commissioned research, consortium agreements, NDAs preceding proposals) are legally weightier and usually externally-led, with the counterparty often providing the paper. The intake form captures contract type, parties, rough value, and timeline. The workflow branches on whether the contract is drafted by the institution or provided by the counterparty. Owned by the research support legal team. Characteristic shared fields: counterparty identifier, funding body (where applicable), start/end dates, principal investigator. The interesting design question is whether and how research contracts should be triggered by research project registration; we have chosen "recommended, not required" because many research contracts precede a formally-registered project.

Research Project Registration. A research project in the cockpit is a lightweight entity that other processes can attach to. It records the project's identity (name, PI, department, funding source, dates) and serves as a focal point for the downstream obligations (DMPs, ERB approvals, agreements, storage allocations) that accumulate over a project's life. It is deliberately lightweight; we do not try to capture every fact about a project here, because most facts are owned by other offices and other systems. The cockpit's project registration is a coordination record, not an ERP-level project master. Currently owned by the platform team, with the intent to hand over to the research office once the process matures. Characteristic automation: when any other cockpit process creates a case linked to an unregistered project, the platform prompts (not forces) the researcher to create a project record.

Student Projects. A distinct intake path for student projects (bachelor, master, sometimes PhD). The split prevents "polluting" the research-project data with educational cases that have different governance needs, and lets education-specific answers in the DMP be pre-filled. Lightly owned at present; partnership with the education product area is the explicit next step. Characteristic automation: student project creation triggers a DMP request with the educational-purpose flag set, which suppresses certain questions and routes to the student-specific review pathway.

---

Part 5 — Product ownership in practice

Warning

Summarised from internal documentation with AI

The rest of this playbook is architecture. This part is what you do every day when the architecture is live. Mostly unglamorous. Mostly what makes the platform work.

The request inbox: refinement triage

Once a process is live, requests arrive — from data stewards, from ERB reviewers, from privacy officers, from researchers, from funders. Some are bugs. Some are feature requests. Some are actually changes to the process that the cockpit merely expresses. Most are under-specified.

Any platform team smaller than large will drown in this traffic without triage. Three states.

• REFINABLE. Enough context to write acceptance criteria and commit the work. The problem is named, approving stakeholders are known, and either the solution is obvious or the team can propose one.
• NEAR-REFINABLE. Most of the context is there. One or two specific questions remain — usually a decision the requester has not made or a stakeholder not yet consulted. Parked with an explicit question, not lost.
• NEEDS FOLLOW-UP. Significant gaps: a title with no description, a request implicating three offices and a policy decision none have made, an idea that is not yet a problem statement. Sent back to the requester with the questions that need answering.

The vocabulary is social, not technical. A request parked as NEEDS FOLLOW-UP is not ignored; the requester is told precisely what is missing. Requesters trust the queue more when triage is visible; stakeholders respect it more when its state is legible.

Triage runs weekly; new requests sit at most seven days. Requests in NEEDS FOLLOW-UP for over a quarter get escalated — direct call to the requester, or closed with a note that it can be reopened. An indefinite NEEDS FOLLOW-UP backlog signals a team being polite when it should be direct.

The impact analysis template

Any change request that touches a live process gets an impact analysis before being committed to a sprint. Our template has four rows that are filled in every time, because every change touches all four.

# RCJB-XXX: [short title]

**Requester:** [name, on behalf of which office]
**Date:** [date]

## Summary
[1–3 sentences. What the change is, in terms an outsider can follow.]

## Impact analysis

### 1. Custom fields
- Which fields are added, removed, or changed type?
- Is any field on the shared spine affected? If yes, which other processes read it?
- Data-migration considerations for existing cases.

### 2. Forms
- Which forms need updating?
- Are validation rules affected?
- Are pre-fill sources affected?

### 3. Automations
- Which automation rules reference the changed field / workflow state?
- Any cross-process triggers affected?
- Test cases: qualifying and non-qualifying examples.

### 4. Documentation
- Which Confluence pages need editing?
- Which screenshots are now stale?
- Who owns each page that needs updating?

## Decisions needed
[Explicit list of open questions, each with the named person who owns the decision.]

## Execution plan
[Phases: preparation / config / documentation / verification.]

## Risk summary
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|

An example of this template in anger: a request to change an ERB form question from radio buttons (price ranges) to a numeric input. On the face of it, a 20-minute form edit. The impact analysis surfaces that the custom field's type has to change (radio → number), which is destructive to historical data; that the form question needs new validation rules (min 0, no decimals? cap?); that an automation uses the field for fast-track approval conditions and will break the moment the field type changes; that the documentation page explaining fast-track eligibility is now inaccurate; that the field is referenced by one ticket's implementation history that should be linked for traceability.

A 20-minute edit is really a two-hour exercise across six artefacts, and the impact analysis is the artefact that prevents any of them being forgotten. You will feel silly writing a four-row analysis for a two-line change; write it anyway. The one time you would have skipped it is the time it would have caught the bug.

The decision record

Some changes are not technical but policy-level: a rule changed, an exception added, an approval threshold tuned. These do not get a full impact analysis but do get a short decision record, typically half a page covering what was decided, who decided it, why (the reasoning, one paragraph), what it means operationally (the change to automations, forms, documentation), what to test, and what open questions remain.

An example: adding a sixth condition to the DMP auto-approval rule so that DMPs declaring minors as participants cannot be auto-approved, even if all other conditions are met. The decision record captures that the owning process owner signed off, the proposed wording of the blocking comment shown to the researcher, the question of whether 16–17 year olds should also be blocked (resolved: no, matching the existing ERB fast-track threshold), and the test plan.

Decision records are linked from the changelog. Read as a series they are the best narrative of how the platform actually evolves.

Documentation audit

The documentation substrate rots in predictable ways. Pages get outdated when automations change, links go stale when pages move, templates get half-filled and left that way, ownership transitions are not always recorded. The audit is how we keep it current.

We run one audit per year, covering every process page. It takes about a week of focused work and follows a tight taxonomy.

1. Redundancy. Same concept explained on multiple pages, with inevitable drift. Action: consolidate or cross-reference.
2. Unclarity. Prose that says the right thing in a way a reader cannot parse. Action: rewrite with a worked example.
3. Contradiction. Two pages say different things about the same rule. Action: find the owner, get a decision, update both.
4. Conceptual gap. The page does not answer a question a reader is likely to have. Action: add a section or a link.
5. Draft / stale content. Placeholder text, unresolved TODOs, screenshots from two versions ago. Action: finish it or archive it.

The audit produces a prioritised list: which issues are high-impact (a researcher or reviewer will hit this within the next quarter and be misled), which are medium (annoying but not misleading), which are low (cosmetic). The platform team works through the high-impact items within the following quarter; the rest gets scheduled or consciously deferred.

Numbers help. In our last audit: 374 pages reviewed, 50 issues identified, of which 21 high-impact, 20 medium, 9 low. Keeping the score makes the audit accountable, the same way a bug count keeps bug fixing accountable.

Change management

Change management is not just for changes to live processes. It is for everything a researcher or reviewer might see differ from yesterday. Three doors.

• Platform-visible changes — something about the user's experience differs (a question added, a workflow state renamed, a notification text changed). Goes through a changelog entry, a documentation update, and — for researcher-visible changes — a communication through the appropriate channel (portal announcement, newsletter, targeted email to active cases).
• Internal-visible changes — something only the platform team or a process owner notices (an automation refactor, a reorganisation of shared fields, a new registry key). Changelog entry, documentation, no researcher communication.
• Hot-patches — an urgent fix to a live issue (a broken automation, a formulation that is actively misleading researchers). Applied immediately, documented afterwards, with a post-incident note.

The changelog is public. Staff and researchers can subscribe to it. The publicness matters more than the content; when stakeholders can see that changes are logged and narrated, they stop asking whether things have changed.

Change-advisory rhythm

The cockpit touches enough offices that a standing change-advisory group is useful. Ours is monthly, with one representative from each owning office (data stewards, ethics board, privacy, legal, research office). The platform team runs it. The agenda is the queue of significant changes since the last meeting and those proposed before the next. Purpose is awareness, not approval; each change has its own process owner. Each office sees what is coming and flags anything that interacts with their own work.

This meeting is cheap and high-value. Skip it at your peril; the cost of surprising the ethics board with a change to the DMP-to-ERB trigger dwarfs the cost of a monthly half-hour.

Handling incidents

Things break. Automations misfire, forms reject legitimate submissions, cross-process triggers don't fire when they should. How the team handles these is as visible to users as any design work.

1. Stop the bleed. If the incident is creating bad outcomes at scale (misdirected cases, lost data, wrong letters going out), disable the offending automation or form immediately. A temporarily-disabled feature beats a feature that is actively wrong.
2. Explain visibly. Within hours, not days: "We've identified an issue with X, we've paused it, here's what to do meanwhile."
3. Fix the root cause. A broken automation is usually a symptom of a missing test case or an under-specified shared field. Fix the test case and the field, then fix the automation.
4. Post-incident note. Written, archived, linked from the changelog. A learning document, not a blame document. What happened, what we did, what we will do to prevent recurrence.

The post-incident note is what most teams skip. Don't; future-you debugging a similar failure in eighteen months will thank present-you for the fifteen minutes.

Working with process owners

Most process owners are not technical. Data stewards think about data protection, ethics reviewers think about ethics, legal counsel think about contracts. None of them wake up wanting to think about Jira automations. The platform team's job is translation: take a technical constraint, explain it in the owner's vocabulary; take a domain concern, translate it into a design question. Do not demand owners learn the substrate's particulars.

Two habits help. Write the owner's name on everything they own. The documentation page, the change request, the decision record. The name on the record signals respect and creates accountability symmetrically. Bring options, not verdicts. The process owner is the domain expert, the platform team is the substrate expert; neither should decide unilaterally.

The PO's calendar, in rough proportions

Refinement and triage of the request queue: 20%. Change management and advisory: 10%. Process onboarding (the ETDDDP work on new processes): 20%. Documentation and audits: 15%. Incident response and root-causing: 10%. Roadmap and stakeholder alignment: 15%. Your own work (design, architecture, writing): 10%.

Your proportions will differ. What matters is that documentation and refinement are not line items you sacrifice when sprints get tight; they are the invariants that make everything else sustainable. At 3% documentation you are in documentation debt; at 0% refinement you are in requester-trust debt. Both compound.

---

Part 6 — Getting started at your institution

Warning

Summarised from internal documentation with AI

For an early-stage product owner or service designer asked to stand up something like this at your own institution, this part describes the first ninety days of deliberate work. The goal of the first ninety days is not to have a cockpit. It is to have enough scaffolding that building one for real has a chance.

The single most important piece of advice: start with one process, not the platform. A platform without a process is an empty cathedral. A process without a platform is still useful. Let the process drive.

Weeks 1–4: stakeholder map and pre-scan of the first process

Week 1. Identify the one senior stakeholder (dean of research, CIO, director of the research data infrastructure) who will sponsor this work. Without a sponsor there is no chance. Book sixty minutes; learn what they care about, what they can authorise, where they would push back.

Week 2. Map the stakeholder landscape. Name the person who fills each of these roles: data stewardship lead, ethics review board administrative coordinator, privacy officer / DPO, research contracts / legal lead, research office's project-registration lead, head of research IT, library / research-data-repository lead. Vacant or distributed roles are information: that's where the platform will have to build capacity rather than connect it.

Week 3. Choose your first process. Recommended: DMP, for three reasons — it is the root of the dependency graph (every other cockpit process is downstream of it), it is where researchers feel the coordination win most directly, and the DMP vocabulary is increasingly standardised (funder templates, maDMP), so design decisions land in reasonably well-trodden territory. Meet the process owner — not their team, the owner. Forty-five minutes. Ask: what is the current process, what is broken about it, what have you already tried.

Week 4. Write a one-page pre-scan: process name, owner, stakeholders, as-is summary, top three pain points. Add a complexity-and-maturity assessment (Part 3). Share with the sponsor. Get their go / no-go.

Output: a written commitment to proceed, a named process owner, a named platform-team lead (probably you), and a rough budget/capacity commitment for the quarter.

Weeks 5–8: pilot one process end-to-end

Do not try to build the platform in these weeks. Build one process, on whatever substrate you can move fastest on.

Week 5. Stand up the substrate. If your institution has a Jira / ServiceNow / similar tool, use it. Do not procure new tooling in the first pilot. Create one project / queue / space, configure identity, create one intake form with the smallest plausible set of fields.

Week 6. Wire up the workflow: draft → submitted → under review → approved / returned. A handful of automations: notification to the reviewer on submission, notification to the researcher on approval, simple reminder on ageing cases. No cross-process triggers yet; you do not have another process to trigger.

Week 7. User-test with one researcher and one reviewer. Watch them use it. Note what they get stuck on. Rewrite the form based on what you saw, not on what they said; people are better at demonstrating confusion than naming it.

Week 8. Documentation. One page per: the process (owned by the process owner), the workflow (owned by the platform team), the intake form (owned by the process owner). Links between them. Review cadence declared on each.

Output at end of week 8: a working first process, exercised by at least one researcher. Documentation that would let another team pick it up. A short written reflection on what surprised you.

Weeks 9–12: retrospective and pick the second process

Week 9. Write the retrospective. What worked? What didn't? Which decisions are you now reconsidering? An honest assessment of how much work the first process actually took. (It will be more than you estimated. Be honest about the factor.)

Week 10. Walk the retrospective through the sponsor and the process owner. Be candid about what you learned about the organisation, not just about the system. Sometimes the learning is "this institution is not ready for more processes yet"; that is a legitimate outcome.

Week 11. Pick the second process. The ideal second process is downstream of the first; ours was ERB, directly downstream of DMP, because the first cross-process trigger is where the platform-as-coordination-layer starts to prove its thesis. If your second process is not downstream of your first, you are really building two first processes, not a platform.

Week 12. Write the second pre-scan. Revisit the principles in Part 2 and decide which ones survive your first real experience. Rewrite them in your own voice. Commit to them.

Output at end of week 12: a concrete plan for the next quarter. A refined set of principles. Sponsor buy-in for the continuation. A process owner lined up for the second process.

What you should not try to do in the first ninety days

• A detailed architecture document. Part 4 of this playbook is the result of two years of work; you will write a much worse version in the first month. Write one-page sketches and iterate them.
• A shared-field spine in advance. You need exactly one process's fields for ninety days. The shared spine emerges in the design of the second process, not the first.
• A full change-advisory rhythm. The first process does not have enough to change to justify one. Run it lightweight until there is enough cross-process activity to need it.
• Adoption at scale. A pilot with 10 researchers is enormously more valuable than a launch to 1000. Go small, go deep.
• External audit. You are not ready, your institution's auditors are not the right readers, and it will freeze your ability to iterate.

What you should always do in the first ninety days

• Make the work visible. Weekly updates to the sponsor. A running changelog from week one. A single public-to-the-institution page that says "this exists and here's where it is."
• Keep a decision log. Every non-obvious call you made, with a line on why. You will forget by month six. Future-you needs this.
• Invest in relationships with process owners. A monthly coffee, a shared-progress update, explicit appreciation when they put in effort. These are how federation (P1) is held together in practice.

Signs it is working, signs it is not

You are on the right track if the process owner is telling colleagues about the cockpit voluntarily, if researchers who used the pilot ask whether their other obligations could move onto it, if the sponsor's question has shifted from "why are we doing this?" to "how quickly can we add the next process?", and if you have made three decisions you now regret and can name what you would do differently. A team with zero regrets was not paying attention.

You are off-track if the process owner has not used the substrate themselves three months in, if researchers use the pilot once and do not return (visible in the case count), if the sponsor has stopped asking about progress, or if your team is exhausted three weeks into what was supposed to be the first month. Each has a corresponding move: re-engage the process owner, plan for low return rates, re-engage the sponsor (silent sponsors are the leading indicator of silent cancellations), and cut scope explicitly.

The rest of this playbook becomes useful as you accumulate processes. Part 3 (ETDDDP) gets real planning the second and third. Part 5 (process catalogue) gets real once you have three to compare. Part 7 (PO practice) gets real when the request inbox fills up. Part 8 (interoperability) gets real when you have something stable enough to propose exchanging with a peer institution.