Open Science Persistent Demonstrator 2026: Call for Participation (CFP)

The Open Science Persistent Demonstrator (OSPD) is a multi-phase, inter-agency initiative working towards a single long-term outcome: making geospatial scientific workflows transparent, reproducible, and reusable across the many platforms on which Earth science is now carried out. Successive phases have explored how that outcome can be supported by shared, standards-based description of workflows, datasets, and execution platforms — and how parts of that description stack can be progressively governed and standardised through OGC. The first phase of OSPD, OSPD 2024, ran in 2024 as an ESA-NASA sponsored initiative in OGC. Its goal was to establish the demonstrator as a persistent, multi-platform environment for reproducible Earth science: a continuously-available framework in which scientific workflows could be executed and inspected across the cloud platforms operated by participating organisations. Phase 1 delivered an initial collaborative research web application, a test environment for cross-platform workflow execution, advanced visualization environments, and learning and outreach materials. Its outcomes are documented in OGC Engineering Report 24-022. OGC 2025 focused on using OGC Building Blocks, detailed and well described and well supported workflows, and established ontologies as the main framework for scaling up activities from the previous phase. It highlighted significant gaps in the currently available tooling and technologies and produced a clear view of where the most useful next steps lie. Two findings, in particular, shape this Call for Participation.

Processing activities — the steps that transform inputs into outputs — sit at the heart of provenance and are the natural anchor point for richer workflow descriptions. They are also a bounded and manageable problem: geospatial workflows draw on a finite and recurring set of operation types (downscaling, reprojection, resampling, change detection, interpolation, classification, and so on). Defining these clearly is achievable within a single phase and is a necessary precursor to more detailed descriptions of workflow inputs, outputs, and execution behaviour.

The initiative is not an attempt to model entire workflows, nor to standardise all workflow components. Inputs, outputs, feature types, execution environments, and platform descriptions remain valuable areas for future work, but they are not the central object of this phase. This scope discipline is the key lesson carried forward from previous OSPD phases.

The provenance profile provides the formal structure for recording what happened in a workflow: which activities were carried out, what inputs they consumed, what outputs they produced, and which agents, services, or execution contexts were involved. It is built on W3C PROV and informed directly by the provenance work and integration experience from OSPD 2025, including the practical lessons learned from combining PROV with WF4Ever and OGC API — Processes schemas.

The profile is designed to be domain-agnostic. It is a reusable foundation, not an artefact tied to a single workflow or science domain. A tested JSON implementation schema accompanies the profile so that it can be adopted directly within OGC APIs and metadata profiles.

The profile is delivered as an OGC Building Block, with all artefacts expected of a Building Block: schemas, constraints, examples, semantic mappings, metadata, declared dependencies, validation results, and implementation evidence.

The register provides the controlled terms used to classify the activities recorded in provenance. Each entry gives a stable identifier and definition for a common geospatial processing operation — downscaling, reprojection, resampling, change detection, interpolation, and similar — that can be referenced consistently across provenance records, metadata, and future workflow descriptions.

The register is designed to support federation rather than replace existing vocabularies. Process terms from OpenEO, NASA vocabularies, machine-learning taxonomies, and other domain-specific sources can be reused, mapped, or related through standard semantic relationships (exactMatch, closeMatch, broader, narrower). This positions OGC as a common reference point without requiring any community to abandon its existing terminology.

In combination, the profile and the register make processing activities identifiable, referenceable, and comparable across workflows and platforms. The provenance profile asks "what activity happened?"; the register supplies the controlled term that answers the question. This separation of structure from vocabulary follows the same Building Blocks principles validated in OSPD 2025 and allows each part to evolve independently.

The pilot is organised around five Activities that together produce and exercise the provenance profile and the process-type register, and document the outcomes. Each Activity is detailed further in Activities — Detailed Description.

Work is allocated to differnt roles as follows:

This allocation has two deliberate properties. First, Activity 1 is performed independently by both D100 and D110, providing at least three parallel implementations of the generic provenance Building Block and a strong test of its clarity and reusability. Second, Activities 2 and 3 are performed in parallel by different roles, allowing the workflow-profiling and register-setup work streams to progress concurrently before converging in Activity 4.

