Product Retrieval and Compatibility Deployment

Approval queues asynchronous governed publication. Consumer retrieval, publication, and target activation establish different evidence. Use the application programming interface (API) base and protected POLICY_AUTH_HEADER file from authentication.

Publication makes compiled output available to its target. Consumer receipt records retrieval. Activation means the target uses that output. Approval alone establishes none of these completion conditions.

GET /product-policies/{product_type}

Retrieve the latest published Federated Guardrails aggregate. The current public product_type enum accepts only federated-guardrails. Do not substitute pim or securequery. Accept no body. Optional environment and product_id query strings are reserved and currently ignored. They do not select separate consumer output.

Send the following headers when retrieving published consumer output:

curl --fail-with-body -i \
  -H "@${POLICY_AUTH_HEADER:?Complete authentication setup}" \
  "${POLICY_API}/product-policies/federated-guardrails"

Return 200 with ETag, Last-Modified, and Cache-Control headers. The response contains:

Illustrative response:

{
  "product_id": "federated-guardrails",
  "updated_at": "2026-10-29T12:00:00Z",
  "revision": 15,
  "version": 4,
  "fingerprint": "example-lineage-fingerprint",
  "content": {
    "entities": [],
    "warnings": [],
    "policies": {
      "templates": {},
      "staticPolicies": {},
      "templateLinks": []
    }
  }
}

A matching If-None-Match condition returns 304 with no body. The response supplies Last-Modified, but this operation does not evaluate If-Modified-Since. The fingerprint identifies contributing policy versions, rather than only comparing generated text. Background recompilation can change those versions without another human approval. The product revision and version identify aggregate output, not one policy’s governed revision. Use policy history to find an individual policy’s approved version and compilation minor.

Return 404 when no published output exists. Return 422 for an unsupported product type. Gateway identity and access failures can return 401 or 403.

Guardrails Receipt Boundary

When GUARDRAILS_CONSUMER_USERNAME is nonempty, only the exact trusted consumer identity records receipt evidence. The setting does not authenticate callers. The empty-string default accepts only requests with absent or empty identity, for anonymous compatibility. Named requests do not qualify under this default. Qualifying 200 and 304 responses can both record evidence. With a nonempty setting, anonymous reads and diagnostics under another identity do not qualify. Receipt does not prove activation or receipt by every target replica.

A qualifying consumer retrieval records receipt. No separate acknowledgement request is required. Successful retrieval alone does not establish eligibility. The receipt must match current publication targets and checksums, or exact current contributor lineage in a newer aggregate. Publication reaches Published. Publication plus qualifying receipt allows reconciliation to Enforced for Guardrails-only policies. Mixed policies also require Data protection evidence. Use Guardrails monitoring to check whether the consumer applies the retrieved configuration.

The chart maps apiService.environment.GUARDRAILS_CONSUMER_USERNAME through the API ConfigMap into the environment. Refer to Guardrails consumer evidence. The setting does not change gateway access rules.

POST /policies/{policy_id}/deploy

Retain this compatibility operation for eligible legacy approved policies. Do not use it to force publication of a governed revision. Governed delivery belongs to approval and background processing. The server rejects this operation when governed publication owns delivery.

Require policy:approve and a trusted caller identity. Policy forwards the caller’s bearer credential for request-driven Policy Integration Manager (PIM) writes. That caller also needs the applicable PIM permissions. Policy accepts the gateway’s deployment cookie fallback when no explicit authorization header exists. Do not send identity-forwarding headers or an actor in the body.

The route accepts the following path and query parameters:

This route does not require If-Match or a general Idempotency-Key. The body uses application/json. It extends the public compile request with these optional fields:

pimBindings requires an audit reason and cannot replace an existing ownership binding. Refer to reconciliation for governed ownership incidents. The public deployment schema does not accept a Secure Query-native variant. Use the deployed /doc document for the complete nested compile and native rule schemas.

Before running this compatibility-only request, prepare and review the complete deploy-request.json file. Set POLICY_ID to the eligible legacy policy’s identifier. Use the compile-body reference for its base fields and the additional deployment fields listed above. Do not pass the outer create-policy envelope from the worked lifecycle.

curl --fail-with-body -X POST \
  -H "@${POLICY_AUTH_HEADER:?Complete authentication setup}" \
  -H "Content-Type: application/json" \
  --data-binary @deploy-request.json \
  "${POLICY_API}/policies/${POLICY_ID}/deploy?reuse_existing=true"

Return 200 with plan, result, and nullable reconciliation. The last field can contain protected, unprotected, awaiting_protection, and unreadable resource-identifier arrays. These arrays report observed resource states, not confirmation that every intended target applies the configuration.

The following table summarizes compatibility deployment status codes and their meanings:

If the request times out, check policy detail and ask the PIM administrator whether the affected objects changed. Do not repeat deployment until the administrator checks for a partially applied request.