The Innovation Package and Scaling Readiness (IPSR) pathway is a structured reporting frame for OneCGIAR Initiatives that have developed an innovation and are systematically assessing its readiness for broad adoption and scaling. An IPSR result is not a standalone result — it wraps one or more existing Innovation Development results into a package, adds an expert-assessed readiness profile, maps complementary innovations needed to unlock scaling, and links the whole assembly to the initiative’s Theory of Change outcomes. IPSR pathway authoring is available in the dedicated IPSR module (Documentation Index
Fetch the complete documentation index at: https://mintlify.com/AllianceBioversityCIAT/onecgiar_pr/llms.txt
Use this file to discover all available pages before exploring further.
pages/ipsr on the client, api/ipsr on the server).
What IPSR is
An IPSR innovation package is a specific result type that asks: “Given this innovation, what combination of technical improvements, enabling conditions, and complementary innovations are needed to achieve the 2030 Scaling Ambition?” The package:- Selects a core innovation — an existing Innovation Development result (
result_type_id = 7) that the initiative wants to scale. - Defines the geographic scope and aspired scaling reach — expressed in a structured “2030 Scaling Ambition Statement” that is auto-generated from the geo scope, lead initiative, partner institutions, actors, organizations, and EOI (End of Initiative) outcomes.
- Assesses readiness levels for the core innovation and any complementary innovations.
- Records whether an expert workshop was organized to validate the assessment.
- Identifies complementary innovations (
result_type_id = 11) that are needed alongside the core innovation for scaling to succeed. - Links the package to the initiative’s Theory of Change EOI outcomes and Action Area outcomes.
api/ipsr) is the largest and most complex non-results module, containing 30+ sub-modules covering every aspect of the four-step pathway.
IPSR result identity and title
When an IPSR result is created, its title is auto-generated by the server and updated every time the geographic scope changes. The format is:Result entity and appears in all search, bilateral, and PMU views.
Four-step pathway authoring
The IPSR pathway is authored through four structured steps, each handled by a dedicated service underapi/ipsr/innovation-pathway/:
Step 1 — Innovation Package context and aspired outcomes
Step 1 (
InnovationPathwayStepOneService) establishes the fundamental framing of the package:Core innovation selection — the IPSR result is linked to one or more existing Innovation Development results via the result-innovation-package sub-module. The core innovation (with ipsr_role_id = 1) is the innovation whose readiness is being assessed.Readiness levels — the lead initiative records the current readiness level (evidence-based) and use level (evidence-based) for the core innovation, drawn from CLARISA-sourced readiness level catalogs. These levels are stored in the ResultInnovationPackage entity.Geographic scope — the geographic extent of the scaling ambition is captured using the same scope model as standard results (global, regional, national, sub-national). The server automatically regenerates the IPSR result title whenever the geo scope is saved.Partners and delivery institutions — organizations with institution_roles_id = 5 (IPSR-specific partner role) that are part of the scaling partnership, linked via ResultsByInstitutions with optional delivery types.Innovation use actors, organizations, and measures — disaggregated data about who will use the innovation and at what scale, matching the actors/organizations/measures model used by standard Innovation Use results.EOI outcomes — one or more End-of-Initiative Theory of Change outcomes that the package is expected to contribute to, stored in ResultIpEoiOutcomes. The server also retrieves Action Area outcomes from the lead initiative’s ToC and stores them in ResultIpAAOutcomes.2030 Scaling Ambition Statement — the server auto-composes a plain-English statement from the geographic scope, actors, organizations, measures, partner institutions, and EOI outcomes. This statement is stored in ResultInnovationPackage.scaling_ambition_blurb and displayed prominently in the package view.Expert workshop flag — a boolean is_expert_workshop_organized indicating whether a formal expert workshop was held to validate the package’s readiness assessment. When true, Step 1 also captures the assessed_during_expert_workshop_id — a reference to the workshop type (from the assessed-during-expert-workshop sub-module catalog).The 2030 Scaling Ambition Statement is regenerated server-side on every Step 1 save. If the actors, geography, or partner data changes, the statement updates automatically.
Step 2 — Complementary innovations
Step 2 (
InnovationPathwayStepTwoService) identifies the other innovations — either existing CGIAR results or new complementary innovations — that must accompany the core innovation for the package to succeed at scale.Complementary innovations list — the package can link to existing Innovation Development or Innovation Use results in PRMS via results-complementary-innovations. Each linked result carries its own readiness level in the context of this package.New complementary innovation records — if a needed innovation does not yet exist as a PRMS result, a Complementary Innovation (result_type_id = 11) record can be created directly from Step 2 via saveComplementaryInnovation. These records capture a title, description, and the organization responsible.Complementary innovation functions — each complementary innovation is tagged with one or more functions (results-complementary-innovations-functions) that describe the role it plays in the package (e.g., agronomic practice, market linkage, policy environment, financial service). Functions are drawn from the CLARISA-backed catalog via innovation-pathway-step-two.service.ts.Enabler types — the results-innovation-packages-enabler-type sub-module classifies each complementary innovation by the type of enabling condition it represents.Reviewers and PMU use the complementary innovations view to assess whether the package narrative accounts for the full system of innovations needed for scaling, not just the headline technology.Step 3 — Expert workshop and validation
Step 3 (
InnovationPathwayStepThreeService) captures the expert workshop details and the formal scaling readiness assessment outcomes.Workshop details — if an expert workshop was flagged in Step 1, Step 3 records the specifics: workshop dates, format, and the evidence link pointing to the workshop report (stored as an Evidence row with evidence_type_id = 5 — the workshop evidence type). The link is surfaced in the Step 1 data as link_workshop_list.Expert workshop organized — the result_ip_expert_workshop_organized table records the individual workshop events associated with this IPSR result, capturing each session via ResultIpExpertWorkshopOrganizedRepostory.Packaging expert profile — the innovation-packaging-experts sub-module captures information about the experts involved in the assessment. Each expert record can carry a list of expertise domains (results-complementary-innovations-functions via ResultIpExpertises) and an affiliated organization. Diversity of expert background is flagged via experts_is_diverse on the ResultInnovationPackage entity; if experts are not diverse, a justification is required.Participants consent — the participants_consent flag on ResultInnovationPackage records whether workshop participants consented to have their inputs used in PRMS reporting.Validation module — the results-innovation-packages-validation-module sub-module runs a structured readiness check on the package before submission is allowed. The ResultsInnovationPackagesValidationModuleService.getGreenchecksByinnovationPackageSPV2 method returns a validResult flag that must be true for the IPSR submit endpoint to accept the request.Step 4 — Theory of Change linkage and investment
Step 4 (
InnovationPathwayStepFourService) completes the package by linking it to the initiative’s Theory of Change at the result level and capturing the investment context.Package ToC results — results-package-toc-result maps the IPSR package to specific outcome and output nodes in the initiative’s ToC, extending the common ResultsTocResults pattern to the package scope.Package initiatives — results-package-by-initiatives records which initiatives are contributing to or leading the package, beyond the owning initiative.Package centers — results-package-centers records contributing CGIAR centers for the package as a whole, distinct from the per-result center attribution.Partners and donors — Step 4 accepts partner institution saves (savePartners) and bilateral donor saves (saveBilaterals). Donors are captured via non-pooled-package-projects as investment rows linking the package to specific bilateral funding lines.Non-pooled package projects — the non-pooled-package-projects sub-module records the non-pooled (bilateral) project funding lines that support this innovation package, with amounts and funder attribution.IP measures — quantitative measures of expected scaling impact captured in ResultIpMeasures at the package level (in addition to the per-result measures in Step 1).IPSR-specific result types
Two result types exist exclusively within the IPSR module:| Type | ID | Description |
|---|---|---|
| Innovation Use (IPSR) | 10 | An innovation use result authored within the IPSR context, linking use evidence directly to the package’s scaling pathway. |
| Complementary Innovation | 11 | A supporting innovation identified as necessary for the core innovation to scale, authored in Step 2. |
IPSR framework reporting
Beyond individual pathway authoring, theapi/ipsr-framework module provides a cross-result, portfolio-level view of all IPSR packages in the active phase. PMU and portfolio leads use this view to:
- See the full portfolio of innovation packages and their readiness levels at a glance.
- Monitor which packages have completed all four pathway steps.
- Review scaling ambition statements across the portfolio for consistency.
- Identify gaps — packages with incomplete complementary innovation maps, missing expert workshop evidence, or unlinked ToC outcomes.
pages/ipsr-framework → api/ipsr-framework) is distinct from the per-package pathway editing interface. It is a read-optimized, PMU-facing reporting surface rather than an authoring tool.
Submission and validation for IPSR
IPSR packages follow the sameEditing → Quality Assessed → Submitted lifecycle as standard results, but with an additional validation gate. The submitFunctionIPSR method in SubmissionsService calls getGreenchecksByinnovationPackageSPV2 before allowing submission. If any required pathway section is incomplete, the server returns a 406 Not Acceptable response with the message “sections are missing to complete” and the package remains in Editing. The green-check validation surface is visible to the submitter throughout authoring so they can track readiness before attempting to submit.
Roles required to submit an IPSR package: Coordinator, Co-Lead, Lead, or Admin on the owning initiative (role IDs 3, 4, or 5 in the roleByUser permission check).
Share result innovation package request
Theshare-result-innovation-package-request sub-module allows IPSR package owners to invite collaborators from other initiatives to contribute to the package’s authoring. This mirrors the standard share-result-request mechanism but is scoped to the IPSR module. Pending share requests are surfaced in the notification panel and must be accepted before the invited user can edit the package.