The activity follows a model-first, test-driven approach. The provenance profile is developed as a reusable, domain-agnostic foundation, and a representative set of workflows is used to test it and populate the register. The principal methodological steps are:

The Workflow Profiler is responsible for applying the provenance profile to a real workflow and contributing the resulting evidence back into the pilot. A Workflow Profiler:

The pilot includes at least two Workflow Profiler positions, intended to be filled by two different organisations to provide independent profiling experience against two or more different workflows. Bidders proposing for this role may identify the workflow they intend to profile and explain why it is suited for the exercise.

The Register Implementer is responsible for standing up the process-type register and ensuring it is ready for handover to OGC after the pilot. A Register Implementer:

Bidders proposing for this role may describe their experience with vocabulary management, register/registry infrastructure, and OGC Building Block conventions, if any.

The OGC API Processes Profiler is an in-kind role that demonstrates the provenance profile in the context of OGC API — Processes. An OGC API Processes Profiler:

This role is offered on an in-kind basis only; it is not eligible for funding. Bidders proposing for this role may describe their experience with OGC API — Processes, provenance metadata, and OGC Building Block conventions.

The bidders for all the roles are generally expected to be familiar with W3C PROV, OGC Building Blocks, JSON Schema and JSON-LD, register/vocabulary infrastructure.

OGC staff document results across the pilot and contribute to the Report. OGC staff are not part of the bidding process.

OSPD 2026 expects the Workflow Profilers to propose workflows that exercise the provenance profile against substantive geospatial processing. The pilot does not prescribe specific workflows; bidders are expected to nominate workflows they are already familiar with and to explain how they exercise the provenance profile.

A suitable workflow for this role typically has the following characteristics:

Bidders are encouraged to propose workflows they have already implemented. Several such workflows have been thoroughly documented in previous OGC pilots. For example, the OSPD 2025 initiative includes well-documented workflows for water body detection, polar ice analysis, mangrove biomass estimation, and coastal vulnerability assessment. Additional relevant examples include workflows from AI-DGGS Pilot activities, flood and hydrological modeling chains, and selected Earth-science processing use cases. Workflows from other contexts are also welcome, provided they meet the characteristics described above.

The Workflow Profilers are expected to select different workflows, so that the provenance profile is exercised against independent processing chains.

Activity 1 — Generic Provenance Building Block — is performed independently by both role Participants. This is a deliberate design choice. At least three parallel implementations of the same generic Building Block provide:

The three implementations are not expected to be identical — variation is informative. Where the implementations diverge, the Lead Architect (OGC Staff) and the Register Implementer (D110) coordinate with all Participants to determine whether the divergence reflects ambiguity in the profile (which is then resolved through refinement) or legitimate variation that the profile should tolerate.

Activity 4 — Register Population — is the integration point of the pilot. All three Participants contribute to Activity 4:

At the close of the pilot, the populated register is handed over to OGC for redeployment within the OGC register infrastructure.

OGC staff assemble the documentation delivered by Participants across all Activities — implementation experience, validation evidence, and lessons learned — and ensure its proper integration into the Report (D001) and the OGC Building Block website. They assume the role of the Lead Architect and curate and edit the material the Participants provide rather than authoring it from scratch (see Activity 5). All Participants are responsible for delivering this material and contribute weekly to the Report — see Pilot Organization and Execution for the documentation requirements that apply to all OGC COSI initiatives.

A detailed master schedule is provided in Master Schedule. At a high level, the pilot runs in three overlapping phases:

Activity 1 produces the generic provenance Building Block that implements the OSPD 2026 provenance profile. This activity is performed independently by all Participants, providing parallel implementations of the same generic Building Block.

The Building Block must:

Activity 2 exercises the generic Building Block produced in Activity 1 against real geospatial workflows. This activity is performed by the two Workflow Profiler Participants, each profiling a different workflow, and by the OGC API Processes Profiler (D120, in-kind).

The activity must:

Activity 3 establishes the process-type register infrastructure that will host the controlled vocabulary of geospatial processing operations. This activity is performed by the Register Implementer Participant/s.

The activity must:

Activity 4 populates the register established in Activity 3 with the initial set of process-type entries and federation mappings. This activity is performed by all Participants.

The activity must:

