Open Agri Stack

Open Agri Stack is the digital public infrastructure (DPI) for agriculture: sovereign departmental registries, shared reference data, and the shared services that let partners use farmer data with the

Source code: github.com/openg2p/agri-stack (the use-case composite), github.com/OpenG2P/crop-sown-registry, github.com/OpenG2P/farmer-registry and github.com/OpenG2P/registry-platform.

What it is

Open Agri Stack is the digital public infrastructure (DPI) for agriculture. These pages describe its architecture for OAN Ethiopia layers 1–3:

• Layer 1: the functional registries (farmer, crop sown, livestock, DA);

• Layer 2: catalogues: the reference data every registry uses (code lists, reference entities such as seed varieties, geography);

• Layer 3: the shared DPI services that connect and govern them.

They also cover how service providers (banks, MFIs, agritechs: partners) get farmer data held across the registries: who routes a request, who decides what may be shared, and who enforces it.

The registries (Layer 1)

Each department runs its own registry on the OpenG2P registry platform. Registries are sovereign: each checks the caller, asks the Consent Manager what may be released, and releases only that. Registries share data, never code.

Registry	Holds	Kind	Status
Farmer Registry (FR)	Farmers, land parcels, households, declared main crops, livestock (until a Livestock Registry exists)	Registers and child tables (entities)	Built (Farmer Registry)
Crop Sown Registry (CSR)	What each farmer plans, prepares, sows, observes and harvests, plot by plot and season by season; clusters	An activity register (occurrences) plus a Cluster register	Built (design, as built)
Livestock Registry	Animals and livestock events (born, vaccinated, treated, sold)	An entity register and an activity register	Planned (design only, see register model design)
DA Registry	Development agents	Register	Planned

All registries are keyed to the same Fayda-based identifier.

Shared services (Layers 2 and 3)

Service	Role in Open Agri Stack
Catalogues (today the Master Data Service, MDS)	All Layer 2 reference data: code lists (the Ethiopia country pack's agriculture domain), reference entities, geography, sample people. MDS serves this role for now; proper catalogues are still to be designed and built (see open items)
Partner Management (PM)	Trust root for every participant (partners, registries, the composite): identities and public keys
Consent Manager (CM)	The farmer's consent and the data-share policies; /validate tells each registry what it may release
Use-case composite	One generic service that serves approved use cases (e.g. loan-profile) by querying several registries with one consent and returning one signed response
Approval Workflow Engine (AWE)	Each department approves its own policies and its registers' changes
Audit Manager	Audit events from every hop, linked by the request ID

What is built and what is design

Besides the existing OpenG2P registries, PM and CM, the following are built (October 2026). The rest is design.

Part	Status	Where
Activity registers in the registry platform	Built	Registry platform changes
Register model, phase 1 (typed participants, entities first, partner corrections, Cluster register, crop-change link, verification status in DCI, shared sample data)	Built	Register model design
Register model, phase 2 (common verification model, disputes, beneficiary API for occurrences, subscribe/notify)	Design	Register model design
Crop Sown Registry	Built	Crop Sown Registry (as built)
Farmer Registry: declared main crops, FARMER_ID in DCI, sample lands	Built	Farmer Registry changes
One consent with a grant per registry, in CM	Built	Consent Manager changes
Use-case composite, first version	Built	Composite as built
Consent collected in CM presented at a registry; policies held in PM; rate limits across pods and quotas; publish checks; data-blind mode	Design / TODO	TODOs and open items

Map of this section

Part	Pages
Architecture and concepts	Components and who talks to whom; request flow; policy and consent; consent model; registry model; register vs activity register; terms
Design	Register model design; activity register; Crop Sown Registry; use-case composite; concept notes review
Implementation	What is built, per component: registry platform, Consent Manager, Crop Sown Registry, Farmer Registry, composite; the standards used
Guides	Partner guide; composite configuration; adding a data source; end-to-end test from a laptop; deploying on a cluster; running the composite locally
TODOs and open items	Decisions and checks still pending; service guide notes