M1 → M36 · 36-month tracker

Task & milestone tracker

Every task in the register that touches the knowledge base, sorted by start month. Filter by how deep our hands are in it.

Work package

Timeline

M1
M7
M13
M19
M25
M31

Tasks in detail

The foundation stone. Define the minimum viable semantic model for services, technologies, facilities and workflows; pick and align controlled vocabularies; set the PID strategy (ORCID / ROR / DOI / PIDINST) that every later record hangs off.

Bio-Hub implementation outline, item 3: build iteratively — desk-based model → Expert Group stress-test → revision → small-scale pilot → network-wide rollout — with updatability and distributed ownership as day-one requirements, not an afterthought.

See the full implementation outline →
What we produce
  • Minimum viable semantic model (entities, relations, cardinalities)
  • Controlled vocabulary + ontology alignment register
  • PID strategy and identifier minting rules
  • Node-facing metadata templates
  • Validation / SHACL-style conformance rules
Input required before this moves
  • Persona intents and exemplar queries from T1.2 — they define what the model must be able to answer
  • Backend format constraints from KTH (T4.1): graph vs. document, embedding strategy
  • Decision on ontology base: EDAM-Bioimaging vs. custom Euro-BioImaging services ontology vs. hybrid
Leads
Erika, Feriel, Bio-Hub AI4Access team
Participants
Sudeep
GA lead / partners
Bio-Hub + Med-Hub (co-leads) · ERIC, KTH
Due
D2.1 (M12)
Depends on (1)
T1.2
Feeds (17)
T1.2T1.3T1.4T2.2T2.3T2.4T2.5T3.1T3.2T4.1T4.3T4.4T5.1T5.2T6.1T6.2T8.3

Deliverables & milestones

Highlighted rows are ours to deliver.

M3D8.4First Data Management PlanNeeds the data-inventory direction before the model is settled.
M6D7.1DEC strategy & brandingWebsite and channels launch. Context only.
M6MS6DEC channels launchedWebsite/social media live. Register calls this MS6; Part B text calls it MS7.1.
M6MS8Project Handbook & Integration/Standards PlanIncludes the T8.3 Architecture & Standards Board output this function feeds.
M6MS9KPI Dashboard operationalT8.3, alongside MS8. Register calls this MS9; Part B text calls it MS8.2. Incorporates WP7 dissemination/exploitation metrics.
M8MS7DEC metrics dashboard operationalRegister calls this MS7; Part B text calls it MS7.2.
M12D1.1Personas & virtual personasContributes ontology terms and exemplar queries.
M12D2.1Ontology-aligned data modelThe flagship deliverable. Semantic model, vocabularies, PID strategy.
M12D3.1Image analysis tool landscapeLed by Feriel; anchors on BIII.
M12D7.2Outreach & dissemination materialsContext only.
M12MS1First Navigator prototypeConsumes an early slice of the knowledge base. Register: MS1; Part B text: MS1.3.
M12MS3Node integration pilots launchedMappings against national systems begin.
M18D2.2Harmonised Node datasetThe collection dashboard must exist well before this.
M18D2.5.1INFRA-SERV integration analysis & interface specCrosswalks supplied here; register calls this D2.5.
M18D4.1AI agent backend + hybrid KBHard consumer of D2.1/D2.2. Schema must be frozen by ~M15.
M18D5.2Facility pilot integrationFacility-system mappings.
M18D6.1Provenance & trust frameworkProvenance fields must already be in the schema.
M18D7.3Mid-term exploitation & sustainability roadmapDecides post-M36 funding/licensing for the Navigator.
M18D7.5DEC strategy / stakeholder & KER map, updatedContext only.
M18D8.1Policy Brief 1Context only.
M18D8.3IPR register & exploitation alignment reportContext only.
M18D8.5DMP updateData inventory refresh.
M18MS5Node-staff training rollout beginsNeeds the update protocol and SDK docs finished first.
M19MS4Facility pilots running
M24D2.3Website content packageMachine-actionable, provenance-linked.
M24D2.4Update protocolSustainability of the knowledge base.
M24D3.2AI-ready service cataloguePlus MS2 integration module.
M24D6.3Green AI strategyContext only.
M24MS2Catalogue integration module
M30D3.3Service selection & augmentationCurated and validated here, built by KTH.
M30D6.2Explanations & traceabilityDraws on the provenance graph.
M36D1.2Final user testing & usability reportContext only.
M36D2.5.2Cross-RI integration demonstratedRegister calls this D2.6.
M36D3.2Catalogue maintained to project endT3.2 runs M1–M36.
M36D4.2Continuous learning & updatesShares the versioning model built for the update protocol.
M36D5.1Node platform integration
M36D5.3Training & adoption playbookTurns the update protocol and SDK into something a Node can run.
M36D6.4Regulatory alignment reportContext only.
M36D7.4Final exploitation & sustainability planContext only.
M36D8.2Policy Brief 2Context only.
M36D8.6Final DMP

Blockers & required inputs

No Node data collection dashboard exists

critical

T2.2 asks 39 Nodes to submit structured service descriptions. Without a real intake surface — templates, validation on entry, per-Node status, review queue — collection degrades into spreadsheets by email, and the harmonisation cost lands here at exactly the moment D2.2 (M18) is due.

Blocks
T2.2T2.3T2.4D2.2 (M18)
Needs from
Build decision + developer time; requirements from the WP2 team
The ask
Agree by ~M4 whether this is built in-house, extended from the Access Portal, or bought. It has to exist before the model is finalised, because the intake form is the model made visible.