Activity 5 makes documentation an explicit, first-class outcome of the pilot. Each Participant is responsible for documenting its own work, worked examples, and results — implementation experience, validation evidence, design findings, and lessons learned — as the pilot proceeds rather than only at its close. This activity is performed by all Participants.

The material produced here is what the Report Editor (D001) assembles and integrates into the Report and the OGC Building Block website. The completeness and quality of the final Report therefore depend directly on the snippets and evidence each Participant delivers.

Activity 6 is an optional sub-activity of Activity 5. It is the automatic generation of profile documentation from building blocks - i.e. getting the profile ready for publication.

The OGC Open Science Persistant Demonstrator 2026 Report (D001) is the principal written deliverable of the pilot and integrates findings from all five activities. The Lead Architect (OGC Staff) edits the Report; all Participants contribute weekly to it. Content includes:

Bidders are selected based on the evaluation criteria defined below, applied per role.

A bidder is an OGC organisational member that holds Explorer or higher level membership in good standing and submits a proposal in response to this Call.

For "Extra Small Explorer" members, OGC’s standard per-initiative funding cap applies. All higher-level memberships have no cap. OGC Individual and Developer members can participate in initiatives but are not eligible for funding.

OGC welcomes submissions from organisations representing a consortium. OGC will enter into a contract with a single organisation exclusively; it is up to the consortium representative to manage its other consortium members. The contracted OGC member is fully accountable for the consortium.

Further information on the bid submission process can be found in Proposal Submission.

Responding to the Call For Participation (CFP):

To respond to the CFP as a bidder, you will submit an Online Form in which you describe your proposal. The proposal should include your technical solution(s) for each deliverable, cost-sharing request(s) for funding, and proposed in-kind contribution(s) to the initiative.

The CFP includes a description of the deliverables against which bidders may submit proposals (see Bidding and Selection Process). Bidders may address role deliverables (D100, D101, D110, D120). The timeline for completion of the deliverables is set out in the Master Schedule.

Proposal evaluations take place on a per-deliverable basis. All proposals should be entered into the form on a per-deliverable basis.

Proposals in response to the CFP should be submitted by the deadline listed in the Master Schedule.

Participant Selection and Agreements: Following the submission deadline, OGC will evaluate received proposals, review recommendations with the Sponsor, and negotiate Participation Agreement (PA) contracts including Statements of Work (SOWs). Participant selection is complete once PA contracts have been signed with all Participants.

Required attendance at the Kickoff: The Kickoff is a meeting where Participants, guided by the Lead Architect and OGC staff, refine the initiative architecture and settle on specifics to be used as a baseline. Participants are required to attend the Kickoff, including breakout sessions, and are expected to use these breakouts to collaborate with other Participants. Given that Activity 1 begins immediately after Kickoff, alignment on the provenance profile baseline at Kickoff is critical.

Required attendance at Regular Telecons and Meetings: After the Kickoff, Participants will meet frequently via weekly telecons (videoconferencing) and in person at OGC Member Meetings. As a minimum, Participants are required to attend virtual meetings regularly.

Requirements for Development of Deliverables: Development of components, Reports, and other deliverables will commence during or immediately after the Kickoff meeting.

Under the Participation Agreement contracts, ALL Participants are responsible for contributing content to the Report (D001), particularly regarding their implementation experiences, findings, and recommendations. Each Participant is required to provide at least one bullet point per week to the Report on work, progress, technical discussions, and decisions. The Lead Architect serves as the Report editor and is the primary author on shared sections such as the Executive Summary, capturing design decisions and lessons learned during the whole execution phase. Compiling the whole report at the end of the initiative does not work.

More detailed deliverable descriptions appear in Pilot Organization and Execution.

Final Summary Reports, Demonstration Event, and Other Stakeholder Meetings: Participant Final Summary Reports constitute the close of funded activity. Further development work may take place to prepare and refine assets to be shown at webinars, demonstration events, and other meetings.

Assurance of Service Availability: Participants selected to implement service components (in this initiative, the Register Implementer in particular) must maintain availability of the register for a period of no less than twelve months after the Participant Final Summary Report milestone — or hand the running infrastructure over to OGC at the close of the pilot, as set out in Activities — Detailed Description.

Questions and Requests for clarification: Bidders have the opportunity to submit questions about the CFP. Questions are due on the date listed in the Master Schedule. Question submitters will remain anonymous, and answers will be compiled and published in the CFP clarifications.

