Troubleshoot Automatic Recompilation

Use this task when changed source information does not produce expected approved output. Automatic recompilation periodically checks approved policies against fresh inputs. It differs from reviewer-requested saved validation and retained-deployment retry.

Prerequisites

Prepare the following:

• Identify the approved policy and the source change you expected it to reflect.
• Read automatic recompilation operations.
• Ask the platform operator to inspect effective scheduling and bounded logs.
• Use policy:audit only when operation inspection becomes necessary.

An author can report the policy, source change, and visible history. An author need not obtain cluster access or system-configuration authority.

Establish Whether a Cycle Should Run

Establish eligibility and effective scheduling first:

1. Confirm that the policy has an approved governed revision. Saving an unapproved draft does not place its proposed changes into this process.
2. Record the source change and its timestamp. Include the expected effect without assuming that every change alters compiled output.
3. Ask the operator to check the effective policy_recompile_interval_seconds setting. The default is 300 seconds. Nonpositive values disable scheduling.
4. Ask the operator to inspect cycle outcomes after the source change. Cycles wait before running, and execution adds time to the interval.

The interval is not a completion deadline or an immediate change-event trigger. Do not restart Policy to force a cycle. Policy exposes no public run-now endpoint for this task. Follow deployment change control before enabling a disabled schedule.

Choose the Matching Outcome

Use this table to match a recompilation outcome with the appropriate next action:

An input-refresh failure does not authorize compilation against cached discovery. Blocking cycles preserve the previous governed set. The governed set is the current governed policy content considered together during validation. Do not assume that a missing minor revision means that Policy ignored the schedule. Unchanged output intentionally creates neither a new version nor publication work.

Resolve the Cause and Observe the Next Cycle

Complete the following steps:

1. Preserve the cycle’s time, outcome, and sanitized diagnostics. Include the affected policy and effective settings in the incident record.
2. Send connection errors to the named integration’s administrator, or policy validation errors to the author and reviewer. Do not change author intent merely to clear an operational failure.
3. Observe the next scheduled cycle after correction. Use its actual outcome rather than assuming success after a fixed wait.
4. Inspect permitted policy history for changed compilation output. Automatic recompilation preserves authored intent, approval identity, and open drafts.
5. Inspect subsequent publication separately when output changes. A compilation minor and queued work do not prove protection.

If intended policy content must change, use the normal authoring and governance journey. Deployment retry sends retained artifacts. It does not request automatic recompilation. Legacy adoption or blocked delivery can require separate authorized decisions. Do not promise that another cycle will resolve them automatically.

Verification and Stop Conditions

For unchanged output, confirm a successful cycle using fresh inputs. For changed output, confirm the new compilation minor and associated publication work. Then follow the Data or Guardrails verification guide.

Stop and escalate when repeated cycles fail, the outcome remains unavailable, or a required action exceeds your authority. Include effective scheduling, observed outcomes, and the dependency owner’s findings.