Ontology base is undecided

critical

T2.1 must pick between extending EDAM-Bioimaging, formalising the 2022 harmonised services ontology, adopting foundingGIDE recommendations, or a hybrid. Every downstream annotation, crosswalk and adapter schema inherits this choice, and reversing it after M12 is expensive.

Blocks
T2.1T3.2T2.5T3.4T4.4
Needs from
Expert Group + Bio-Hub/Med-Hub/KTH agreement
The ask
A time-boxed decision workshop before M6, with a written rationale. Recommendation: OLS-resolved terms, EDAM-Bioimaging for analysis, a small Euro-BioImaging services extension for access concepts.

Schema freeze date not agreed with KTH

high

T4.1 delivers the backend and hybrid knowledge base at M18 and depends on T2.1–T2.4. If the model is still moving at M15, KTH builds against a shifting target and both sides absorb rework.

Blocks
T4.1T4.4D4.1 (M18)
Needs from
KTH (Wei and team)
The ask
Agree a v1.0 schema freeze at M12 with a versioned change process afterwards — additive changes only until M18.

Unfilled posts across dependent tasks

high

The register lists 'new hire' on T1.1–T1.4 and 'Aman till new hire' on WP4 tasks. Inputs from this function land on people who are not yet in post, and the WP1 persona work that shapes the data model is among them.

Blocks
T1.2T4.1T4.4
Needs from
ERIC + KTH recruitment
The ask
Confirm start dates so it's known whether the T1.2 intent taxonomy will really be usable before the T2.1 freeze.

Authority rules for conflicting sources

high

Node submissions (T2.2), website content (T2.3) and facility systems (T5.2) will disagree about the same service. Without a precedence rule and a sign-off owner, the knowledge base contains contradictions the Navigator will confidently repeat.

Blocks
T2.2T2.3T5.1T5.2T6.2
Needs from
Hub content process owners + Node coordinators
The ask
Define a source precedence order and a named authority per record type, inside the T2.4 update protocol.

Personal data in past-project evidence

watch

Evidence objects built from 1,100+ logged user projects carry applicant and facility-staff details. GDPR and AI Act obligations under T6.4 must be settled before ingest, not after.

Blocks
T2.3T6.4T8.4
Needs from
Ali (T6.4), Thea/Linda (T8.4)
The ask
Ruling on anonymisation versus consent for past-project evidence, in time for the M18 DMP update.

CMS / structured export access

watch

T2.3 assumes website resources can be parsed at scale. Screen-scraping the public site is fragile; a structured export or API from the EWP team is worth weeks of effort.

Blocks
T2.3
Needs from
EWP team
The ask
Confirm what structured export exists before committing to a parsing approach.

Grant Agreement risk register

The 9 critical risks and mitigations as registered in the signed Grant Agreement (GAP-101289393) — formal, consortium-wide, and owned by WP8. Kept separate from the blockers above, which are this function's own operational read of what's in its way.

R1

AI model errors and hallucinations leading to inaccurate or misleading recommendations

WP6WP4Likelihood: MediumImpact: High
Mitigation
If hallucinations are detected, fallback to predefined safe answers with references; route the query to human experts for validation; mark responses clearly with uncertainty levels to avoid misuse.
R2

Delays in ontology and knowledge base integration due to complexity and community agreement

WP2WP4Likelihood: MediumImpact: High
Mitigation
If integration delays occur, Task 8.3 will establish an Ontology–Integration Task Force (WP2+WP4+WP3) who will monitor ontology coverage. High-value metadata fields would be mapped so that onboarding can proceed while full ontology terms mature.
R3

Heterogeneity of facility management systems complicates Navigator integration

WP5Likelihood: MediumImpact: Medium
Mitigation
If full integration is not possible, provide standalone adapters; publish facility-specific guidance notes; prioritise pilots that demonstrate value without requiring uniform adoption.
R4

Low engagement from Nodes in providing/maintaining data

WP2WP5Likelihood: MediumImpact: High
Mitigation
If data provision is insufficient, supplement Navigator responses with existing public information; highlight missing content clearly; shift to a lighter knowledge base model while maintaining minimum service discoverability.
R5

Limited uptake by SMEs and widening countries

WP1WP7Likelihood: MediumImpact: Medium
Mitigation
If uptake remains low, implement targeted Navigator prompts with SME/widening-specific entry points; launch dedicated social media and support campaigns; monitor and report separately on underrepresented groups to adjust strategy.
R6

User trust concerns regarding AI transparency, GDPR, or IP/confidentiality

WP1WP6Likelihood: MediumImpact: High
Mitigation
If trust issues escalate, enforce an AI-free access route; anonymise sensitive requests automatically; issue clear disclaimers and provide manual validation options for confidential or regulated cases.
R7

Environmental footprint of AI training/inference exceeds targets

WP6Likelihood: LowImpact: Medium
Mitigation
If energy use exceeds set thresholds, scale back retraining frequency; switch computations to lower-energy models; temporarily suspend high-footprint features until efficiency measures are restored.
R8

Sustainability risk: knowledge base becomes outdated post-project

WP2WP5WP7Likelihood: MediumImpact: High
Mitigation
If updates lapse post-project, reduce the scope of Navigator recommendations to the last verified dataset; acquire funding to improve static knowledge base.
R9

Coordination risks across multiple WPs and partners

WP8Likelihood: LowImpact: Medium
Mitigation
If coordination breaks down, escalate to the decision-making governance body; apply corrective measures such as reallocation of responsibilities.