Reconcile a Policy's Native Ownership

Use this task when publication reports missing or conflicting native ownership. Policy Integration Manager (PIM) identities differ from Policy’s saved reference keys. Do not repair a mismatch by guessing an identity from its name. A binding associates a saved Policy reference with a native object’s identifier. The ownership registry stores these associations. Its version changes independently of a draft or policy revision.

Prerequisites

Prepare the following:

• Identify the affected policy and operation.
• Obtain policy:system-configure for inspection and decisions.
• Obtain additional policy:archive authority if you intend to withdraw.
• Arrange an authorized integration owner for native inventory or configuration problems.
• Use the application programming interface (API) request setup.

An ordinary author should preserve the error and hand off this task. Policy ownership grants do not supply system-configuration authority.

Inspect the Policy Incident

Complete the following steps:

1. Read the current policy-scoped incident:

   curl --silent --show-error --include --cacert "$PPC_CA_FILE" \
     -H "@${POLICY_AUTH_HEADER:?Complete authentication setup}" \
     "${POLICY_API}/policies/${POLICY_ID}/pim-reconciliations"
   

   The response provides unresolved bindings and the strong registry ETag.

2. Select the affected refKey from the returned incident. Keep its persisted native unique identifier (UID) distinct from the reference key.

3. Inspect the selected binding when needed. Set REF_KEY to the returned key:

   curl --silent --show-error --include --cacert "$PPC_CA_FILE" --get \
     -H "@${POLICY_AUTH_HEADER:?Complete authentication setup}" \
     --data-urlencode "refKey=${REF_KEY}" \
     "${POLICY_API}/policies/${POLICY_ID}/pim-reconciliations"
   

4. Save the response and its ETag header in your incident record. The decision request needs its refKey, governedSetGeneration, candidate identifiers, and affected policy versions.

5. Ask the owners of the policies listed in the response to review the proposed adoption, replacement, or removal. Several policies can refer to the same PIM object.

A healthy original identity can return no allowed action. A 503 means inventory evidence remains unavailable. It cannot prove native absence. A 409 can mean that a policy changed after inspection or has no current approved publication to repair. Read the error message, then repeat inspection before preparing a decision.

Choose Only an Allowed Decision

The following table defines the decision boundary for each allowed action:

Make a decision only from the current inspection:

1. Select an action from the current allowedActions. Stop if inspection offers no suitable action.
2. Prepare its body using the reconciliation reference. Copy the response’s refKey and governedSetGeneration, then add the fields required for the selected action. State why you chose the candidate, replacement, or removal.
3. Attach the strong registry ETag as If-Match. Do not use a draft token or governed-policy token.
4. Assign an Idempotency-Key to this exact decision. Retain the key, body, resource, and precondition in the approved incident record.
5. Submit POST /policies/{policy_id}/pim-reconciliations. Adoption or replacement authorization returns 200. Withdrawal acceptance returns 202.
6. Read the policy-scoped inspection again. Confirm the reconciled identity or follow the returned withdrawal deployment.

Replacement authorization does not mean Policy already created a replacement. Withdrawal acceptance does not mean Policy already removed protection. Refer to publication and withdrawal recovery for subsequent operation verification and eligible retry.

Handle Races and Uncertain Results

Use the response to select the next inspection or handoff:

• For 428, supply the required registry precondition.
• For 400, obtain a valid strong registry token from inspection.
• For 412, inspect again because the registry changed.
• For 409, read the error message and repeat inspection. Compare the returned policies, candidate, and allowedActions with your request.
• For 503, ask the PIM administrator to restore inventory access, then repeat inspection.

After changed evidence, reconsider the decision before preparing a new request. Use a new key for a newly decided mutation. After a lost response, reuse a key only for the identical prior decision. Do not change its body or evidence while claiming an exact replay. If you cannot reconstruct the original request, ask the administrator handling the incident to inspect the current mapping before another submission.

Verification and Stop Conditions

Repeat the inspection request and check that the returned PIM identifier matches your decision. Then follow delivery verification for the affected policy. If PIM inventory is unavailable, an affected policy owner has not agreed, or allowedActions offers no suitable choice, escalate the incident.

For cross-policy stale saved mappings, use global cleanup instead. For an unresolved incident, use the diagnostic handoff.