inferrex-review-golden-records · Get SKILL.md

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

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.