WP3 preparatory discussions

Wednesday 22 Jul 2026, 09:00 → 11:00 Europe/Zurich

Link for the meeting

https://teams.microsoft.com/meet/358288484548148?p=QwqqqGudXqqJFch8HJ

Input requested from each partner - before the meeting

Please prepare short written answers (bullet points are fine, ~1 page max) and send them to the WP3 mailing list. They will be consolidated and circulated ahead of the meeting. Maybe some points are difficult to be defined now, put the information that you can propvide or put options/comments.

2.1 Technical contribution

• Expected technical contribution of your institution to WP3, mapped to tasks T3.1–T3.5 (which tasks, what role, indicative effort).
• Dependencies on other WPs (data from WP4 use cases, requirements from WP2, integration with WP5).
• Risks or bottlenecks already identified (technical, data access, legal/privacy).
• For FL node hosts (CFB, GANIL, KIT, GSI): current status of local infrastructure and constraints for hosting an FL node (network, security policies, containerisation).

2.2 Procurement and infrastructure

• Foreseen equipment or infrastructure needs linked to your WP3 tasks (GPUs, servers, storage, licences and others).
• Existing infrastructure that could be shared or reused across the consortium.
• Institutional procurement constraints (lead times, tendering thresholds) - note the end-of-July consortium deadline.

2.3 Computing resources

• First estimate of computing time and storage for your WP3 activities (model training, fine-tuning, RAG indexing).
• Whether you plan to rely on HPC clusters allocations, institutional clusters, or both.

2.4 Human resources

• Hiring needs and profiles for WP3 (engineers, researchers, etc.), with expected start dates - note the end-of-July consortium deadline. To be coordinated with the consortium.
• Personnel already allocated to WP3.
• Skills/expertise gaps that may require coordination with other partners.

2.5 Coordination and communication

• Technical contact(s) for WP3 activities at your institution (name + email) to be updated in the WP3 mailing list.
• Preferred communication channels and collaboration workflows.
• Any concerns regarding document sharing, permissions, or version management

WP3_all_partner_inputs_verbatim.pdf

WP3_minutes_20260722.pdf

WP3_preparatory_meeting_preread.pdf

WP3_preparatory_meeting_slides.html

WP3_preparatory_meeting_slides.pdf

TwinRISE WP3 — Preparatory Meeting Minutes

Meeting: [TwinRISE] WP3 preparatory discussions

Date: 22 July 2026, 09:00–10:06 CEST (online, MS Teams) Chair: Guillermo Rodríguez Llorente (HI Iberia, WP3 Lead) Minutes: HI Iberia (WP3 Lead)

Attendees (7)

Name	Organisation	Role
Guillermo Rodríguez Llorente	HI Iberia (HIB)	WP3 Lead / Chair
Rachid Guerchouche	INRIA	WP3 Deputy
Andreas Lintermann	FZJ	Participant
Rakesh Sarma	FZJ	Participant
Erik Bründermann	KIT	Participant
Julian Gethmann	KIT	Participant
Sara Narteni	CNR	Participant

Not present: CFB (Centre François Baclesse), GENCI, UCAEN (Université de Caen). Their written inputs remain pending.

1. Purpose and context

The Chair recalled that this meeting follows the actions agreed at the previous meeting: the organisation committee (Adnan) requested WP3 inputs by the end of July so that hiring profiles and computing needs can be centralised at project level. Inputs had been received from HIB, INRIA, KIT and CNR (plus FZJ); inputs from CFB, GENCI and UCAEN are still pending. All inputs received have been consolidated into a single document on the Indico page.

The Chair highlighted CFB as particularly important, as it will host a federated-learning (FL) node and holds the clinical data; INRIA had flagged access to clinical data as a potential blocker.

2. FL infrastructure, clinical data and node deployment (T3.1)

