> For the complete documentation index, see [llms.txt](https://docs.openg2p.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openg2p.org/products/registry/registry.md). # OpenG2P Registry (Platform) OpenG2P Registry is an open-source platform for building functional registries of individuals, groups and non-human entities, that fit into a country's digital public infrastructure {% hint style="info" %} **New home: GitLab.** **`registry-platform`** is now developed at [github.com/OpenG2P/registry-platform](https://github.com/OpenG2P/registry-platform). {% endhint %} **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="" %} ## 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
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="" %} {% endcontent-ref %} {% content-ref url="/pages/pPzw1Q41rqtwLbUJzFDU" %} [Developer Zone](/products/registry/registry/developer-zone.md) {% endcontent-ref %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openg2p.org/products/registry/registry.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.