Ongoing updates and answers to questions will be added to the CFP Corrigenda Table and the CFP Clarifications Table. The HTML version of the CFP will be updated automatically and appear at the same URL as the original version.

Bidders may submit questions using the Q&A Form.

This initiative will be conducted within the policy framework of OGC’s Bylaws and Intellectual Property Rights Policy ("IPR Policy"), as agreed to in the OGC Membership Agreement, and in accordance with the OGC Apply Program Policies and Procedures and the OGC Principles of Conduct, the latter governing all related personal and public interactions. Specifically:

Several key requirements are summarised below for ready reference:

The roles generally played in any OGC Apply Program initiative include Sponsors, Bidders, Participants, Observers, and the OGC Apply Team. Explanations of these roles are provided in Tips for New Bidders.

The OGC Apply Team may include an Initiative Director and Initiative Architect(s). Unless otherwise stated, the Initiative Director serves as the primary point of contact (POC) for OGC.

All activities in this pilot result in a Deliverable. These Deliverables generally take the form of documents (Report), running components (the register infrastructure), or machine-readable specification packages (the provenance Building Block and the populated register content).

Proposals are expected to be brief, broken down by deliverable, and to precisely address the work items of interest to the bidder.

Proposals will be evaluated against criteria in four areas: technical, compliance, experience, and management/cost. Role-specific evaluation criteria are provided in Bidding and Selection Process.

This section presents general guidelines for submitting a CFP proposal. Detailed instructions for submitting a response proposal using the OSPD 2026 bid submission form URL web page can be found in the Step-by-Step Instructions below.

Proposals must be submitted before the deadline indicated in the Master Schedule.

Information submitted in response to this CFP will be accessible to OGC and Sponsor staff. This information will remain in the control of these stakeholders and will not be used for other purposes without prior written consent of the Bidder. Once a Bidder has agreed to become a Participant, they will be required to release proposal content (excluding financial information) to all initiative stakeholders. Sensitive information other than labour-hour and cost-share estimates should not be submitted.

Bidders are selected for cost-share funds on the basis of adherence to the CFP requirements and the overall proposal quality. The general initiative objective is to produce a governed provenance profile and process-type register, and to capture findings and recommendations that inform future OGC standardisation activity. Bidders not selected for cost-share funds may still request to participate on a purely in-kind basis.

Bidders should avoid attempts to use the initiative as a platform for introducing new requirements not included in this Call for Participation. In particular, OSPD 2026 has deliberately narrow scope (see Implementation Plan: A Profile-Plus-Register Approach); proposals should respect this scope. Any additional in-kind scope should be offered outside the formal bidding process, where an independent determination can be made as to whether it should be included in initiative scope. Out-of-scope items could potentially be included in another OGC Apply initiative.

Each selected Participant (even one not requesting any funding) will be required to enter into a Participation Agreement contract ("PA") with OGC. The reason this requirement applies to purely in-kind Participants is that other Participants will likely be relying upon the delivery of their work. Each PA will include a Statement of Work ("SOW") identifying specific Participant roles and responsibilities.

Once the original CFP has been published, ongoing updates and answers to questions can be found in the CFP Corrigenda Table and the CFP Clarifications Table.

Bidders may submit questions using the [https://forms.ogc.org/ogcportal/form/OSPD2026CFPQuestions/formperma/FatEG5cS8pYQ1NGeeLgt7iZ4zMYOELYhrAzZ8IgN6_A].

All inquiries will be published anonymously. Answers will be regularly compiled and published in the CFP clarifications section.

The process for a Bidder to complete a proposal is set out in the online Bid Submission Form.

The Bid Submission Form will be made available shortly after the CFP release. It will include a series of web forms, one for each deliverable of interest. Bidders should remember to submit one form for each deliverable for which they wish to submit a proposal.

New users must create an account before completing a form. Once an account is established, the user may log in and will be taken to a home page indicating the "Status of Your Proposal." The user can return to this page at any time by clicking the OGC logo in the upper-left corner.

Any submitted bids will be treated as earnest submissions, even those submitted well before the response deadline. Be certain that you intend to submit your proposal before you click the Submit button on the Review page.