• KIT noted that WP2 already has access to the relevant data, and understood that CFB already operates federated learning with hospitals; the idea is that this knowledge/node setup would be transferred to other node hosts. KIT would act as host of one accelerator-side node.
• INRIA stressed that with federated learning the data stays where it is, so there is no data-transfer risk; the real effort is the governance and bureaucratic process of installing a node, especially in clinical settings (authorisations from each hospital's IT direction / legal teams). INRIA has deployed nodes in hospitals in another project; timelines depend heavily on each partner's reactivity. The discussion with clinical and research partners should start now to avoid delays at deployment time.
• It was agreed to distinguish the medical side from the accelerator side: no particular issue is expected for accelerators; the medical side needs to be checked with the hosting partners (not present today). Since some clinical centres may already be used to sharing data, this could be straightforward, but it must be confirmed.
• T3.1 starts at M3, so starting the legal/governance groundwork before project start would accelerate it. Flagged as a key point.

3. Meaning of "deputy" (WP / task level)

Responding to a question raised by INRIA's legal team, the Chair clarified: every WP and task has a leader responsible for deliverables; the deputy is a co-leader who takes over if the leading partner leaves the consortium. The role has more legal implication at WP level; at task level it mainly identifies who would take the lead if a partner leaves. Technically, lead and deputy are typically the partners with the largest effort in that task.

4. Partner summaries (roles, compute, hiring)

HIB — Leads T3.2 (agentic/LLM) and T3.5 (security); participates in T3.4. Compute: own cluster for development, then EuroHPC / FL infrastructure for training once deployed; plans to add servers to its cluster (own cost, not a project procurement), but server prices are rising sharply with the AI boom (sometimes doubling), making 6-month planning difficult. Hiring: a new engineer was hired two weeks ago (physics & nuclear engineer, experience with co-development on industrial/particle accelerators), being trained in LLM basics and MLOps this month; other team members are already in-house. Interns (Master's theses) and possible industrial PhDs foreseen.

INRIA — Leads T3.1; deputy T3.5. Effort: 32 PM in WP3; plan to hire someone at ~80% on the project plus another project, keeping the same person across the full 48 months. Hiring: a Senior Research Engineer (ML/MLOps, security background); hiring to start in August, expected on board at the beginning of 2027; a candidate is already identified (former INRIA, contract ending), subject to the standard open-offer process; possibly available before project start, paid on another project and then switched. Infrastructure: uses GENCI/EuroHPC academic allocations; no extra procurement; FL deployed on the nodes; the FedBioMed team (currently on holiday) has prior deployment experience and foresees no special needs. No blocking point.

FZJ — Leads T3.4 (RAG and interoperable pipelines), bringing interTwin / iTwin-AI expertise; supports T3.1 (training, HPC) and T3.2 (extending iTwin-AI with MCP interfaces for agents). Effort: 24 PM for the WP. As an HPC centre, has in-house resources; estimates 16–20 A100/H100 GPUs for testing/development, applying for additional HPC resources if needed. Hosts the JSC (Jülich Supercomputing Centre) cloud, relevant for deployment — use for the project under discussion. Hiring: a senior researcher (ideally postdoc) to start ~M3 (March 2027); in-house expertise (Rakesh Sarma + one more) exists but a new hire is needed as they are on other projects.

KIT — Mainly end-user; leads the use case in WP4. Combined effort WP3+WP4 ≈ 48 PM; a PhD student finishing this year (HPC background) fits the WP4 role. For T3.3 (explainability/reliability, led by CNR), KIT will hire an ethics / AI-Act expert in another institute for 12 months, concentrated in the first project year to build ethics in from the start; after 12 months no further full-time KIT personnel, though the lead will remain involved in meetings/checks. KIT already worked with the CNR colleagues on the questionnaire. Facilities: Scientific Computing Center plus local large storage and computing (accelerator facility).

CNR — Main role T3.3 (explainability, reliability). No specific hardware procurement foreseen; will not train models from scratch but work on top of pre-trained models with in-house resources; compute needs to be assessed once data/model sizes are known. Hiring: a new research position from January (project start); the Italian process is slow, so expected filled by ~June (to be Sara Narteni herself); further hires possible later.

5. AI factories / EuroHPC access

KIT raised the need to involve the EU AI factories. FZJ noted Jülich is part of the AI-factory effort . It was suggested that HIB, as a company, apply for AI-factory resources (favourable for reporting). HIB is aware of the Barcelona Supercomputing Center (BSC) AI factory, where SMEs can apply, and will do so; requirements may have changed. FZJ noted AI-factory access for companies is usually quick, though it depends on the call and whether a review is required; importantly, even FZJ must apply for access (resources are owned by EuroHPC), and the application process is common across EuroHPC centres (same form). Caveat: a PI may only hold one EuroHPC project at a time (to be confirmed for AI factories); otherwise other consortium members can act as PI.

6. Collaboration tools

Shared Git for code and CERNBox for document sharing (proposed by the organisation committee). On meeting/file tools: INRIA uses SharePoint and Teams in other EU projects with no restriction (occasionally obliged to use a government video tool for meetings they host). FZJ is fine with Teams for meetings but sensitive data must be stored on a European server, i.e. not Microsoft SharePoint (US-hosted); European alternatives exist. Final choice of the shared platform is for the organisation committee (noting CERNBox is operated by CERN, outside the project).

7. Consortium agreement

The consortium agreement (CA) is in the process of being signed; partners' legal departments are handling comments, one of which relates to the Data Transfer Agreement (DTA).

8. FL-node questionnaire and preparatory effort

• INRIA will prepare a short technical questionnaire for node hosts (network constraints, security policy, infrastructure), with its FedBioMed engineers once back from holiday; work planned for August, then circulated to the hosts so the deployment configuration is known in advance.
• Effort before project start (raised by KIT): realistic preparatory effort is limited before the project officially starts and personnel is allocated. HIB confirmed it cannot commit much effort beforehand; current effort is these meetings plus kick-off preparation (presentations/courses). Expectations must be clarified with the organisation committee. KIT considered the FL-node specification a manageable preparatory task and suggested efficient on-site "software sprints" (e.g. an engineer visiting sites, as done with GSI to install the JuML/JEF framework) rather than many back-and-forth meetings. FZJ recalled the AI introductory courses planned for the kick-off as part of preparation.

9. Central virtual test environment

Following a KIT question, a central virtual test environment should be provided centrally by TwinRISE. Options discussed: INRIA's FedBioMed dataset/testbed made available for tests before node deployment, and/or the FZJ JSC cloud (subject to the ongoing discussion). JSC cloud access is simple — registration in FZJ's system and assignment to a project, with a fast review (a couple of weeks at most). To be defined in the WP requirements / first task.

10. interTwin / MCP

The use of interTwin and MCP (linked to WP2 requirements) should be clarified during training. FZJ (Andreas Lintermann) participated in the interTwin project and confirmed all interTwin code is published on GitHub, so there is no access problem for the WP3 work.

Decisions

• Start the clinical-data governance / node-deployment legal groundwork before project start to protect the M3 start of T3.1.
• No WP3-specific procurement; partners use existing infrastructure (HIB's cluster expansion is at its own cost, outside the project budget).
• Avoid US-hosted SharePoint for sensitive data; adopt a European-hosted solution (final platform decided by the organisation committee).
• Consolidate hiring and computing needs and forward them to project management.

Action items

#	Action	Owner	Timing
1	Prepare FL-node technical questionnaire (network, security, infra) and circulate to node hosts	INRIA (FedBioMed team)	Draft in August 2026
2	Start clinical-data governance / legal groundwork with CFB and other medical hosts	WP3 Lead + INRIA + CFB	Before project start
3	Chase pending inputs from CFB, GENCI and UCAEN	WP3 Lead	Short term
4	Consolidate WP3 hiring & computing needs; forward to project management	WP3 Lead	End of July 2026
5	Check AI-factory / EuroHPC access process and requirements (incl. BSC); note one-PI-per-project rule	HIB; FZJ	After summer
6	Define the central virtual test environment (FedBioMed testbed and/or JSC cloud)	INRIA + FZJ + WP3 Lead	WP requirements / T3.1
7	Resolve JSC cloud usage for the project	FZJ	After summer
8	Progress consortium agreement (incl. DTA comment)	All partners' legal depts	Ongoing
9	Share and keep updated the consolidated inputs document and this presentation on Indico	WP3 Lead	Immediate

Next steps

No further meeting before the summer. Preparatory work (FL questionnaire, governance groundwork, kick-off course preparation) proceeds where feasible; the next update round is expected around November–December 2026. The Chair will circulate these minutes and the updated presentation, and thanked all partners for their inputs and effort.