---
name: inferrex-review-golden-records
description: Review proposed changes to Inferrex Golden records with the user, show each change field by field with where every value came from, and approve or reject on their decision. Also previews merge, split, restore and archive edits. Use when the user asks about Golden-record changes, proposals waiting in the Review queue, or which system is the source of truth.
---

# Review Golden-record changes in Inferrex

A Golden record is the single combined version of one real-world thing, built from the records several systems hold. Changes to it arrive as proposals. Approving a proposal writes the Golden record and sends the change back to the systems it came from. Treat every approval as a write to those systems.

In InferrexAPI a Golden record is identified by `entityClusterId`, and a proposed change is a "canonical proposal".

## When to use

- "What Golden-record changes are waiting?"
- "Why does this customer have that email address?"
- "Approve the low-risk ones." (Read the rules below first.)
- "Merge these two customer records."

## Prerequisites

- **InferrexMCP** at `https://mcp.inferrex.com/mcp` (sign-in or API key in a header), or **InferrexAPI** at `https://api.inferrex.com` with `X-API-Key: $INFERREX_API_KEY`.
- Key scopes: `golden-records:read`, `canonical-proposals:read`, and `canonical-proposals:write` to decide.
- Decisions are made as the signed-in person or the key's owner. Where an approval policy names approvers, a decision only counts if that identity fills an open approver place.

## Steps: review what is waiting

1. **List.** Call `golden_record_canonical_change_proposals_list` with `status: "pending"`. Page with `limit` and `offset` until you have them all, or tell the user how many pages you read.
2. **Summarise.** Group by `entity_type` and `risk_level`. Show the user the groups before any detail.
3. **Read one in full.** Call `golden_record_canonical_change_proposals_get` with `id`. Show:
   - each entry in `field_diffs`: `fieldName`, `changeType`, `oldValue`, `newValue`,
   - each entry in `conflicts`: the field and the value each system holds,
   - the `risk_level`.
4. **Explain a value when asked.** Call `golden_record_get_golden_field_lineage` with `entityClusterId` and `field`. It gives the source record and value, the rule that chose it, and the candidate values every source record holds. Call `golden_record_listsources` for the source records that make up the Golden record.
5. **Decide, on the user's word.**
   - Approve: `golden_record_approve_proposal` with `id` and optional `notes`.
   - Reject: `golden_record_reject_proposal` with `id` and `reason`. A reason is required. Ask the user for it and use their words.
6. **Read the answer.**
   - Approved and applied, or approval recorded and still pending for other approvers. Say which.
   - `403`: this identity fills none of the open approver places. Say so. Do not look for another route.
   - `409`: already approved by this identity, no longer pending, or out of date. If `details.newerProposalId` is set, read that proposal instead and start again from step 3.

## Steps: several at once

`golden_record_bulk_approve` takes `proposalIds`. Use it only when:

- the user has seen the list of exactly those proposals, by record and field, and
- the user said to approve those, in this conversation.

After the call, report how many were approved, which still need other approvers, and which were skipped as stale. Never build the id list from a filter alone, such as "all low risk", without showing it first.

## Steps: merge, split, restore or archive

1. **Preview.** Call `golden_record_preview_golden_edit` with `entityClusterId`, `kind` (`merge`, `split`, `restore` or `archive`), and `otherId` for a merge or `move` for a split (source records as `golden_record_listsources` lists them).
2. **Show the result.** If `allowed` is false, give the user `refusal.message` and stop. Otherwise describe what each resulting Golden record would hold.
3. **Propose, on a yes.** Call `golden_record_propose_golden_edit` with the same arguments and an optional `note`. The answer is a proposal: `proposalId`, `status`, `riskLevel`, `riskReasons`.
4. The proposal is then decided like any other. Do not approve it yourself in the same breath. Ask.

## Steps: source of truth

- Read: `golden_record_list_source_roles` shows, for each kind of Golden record, each system's role in force, who set it, Inferrex's recommendation with its reasons, and any change waiting for approval.
- Change, on the user's word: `golden_record_set_source_role` with `connectionId`, `entityType`, `role` (`system_of_record`, `contributor`, `reference` or `receiver`) and `choice` (`confirm`, `choose` or `not_sure`).

Systems are identified by `connectionId`. Two accounts with the same vendor are two systems. Name them to the user by their display names.

## Checks before any write

- Show the field-by-field change before every approve or reject.
- Approving sends values back to source systems. Say that before the first approval in a conversation.
- A preview comes before every edit proposal.

## Equivalents

| Step | InferrexMCP tool | InferrexAPI |
|---|---|---|
| List proposals | `golden_record_canonical_change_proposals_list` | `GET /v1/canonical-proposals` |
| Read one | `golden_record_canonical_change_proposals_get` | `GET /v1/canonical-proposals/:id` |
| Approve | `golden_record_approve_proposal` | `POST /v1/canonical-proposals/:id/approve` |
| Reject | `golden_record_reject_proposal` | `POST /v1/canonical-proposals/:id/reject` |
| Approve several | `golden_record_bulk_approve` | `POST /v1/canonical-proposals/bulk-approve` |
| Read a Golden record | `unified_api_unified_get_action` | `GET /v1/unified/records/:entityClusterId` |
| Every field and why | `unified_api_get_golden_record_fields` | `GET /v1/golden-records/:entityClusterId/fields` |
| Lineage of a value | `golden_record_get_golden_field_lineage` | `GET /v1/golden-records/:entityClusterId/lineage` |
| Source records | `golden_record_listsources` | `GET /v1/golden-records/:entityClusterId/sources` |
| Preview an edit | `golden_record_preview_golden_edit` | `POST /v1/golden-records/:entityClusterId/edit-preview` |
| Propose an edit | `golden_record_propose_golden_edit` | `POST /v1/golden-records/:entityClusterId/edits` |
| Source roles | `golden_record_list_source_roles` | `GET /v1/golden-records/source-roles` |
| Set a role | `golden_record_set_source_role` | `POST /v1/golden-records/source-roles` |

## Report back

- What was waiting, by kind and risk.
- Each decision made: the record, the fields changed, approved or rejected, and the reason given.
- What is still pending and whose approval it needs.
- Anything skipped as stale, with the newer proposal's id.

## Never

- Never approve or reject without the user's decision on that proposal.
- Never bulk approve a set the user has not seen.
- Never invent a rejection reason.
- Never send a Golden record back to its systems (`unified_api_sync_golden_record`, `unified_api_sync_golden_records_batch`) unless the user asks for exactly that.
- Never show values listed in `redacted_fields` or `redactedFields`, and do not try to recover them from another tool.
- Never change an approval policy or a source role to get a change through.