PRMS Architectural Redesign Blueprint Consultancy

The fifth is the technological revolution in data management. The maturing of AI and large language models has changed what is possible: data no longer has to be captured through fixed forms and rigid fields to be usable, and outputs no longer have to be predetermined and assembled by hand. This reframes the redesign itself — not a faster version of the old model, but a shift to more flexible, AI-native handling of data that cuts duplication, lowers effort, and can generate higher-quality outputs on demand while maintaining core security safeguards.

The new PRMS must be modular, reconfigurable, and interoperable by design — not simply cheaper to build, but cheaper to run and extend, with a clear view of the trade-off between reduced human effort and the real costs of AI-driven processing at scale.

Two developments in 2026 show what this looks like in practice. The CGIAR Progress Tracking Solution — launched in July 2026 — demonstrates a possible target architecture: AI-assisted, modular, with a human validation layer, open enough for users to connect their own systems via API. The June 2026 GST-endorsed Guidance Note on Program/Accelerator-level prioritization establishes that actual performance against theories of change will directly inform W1/W2 fund allocation from 2026 onward: PRMS data must be queryable in real time to feed consequential resource allocation decisions, not compiled into static reports after the fact. Together, they define what fit for purpose now requires.

Purpose

This commission produces an architectural blueprint for a rebuilt PRMS — the design basis for a subsequent build investment. It is not a developer-ready technical specification. It is the front end of a two-stage process: design now, procure and build against it. Steering Group endorsement of this blueprint will be the decision gate for the larger investment.

The starting point is not the technology but the people the system serves — funders, senior leadership and governing bodies, Program and Accelerator directors, Centers, and external partners — and the outputs they need, from stabilized reports and dashboards to on-demand answers tailored to a specific question. The design works back from those needs to the data the system already holds, and it must make the system materially lighter to feed — less manual entry, less duplication, less double reporting — not only cheaper to run.

The design target is a system that is orchestrable: modular, reconfigurable, and interoperable, built so that AI agents can understand and operate across any layer — or so that any process can run without AI, depending on the risk appetite and the requirement. A result linked to a causal pathway is the atomic unit; everything else is an expression of it. Report once, use many times. The system must function as a data layer that CGIAR tools and authorised external actors can query, contribute to, and act on — not a system that only produces predetermined outputs for predetermined audiences.

The blueprint must address constraints: that replacing human effort with AI-driven processing shifts cost rather than eliminates it, and that AI operating costs at scale must be designed for; and that Center and Program adoption has been suboptimal, and the design must address why. Both are in scope. The blueprint must be specific enough to brief the Performance and Results Management Steering Group, scope a build procurement, and hold a development team accountable.

Objectives

• Map the demand the system must serve. Identify the priority users and uses — internal and external — and the outputs each needs, from those already mandated by CGIAR governance to the on-demand, tailored outputs that AI now makes possible. Distinguish what the system already delivers well from what users cannot currently obtain.
• Take stock of the foundational building blocks the portfolio already runs on — for example the Theory of Change, the Projected Benefits model, the Results Framework and its 3 indicator tiers, PoRB/PoD planning instruments — and assess their fitness as the base for a redesigned system rather than starting from a blank slate.
• Characterize the data supply and its fragmentation — what is entered by hand versus captured automatically, and what lives across CGIAR, donor, and Center systems — and consider the growing overlap between monitoring data and science or project data under FAIR. Set out what this implies for a system that draws on existing sources rather than re-collecting data during each reporting cycle.
• Define the connecting layer between demand and supply — the core of this commission. At the level of principle and direction, set out how a result linked to a causal pathway becomes the atomic unit that is reported once and reused many times; how the layer is made FAIR, API-first, and orchestrable so that CGIAR tools and authorised external actors — including AI agents — can query and contribute to it; and how heterogeneous W3/bilateral data is accommodated without being forced into a W1/W2 mold.
• Show how the redesign lightens the load — and where it does not. Explain how it may reduce fields, duplication, and double reporting and shift effort from manual data entry toward data interoperability, while being honest about the trade-offs, including AI operating costs at scale and the points where human judgment must remain.
• Set out the direction of travel and a phased path — what is foundational and should be settled now versus what can be resolved at the build stage, including a costed view of the interim 2027 release and the fuller rebuild. As part of this, diagnose at a strategic level why Centers and Programs have historically, to different extents, routed around PRMS, and what the new system must do differently to earn adoption.

Scope and Constraints

This is a conceptual design commission. The consultant produces the architectural blueprint and roadmap, with the Performance and Results Management Steering Group providing oversight and independent challenge. While security, access controls, audit trails, and availability are core aspects of the future system, detailed technical specification — schema definitions, API contracts, and migration mechanics — is deliberately out of scope at this stage: the blueprint establishes direction and principle, and the build phase resolves the detail.

Ready by 2027 means: blueprint endorsed by the Steering Group and a build procurement decision made — not full system deployment. Specific PRMS capabilities needed for the 2027 reporting cycle will be identified in the roadmap and may be delivered as an interim release