> 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/open-agri-stack/architecture/terms.md). # Terms: Validation, Correction, Verification The trust and correction vocabulary used across Agri Stack registries: validation, change, correction, void, approval of changes, verification and dispute. The registry's job is that its records are **authentic, and verified where that is needed**. Whether a programme will act on a record (approval for payment or eligibility) is decided in PBMS, not here. These terms apply to both record kinds: **entity** registers (a farmer, a plot) and **activity** registers, whose records are occurrences (a sowing, a vaccination). See [activity register](/products/registry/registry/features/activity-register.md). | Term | What it means | What happens to the data | Entity register | Activity register | | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | | **Validation** | Automatic checks at entry: format, required fields, reference data, plausibility | Bad input is rejected or warned on; nothing is stored about it | Built | Built | | **Change** | The world changed: the farmer moved, got a new phone, sold a plot | New version; the old value stays in history as true *at that time* | Change request | Doesn't apply: an occurrence never changes; a new event is a new activity | | **Correction** | The record was wrong: a typo, a mis-measured area | New version; the old value is marked as an error, never true | Change request today, not marked as a correction; marking it, with a reason, is proposed (phase 2) | Supersede, with a reason | | **Void** | The record shouldn't exist: a duplicate, an event that never happened | Kept, but no longer counts | Record status (e.g. deactivated) | Void, with a reason | | **Approval** (of a change) | A supervisor authorises a change or correction before it enters the register | Governs who may change data; says nothing about whether it is true | AWE on change requests, as built | Not needed: appends and corrections are governed by permissions and rules | | **Verification** (attestation) | An independent check that recorded data matches reality or an authoritative source: a field visit, a document, a national ID lookup, a trusted device | **Never changes the data.** Adds a trust status (verified, failed or pending), with who checked, how and with what evidence | Proposed (phase 2); today a verification tied to a change request | Built as a single step (verify or reject); moves onto the common model | | **Dispute** | The person concerned says a record is wrong | Triggers verification, then a correction if the claim holds | Proposed (phase 2) | Proposed (phase 2) | **How they relate:** * Verification is about **truth**; approval is about **authority to change**. Both can apply to the same data. * A change or correction **resets the verification** of what it touched: new data hasn't been checked. * A failed verification leads to a **correction** or a **void**; it never edits the data itself. The common verification and correction model for both kinds (verification policies, records and status, corrections marked as such, disputes) is proposed, not built: see [Verification and Correction (Proposal)](/products/registry/registry/design/verification-and-correction.md). --- # 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/open-agri-stack/architecture/terms.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.