Automatic Recompilation of Approved Policies

Policy’s application programming interface (API) periodically recompiles approved policies against fresh discovery and live Policy Integration Manager (PIM) inventory. Source changes can alter generated output without changing an author’s intent. This background check does not replace human review or approval.

For example, fresh discovery can associate another location with an existing classification. The same approved intent can then produce different target artifacts. The worker validates the refreshed set before accepting compilation changes. It does not react immediately to each discovery change event.

Scheduling and Effective Configuration

The backend setting policy_recompile_interval_seconds defaults to 300 seconds. The environment variable POLICY_RECOMPILE_INTERVAL_SECONDS supplies that setting. The shipped chart also defaults to 300 through this value:

apiService:
  environment:
    POLICY_RECOMPILE_INTERVAL_SECONDS: "300"

Nonpositive values disable periodic recompilation. The worker sleeps before its first cycle and between cycles. Execution time adds to the interval. Five minutes is not a completion deadline. Disabling scheduling preserves stored revisions and queued publication work. It neither withdraws policies nor disables the other workers.

Check the actual release values, generated configuration, and startup message. Do not assume source defaults match an existing installation. Refer to observation and restarts for nonsecret checks.

There is no public run-now endpoint for automatic recompilation. Restarting the API is not a supported immediate-trigger mechanism. The next process also sleeps before its periodic cycle.

Fresh Inputs and Set-Wide Validation

An eligible cycle refreshes discovery, then reads live PIM inventory. It pins those fresh inputs for compilation and peer validation. Pinning means using the captured inputs throughout that cycle, rather than mixing later refreshes into the same result. It validates both individual policies and their combined generated output. Changed source context can reveal conflicts that earlier inputs did not expose.

Failed discovery refresh does not permit recompilation from cached discovery. Unavailable live inventory also prevents acceptance. The catalog’s separate ability to retain an old snapshot does not relax this rule. An apparently usable catalog can therefore coexist with blocked recompilation.

Blocking compilation, validation, or persistence failures preserve the previous governed set. Policy does not accept a partially refreshed subset. This preservation concerns local governed state and queued work. It does not certify target availability or undo earlier external changes. Here, fail-closed means refusing an unsafe replacement while retaining previous governed state. It does not mean automatically denying all target traffic.

What Stays Unchanged

Automatic recompilation preserves:

• The author’s saved intent and the approval that authorized it.
• The original approval identity and decision information.
• Any open replacement draft, including unfinished or in-review work.
• Earlier governed revisions and their historical evidence.

System compilation history remains distinct from a person’s approval event. The worker records its compilation action rather than impersonating an approver. An author still needs the ordinary submission and approval workflow to change intent. Refer to states and revisions.

Changed and Unchanged Output

Changed accepted output creates compilation minor versions under the existing governed major revision. It also queues asynchronous publication work. This is not a new authored major revision or a new human approval.

Unchanged output creates neither compilation minors nor publication work. A successful cycle with no new version can therefore be normal. Do not treat an unchanged version number as proof that the worker stopped.

Successful compilation establishes that Policy accepted refreshed artifacts. Queued publication does not establish delivery. Publication and consumer receipt do not independently establish actual target protection. Continue through the delivery and lifecycle guidance for target-specific verification.

Outcomes and Operator Interpretation

Use this table to interpret recompilation outcomes and choose an operator response:

Concurrent governance can supersede work during compilation or persistence. Deferred work can include active publication constraints or legacy adoption requirements. Legacy deployments do not gain automatic governed adoption or publication. Some safe source-preserving scope updates can proceed automatically. Do not infer authorization for every native ownership change.

Observation and Recovery

An operator should collect the following evidence before changing configuration:

• Effective interval, process start time, and recent cycle timestamps.
• Policy count, failed-policy count, completion flag, and diagnostic phase.
• Superseded or deferred indicators and any returned reason.
• Current governed revision, compilation minor, and relevant open draft.
• Dependency availability, request identifiers, and later deployment generation.

The API logs an Approved policy recompilation summary for owned cycles. Inspect structured log fields where your logging platform retains them. Metrics count cycle outcomes. API logs provide the phase and reason. A blocked metric can represent blocked, superseded, or deferred work. Read the logged reason before changing a setting or retrying publication.

For a transient dependency failure, restore access and observe a later scheduled cycle. Do not substitute cached inventory or reduce the interval to bypass validation. For missing policy inputs or conflicts, ask the policy author and reviewer to correct and approve the proposed change. For legacy adoption or missing PIM mappings, ask the Policy administrator to follow ownership recovery. Do not edit database records, erase checkpoints, or manufacture approval evidence.

Publication retry sends the configuration saved for that delivery request. It does not incorporate corrected drafts or fresh discovery. The reviewer’s validation request checks a saved draft. It does not start automatic recompilation.

Refer to monitoring and restarts, publication recovery, and API recovery and reconciliation.