Generic physiologically-based population dynamics model for plant pests

QUESTION: Can EFSA provide information on case studies mentioned in the call?

How and by whom will the case studies be selected?

If case studies are proposed by the contractor should they be included in the proposal submission?

If case studies will be selected by EFSA, can EFSA clarify what type of datasets are expected to be made available for calibration and validation purposes (population abundance data, presence/absence data, or other observations)?

ANSWER: Case studies will be selected jointly by EFSA and the scientific contractor during WP1 (Task 1 – Scoping and Planning), as part of the collaborative stakeholder engagement foreseen in that work package. This is consistent with the iterative approach described in the call, which explicitly anticipates ongoing coordination between EFSA Scientific Officers and the beneficiary throughout WP2.

Applicants are not required to propose specific case studies in their submission. Case studies will be selected jointly by EFSA and the scientific contractor during WP1, as part of the collaborative stakeholder engagement foreseen in that work package.

Regarding datasets: consistent with the typical data landscape in plant health risk assessment, case studies will be selected among organisms for which EFSA has previously conducted Pest Risk Assessments, as well as newly emerging pests meeting a minimum data threshold. Presence data combined with ecophysiological parameters represents the standard baseline expected for model calibration and validation, as illustrated by recent EFSA scientific opinions such as the physiologically-based demographic model applied for Thaumatotibia leucotreta (EFSA, 2023). Population abundance data should not be assumed to be routinely available. Absence data are generally very scarce in this domain and are not expected as a standard input requirement.

As per section 1.8 the form of grant awarded under this Call is based on financing not linked to costs of the relevant operations in accordance with Article 125 (1)(a) of the EU Financial Regulation. For this type of grant the principles of transparency, equal treatment and best value for money in relation to subcontracting are applicable. As per section 1.7, subcontracts must be awarded to the entity offering best value for money or the lowest price (as appropriate), avoiding conflicts of interest. Identified subcontractors can be mentioned already in the proposal.

QUESTION: ii) Statement: “the model signature shall follow a predefined format”.

What is the exact meaning of the term “model signature”? Does it refer to the signature of functions that will make up the Application Programming Interface (API) provided to use the simulator? Is it possible to obtain details on the required “predefined format”?

ANSWER: This refers to the standard MLflow model signature concept, defining the schema of a model's inputs and outputs (names, types, shapes). The specific format will be detailed in the Development Guide. This is fully consistent with standard MLflow model packaging practices.

QUESTION: iii) Statement: “EFSA uses automatic tools for the enforcement of code quality. The contractor is expected to fix issues highlighted by the tools.”

Which practices are included within the “code quality” expected by EFSA (e.g., code readability, documentation, test coverage, others)?

Which tools will be used to assess code quality? Can you provide a list of these tools and the configuration used to perform the code quality checks?

ANSWER: Expectations are consistent with widely accepted best practices in scientific Python development: code readability, inline documentation, PEP 8 compliance, modularity, and adequate test coverage. Specific tools and configurations will be communicated through the Development Guide prior to the deployment phase.

QUESTION: iv) Statement: “The model code shall be developed in Python according to predefined requirements covering the overall design. The most important are: [...]”.

Besides the requirements explicitly listed in the call documentation, are there additional design, architectural, development, or operational requirements that contractors are expected to follow? If so, could EFSA provide further details or reference documentation describing such requirements?

ANSWER:: Any additional requirements beyond those listed in the call will be communicated through the Development Guide, well in advance of WP3. Contractors are encouraged to apply sound software engineering principles during WP2 (modularity, separation of concerns, documented interfaces), which will facilitate a smooth integration phase.

QUESTION: In section A.5 “SEED” (page 11) of Annex 7, it is stated: “The SEED System is a modular computational framework based on a producer–consumer paradigm, designed to support the deployment and orchestration of heterogeneous analytical models.”

As the documentation does not provide further technical details regarding the SEED (Spatially Explicit Environmental Data) System, we would appreciate clarification on the following points as it appears to be a component that will closely work with the algorithms composing the simulator.

i) Does the SEED System provide programming tools that must be used to develop the simulator? If so, is it possible to access their documentation to better understand their intended usage, integration mechanisms, and implementation constraints?

ANSWER: The SEED System is an orchestration, execution and governance layer built on top of EFSA's Databricks environment. The interface between a model and SEED is defined by the notebook template and model signature described in the call's technical requirements, and will be fully documented in the Development Guide. No proprietary SEED-specific API is expected to be used during the scientific model development phase (WP2).

QUESTION: ii) Assuming a version of the simulator has already been developed as standalone Python code, could EFSA clarify the expected level of effort required to integrate it with the SEED System? More specifically: does the SEED System mainly act as an orchestration and automation layer around independently developed simulator components, or are contractors expected to deeply integrate SEED-specific functionalities and patterns into the simulator source code?

ANSWER: The SEED System acts primarily as an orchestration layer around independently developed model components. Integration effort is therefore structural rather than algorithmic, consisting of adapting the model's entry points to conform to the notebook template, model signature, and MLflow registration conventions, without requiring any rewriting of the scientific logic. This is consistent with the call's structure, which explicitly permits IT subcontracting for integration tasks T5 and T6.

QUESTION: iii)The call describes the SEED System as being based on a “producer–consumer paradigm”. Could EFSA clarify whether this refers specifically to the software engineering producer–consumer design pattern? If so, to what extent is this paradigm expected to influence: the architecture of the simulator, the communication between components, and the implementation approach adopted for the simulator source code?

ANSWER: In the SEED architecture, this paradigm operates at the platform level, not within the simulator's internal code. "Producers" develop and deploy models; "consumers" execute them through the Marketplace. This defines platform roles and workflows, not the internal architecture of the simulator. Contractors retain full methodological freedom in designing their model's internal structure, subject to the technical requirements listed in the call.

QUESTION: We kindly request clarification regarding the following statements contained in the “Technical requirements” section (page 10) of the call for proposals.

i) Statement: “the code shall be integrated on a Notebook template”.

Could EFSA clarify the meaning of the term “Notebook template”?

Considering that Python notebooks are generally intended as interactive development tools rather than production deployment artifacts, could EFSA provide additional details on the expected deployment and integration approach? More specifically, should the deliverable be: packaged as a standard Python package, delivered as a Databricks Asset Bundle targeting notebook execution, or provided through another deployment mechanism?

ANSWER: In the Databricks environment, notebooks are first-class executable and deployable artifacts, not merely exploratory tools. The term "Notebook template" refers to a standardised Databricks notebook structure that EFSA will provide before the deployment phase, as explicitly stated in the call: "A complete Development Guide will be released to contractors prior to the start of the deployment phase." Contractors are not expected to anticipate its details at proposal stage.