# OpenG2P Registry (Platform)

**OpenG2P Registry** is an open-source platform for building **functional registries** -- not mere databases -- of individuals, non-human entities, and groups. It is designed to fit naturally into a country's digital public infrastructure (DPI), providing an authoritative, interoperable data platform that can serve multiple government agencies and programmes simultaneously.

A single deployment of the Registry can host one or more **Registers** (such as a Farmer Register, Individual Register, or Household Register), each governed by change-management workflows, version history, and consent-aware data sharing. Whether you are building a national social registry, a farmer registry, or a vehicle registry, the underlying principles and platform remain the same.

Watch the video below for a quick introduction to the OpenG2P Registry Platform.

{% embed url="<https://drive.google.com/file/d/1FmAZ4Tf_iFBTtsHJEV4FTm1h95rqq87K/preview>" %}

## Why a registry?

A **registry** is fundamentally different from an application database. The distinction matters because registries serve as shared infrastructure rather than isolated application stores.

| Dimension             | Registry                                             | Application database                           |
| --------------------- | ---------------------------------------------------- | ---------------------------------------------- |
| **Purpose**           | Authoritative source of truth across the ecosystem   | Data store for a single application            |
| **Identifiers**       | Unique, meaningful IDs mapped to real-world entities | Application-specific keys; duplicates possible |
| **Change management** | Versioned audit trails with approval workflows       | Direct writes, typically unaudited             |
| **Interoperability**  | Cross-sector sharing via standard APIs               | System-specific, tightly coupled               |

When governments invest in a proper registry layer, they unlock exponential value through data sharing, verifiable credentials, and coordinated service delivery. The rationale is explored in detail in the blog [Dynamic Registry: A Foundation for Effective G2P Delivery](/resources/blogs/dynamic-registry-a-foundation-for-effective-g2p-delivery.md).

## One core, many domains

OpenG2P Registry is a **core platform** over which registries of any domain can be implemented. By extending the core with domain-specific registers and metadata, the same platform can manifest as:

* Farmer Registry
* Social Registry
* Family / Household Registry
* Vehicle Registry
* Disability Registry
* Crop Registry
* Any other domain registry

The fundamentals of a good registry -- change management, version history, encryption, interoperability, consent -- remain the same across domains. Only the domain-specific data model changes.

## Functional architecture

<figure><img src="/files/x49d4237Mm5ATdThR3rY" alt=""><figcaption></figcaption></figure>

The architecture can be understood in terms of the following layers and capabilities:

**Data entry channels** -- Staff Portal, Beneficiary Portal, and Agency App provide user interfaces for creating and updating records. Each channel feeds changes through the same change-management pipeline.

**System integration** -- The Partner API and Ingestion Pipeline allow external systems to push data into the Registry programmatically. Data is validated, mapped, and routed through the standard approval workflow.

**Change management** -- Every modification, regardless of source channel, passes through a change request workflow with verification and approval steps before it is applied to the data.

**Data security** -- Records are stored with encryption at rest at the column level, ensuring sensitive fields are protected even in the event of infrastructure compromise.

**Version history** -- The Registry maintains a full version history of every record. Previous versions can be queried at any time, which is essential for grievance redressal and audit.

**Audit trail** -- All significant events in the system are recorded for transparency and traceability.

**Event publishing** -- Changes in the Registry are published via WebSub, enabling downstream systems to react to data updates in near real-time.

**Consent-aware data sharing** -- Data is shared with external consumers only when consent requirements are satisfied, following configurable consent policies.

**Outgestion pipeline** -- A push-based pipeline for proactively sending data to partner systems according to defined schedules and filters.

## Key capabilities

The following table summarises the major features of the Registry with links to detailed pages.

| Capability                    | Description                                                  | Details                                                                                                       |
| ----------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------- |
| Unified registry model        | Registers, Tables, and Programme Registers in one platform   | [Unified Registry Model](/products/registry/registry/features/unified-registry-model.md)                      |
| Change management             | Verification and approval workflows for every data change    | [Change Management](/products/registry/registry/features/change-management-and-approval-workflow.md)          |
| Metadata-driven extensibility | Configure registers, sections, and UI through metadata       | [Metadata-Driven Extensibility](/products/registry/registry/features/metadata-driven-extensibility.md)        |
| Ingestion pipeline            | Bulk and streaming data import from external systems         | [Ingestion Pipeline](/products/registry/registry/features/ingestion-pipeline.md)                              |
| Data integrity and encryption | Column-level encryption at rest; data integrity controls     | [Data Integrity & Encryption](/products/registry/registry/features/data-integrity-security-and-encryption.md) |
| Consent-aware data sharing    | Share data with partner systems governed by consent policies | [Consent-Aware Data Sharing](/products/registry/registry/features/consent-aware-data-sharing.md)              |
| Event publishing and WebSub   | Publish change events to downstream subscribers              | [Event Publishing](/products/registry/registry/features/event-publishing-and-websub-integration.md)           |
| Audit and traceability        | Full audit trail of system events                            | [Audit & Traceability](/products/registry/registry/features/audit-ability-and-trace-ability.md)               |
| Dynamic UI rendering          | UI generated from register metadata and JSON schemas         | [Dynamic UI Rendering](/products/registry/registry/features/dynamic-ui-rendering.md)                          |
| Cloud-native deployment       | Helm-based deployment on Kubernetes                          | [Cloud-Native Deployment](/products/registry/registry/features/cloud-native-deployment-and-scaling.md)        |
| Standards compliance          | Alignment with DPI and functional registry standards         | [Standards Compliance](/products/registry/registry/features/standards-compliance.md)                          |
| Observability                 | Logging, monitoring, and operational controls                | [Observability](/products/registry/registry/features/observability-and-operational-control.md)                |

{% hint style="info" %}
This Registry is internally referred to as **Gen 2**. It is a major evolution from the previous [Social Registry](/products/registry/registry/_archive/social-registry.md), which was built on the Odoo platform. Gen 2 uses a completely different architecture based on **FastAPI** services, with a metadata-driven design and a rich set of features suited to diverse domain requirements.
{% endhint %}

## Getting started

{% content-ref url="/pages/ryDHNM0vtCppsJVjS1Ro" %}
[Concepts](/products/registry/registry/concepts.md)
{% endcontent-ref %}

{% content-ref url="/pages/KijmnE6oxwhfiO7bEhgT" %}
[Features](/products/registry/registry/features.md)
{% endcontent-ref %}

{% content-ref url="/pages/98WdtNltJNqTZwvF5mal" %}
[Deployment](/products/registry/registry/deployment.md)
{% endcontent-ref %}

{% content-ref url="/pages/pPzw1Q41rqtwLbUJzFDU" %}
[Developer Zone](/products/registry/registry/developer-zone.md)
{% endcontent-ref %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.openg2p.org/products/registry/registry.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.