Retainers

The problem

Most research groups and small-to-medium infrastructures have strong domain expertise but limited bandwidth for the strategy work that wins grants. When a funding call opens, the scramble begins: who can draft the technical narrative, how does this project connect to the group's existing work, and who owns the week-by-week progress once the proposal goes in. The result is proposals that read as wishlists rather than credible programmes — ambitions without the roadmap to back them.

What we deliver

• —Review your group's current work, infrastructure, and direction to surface where a funded project would genuinely advance things — not where it would just keep people busy
• —Map your strengths and gaps against the call text, identifying the angles that make a competitive proposal versus one that reads as filler
• —Draft the technical narrative, work plan, consortium structure, and budget justification, iterating with your team until the proposal reflects how you actually work
• —Where you already have a project running, provide the skeleton of a monitoring and reporting framework so the grant can show impact from year one

How we work

This is where the “translation layer” matters most. Grant proposals fail when the technical vision is internally consistent but opaque to the funder's review panel, or when they describe the right goals without the operational detail that makes them credible. We sit in the middle: Li brings the programme design and funder-awareness — having led multi-partner grants for DataCite and worked across EOSC, RDA, and FORCE11 — and Sara brings the semantic architecture depth to make the technical narrative precise. The result is a proposal that reviewers trust because the people who'd have to execute it wrote it.

The problem

Research grants are won on scientific vision, but they're executed on operational discipline. The PI who wrote the proposal becomes the person chasing overdue deliverables, reconciling partner budgets, and writing interim reports to the funder — work that pulls them away from the research the grant was meant to support. In multi-partner consortia this compounds: someone needs to hold the project's timeline, flag dependencies between work packages, and make sure the final report doesn't get written in a panic the night before the deadline.

What we deliver

• —Deliverable tracking and milestone management against the grant agreement, with monthly status summaries for the PI
• —Partner coordination: scheduling, progress check-ins, dependency resolution between work packages
• —Interim and final report drafting against funder templates, pulling evidence of progress from the project's own records rather than starting from a blank page
• —Budget-light oversight — reconciling actuals against the approved budget, flagging under- or overspend before it becomes a problem
• —Risk log maintenance and escalation, so issues surface while there's still time to act

How we work

This is pure operations, not strategy, and we're explicit about that. Li's programme management experience — leading a 7-partner DataCite grant with deliverables to the Wellcome Trust and Templeton Foundation — means the reporting, budgeting, and timeline discipline is already field-tested. What makes it work is consistency: we use the same systems your partners already have (shared drives, Slack, project trackers), not a new toolchain they have to learn. The goal is for the PI to see a clean status dashboard once a month and trust that everything between those updates is being handled.

The problem

Implementing PIDs is one thing; getting people to use them is another. Many organisations complete an integration project — DOIs minted at deposit, ORCIDs linked to author records, RORs on institutional profiles — only to discover a year later that coverage has plateaued or that identifiers in the repository aren't being cited by the community they were meant to serve. Without measurement, nobody knows whether adoption is succeeding, stalling, or failing, and without evidence it's impossible to argue for the next investment.

What we deliver

• —An initial audit of your current PID landscape: what identifiers exist, where they're recorded, how long they've been running, and what the coverage looks like at the level of individual records
• —A monitoring data pipeline — lightweight, automated, built to run on a schedule you own — that captures coverage, resolution rates, citation-linked usage, and any drift between the identifiers assigned and those actually resolvable
• —A baseline report with visualised coverage broken down by identifier type, collection, or workflow step — so you can see the shape of the problem before deciding what to fix
• —Quarterly impact reports that track trends, flag regressions, and include a brief narrative interpretation (not just charts): which metrics improved, which ones didn't, and what the data suggests about why
• —A handover package so a non-technical team member can maintain and extend the pipeline without Semantify running it forever

How we work

Monitoring is the “adopt” phase of our three-act structure — it only makes sense if you've already done the design and build work, and most of our clients come to this retainer after completing a PID implementation with us or elsewhere. Li's research background is directly relevant here: his PhD work examined why CERN physicists didn't reuse deposited data, which gave him a methodology for diagnosing adoption failures that goes beyond what any dashboard alone can show. The pipeline surfaces what happened; his analysis interprets why.