Background Processing and Cadence
The application programming interface (API) process owns Policy’s background services. They are not separate Kubernetes Deployments. Each service performs a different task. One successful worker does not prove another worker completed its work. Native import and publication use Policy Integration Manager (PIM).
Services and Defaults
The following table summarizes each background service, its default cadence, and its purpose:
| Service | Source Default | Purpose and Boundary |
|---|---|---|
| Discovery catalog refresh | Use 300 seconds. | Refresh Traverse inputs. Retain the prior snapshot after failed refresh. |
| Native policy import | Use 60 seconds. | Import external PIM policies into the Library when PIM is configured. |
| Automatic recompilation | Use 300 seconds. | Compile approved intent against fresh discovery and live inventory. |
| Publication | Use 5 seconds. | Process durable approved publication or withdrawal work asynchronously. |
| Protection reconciliation | Use 30 seconds. | Evaluate current revision and deployment evidence for protection progress. |
| Legacy activation | Use 30 seconds. | Check older deployed records. Do not substitute for governed revision evidence. |
The configuration guide explains the distinction between chart values, process environment, and credentials. Record effective settings for the running release rather than relying on this table.
Periodic services sleep before work and run serial cycles within each task. Execution and dependency waits add time to the configured interval. These intervals are not activation guarantees or service-level commitments. The current chart requires one API replica. Do not scale it for faster processing.
Startup Import and Discovery Freshness
PIM startup import defaults to enabled independently of periodic import. A startup import failure does not itself block API startup. Disabling periodic import does not disable that startup attempt. Periodic import also requires a configured PIM base address.
Import discovers existing native policies. It does not automatically adopt them into governed publication. Resolve ownership and legacy adoption through authorized workflows.
Disabling periodic catalog refresh leaves lazy first-request loading. A failed ordinary refresh can leave the prior snapshot available. Automatic recompilation applies a stricter fresh-input gate: it cannot silently compile from that retained snapshot.
Publication and Protection
Approval queues publication rather than performing every target write synchronously. The publication worker processes bounded batches of retained events. These events form the outbox, a database-backed queue that survives a process restart. The worker can finish a request, schedule another attempt, or stop after failure. A processed-event count is not a successful-publication count.
Default retry delays are 5, 15, 30, 60, and 300 seconds.
Deterministic refusals can stop earlier than transient connectivity failures.
Worker ownership leases default to 300 seconds.
A lease temporarily reserves work for one worker.
Terminal means automatic attempts have stopped, not that publication succeeded or the policy disappeared.
After process loss, reclaiming unfinished work can wait for lease expiry.
Restarting does not retry work whose automatic attempts have stopped.
Protection reconciliation evaluates revision-scoped evidence independently. It compares observations with the current governed revision and deployment generation. That generation distinguishes delivery operations. It is not the policy’s authored revision number. For Data, missing, old, or incomplete observations keep Policy from reporting Enforced. For Federated Guardrails, a matching receipt records consumer retrieval, not runtime activation. A policy using both targets needs complete Data observations and the matching Guardrails receipt. Refer to lifecycle and delivery.
Disablement and Stopping
A nonpositive polling interval disables the corresponding periodic service. It does not erase durable work, withdraw native policies, or grant a manual trigger. Stopping the API stops scheduling all its background services and interrupts user access. It does not stop independent consumers or undo native writes.
Use the configuration workflow for supported cadence changes. Refer to monitoring and restarts for a controlled process change. Do not repurpose database restore mode as an ordinary pause mechanism.
Feedback
Was this page helpful?