> 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/features/version-history.md).

# Version History

OpenG2P Registry keeps an append-only **version history** of every approved change to primary and child register records. Staff can open a record’s Version History view to see what changed on a given date, which change request committed the change, and how the record evolved over time - supporting grievance redressal, audit, and point-in-time investigation.

{% hint style="info" %}
Version history stores **record snapshots** (and document promotion events). It is not the same as workflow audit (who verified or approved a change request) or platform write-operation audit. See Audit-ability & Trace-ability for the workflow trail.
{% endhint %}

### What is captured

| Artefact                 | What is stored                                                          | When                                                            |
| ------------------------ | ----------------------------------------------------------------------- | --------------------------------------------------------------- |
| Register record versions | Snapshot rows in per-register history tables (`g2p_register_history_*`) | Change request approval, or intake form ingest into live tables |
| Supporting documents     | Promotion events in `g2p_register_document_history`                     | When pending attachments become live section documents          |
| Computed scores          | Separate score history table                                            | When a score compute job completes                              |

Program application registers do not participate in register version history.

### Capabilities

* **Full ledger of approved states** - previous versions remain queryable after later edits or child deletes (subject-scoped discovery).
* **Linked to change requests** - staff Version History navigates by date and change request; each CR-backed version retains initiator and approver metadata.
* **Intake-aware** - first creates via intake also write history, keyed by submission id when there is no change request.
* **Document promotions audited** - each promotion of a supporting document to a live section is recorded separately from the binary object catalog.
* **Permission-gated** - viewing version history requires `registerHistory:view`.

### Staff experience

On a register record in the Staff Portal:

1. Open **Version History**.
2. Choose a date that has committed changes.
3. Review sections and change requests for that date.
4. Open a change request to see the approved payload and approval context.

### How it relates to change management

All registry mutations still flow through Change Management & Approval Workflow (or the intake approval path). Version history is the **post-approval** ledger: the shadow / change-request stage holds the proposed state; only after approval is a history snapshot written and the live register updated.


---

# 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 dynamically by asking a question.

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

```
GET https://docs.openg2p.org/products/registry/registry/features/version-history.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.