Outdated Policy Detection Prompt for Copilots

This prompt is designed for a specific operational control point: a pre-response guardrail or a scheduled audit workflow that verifies a copilot's active behavioral policy is not stale. The job-to-be-done is preventing a compliance-sensitive assistant from operating on a superseded instruction set, which could lead to regulatory exposure or inconsistent user experiences. The ideal user is an MLOps engineer, a platform reliability team, or a compliance officer responsible for the governance of AI-assisted workflows. They need to programmatically confirm that the active_policy_version in the assistant's system prompt matches the latest_policy_version from a trusted registry before the assistant is allowed to act on high-stakes turns.

You should not use this prompt in the hot path of every user interaction. Running a version comparison on every turn adds latency and token cost without proportional benefit when policies change infrequently. Instead, wire it into two specific harnesses: a scheduled audit job that checks policy freshness at a regular interval (e.g., every 15 minutes) and logs a staleness event if a mismatch is detected, and a pre-response guardrail that activates only for turns classified as high-risk or compliance-sensitive. The prompt requires a structured input context containing the [ACTIVE_POLICY_IDENTIFIER], the [ACTIVE_POLICY_VERSION], and a [POLICY_REGISTRY_SNAPSHOT] that includes the latest version and its release timestamp. Without this explicit context, the model cannot perform a reliable comparison and may hallucinate version information.

A critical constraint is that this prompt's output is a structured staleness assessment, not an automatic policy update. If a staleness flag is raised, the recommended action is to block the assistant's response on the current turn and escalate for human review. A human must validate the policy diff, assess the compliance impact, and approve the constraint update before the new policy is injected into the system prompt. Do not build an autonomous self-updating loop, as an error in the registry or a malicious policy update could instantly compromise the assistant's behavior. The next step after detecting staleness is to route the structured mismatch details to a review queue, not to a prompt rewriter.

This prompt is designed to be pasted directly into your policy audit workflow. It compares the assistant's current behavioral policy, instruction set, or rule base against a provided latest version to detect staleness. The output is a structured staleness flag, a version mismatch summary, and recommended constraint updates. Because policy changes can carry compliance impact, the prompt explicitly requires human review for any detected mismatch before deployment changes are made.

textCopy
You are a policy audit assistant for a regulated copilot deployment. Your task is to compare the assistant's current behavioral policy against the latest approved policy version and detect any staleness, conflicts, or missing constraints.

# INPUTS

[CURRENT_POLICY]
{The assistant's active behavioral policy, system instructions, or rule base. This is the policy currently enforced in production.}

[LATEST_POLICY]
{The most recently approved policy version. This is the source of truth against which the current policy is evaluated.}

[POLICY_METADATA]
{Optional. Version numbers, effective dates, approval IDs, and change descriptions for both policies.}

[COMPLIANCE_DOMAIN]
{The regulatory or compliance domain governing this policy, e.g., HIPAA, SOC 2, GDPR, PCI-DSS, internal InfoSec policy.}

# TASK

1. Compare [CURRENT_POLICY] against [LATEST_POLICY] field by field, constraint by constraint.
2. Identify any of the following mismatch types:
   - MISSING_CONSTRAINT: A rule present in [LATEST_POLICY] but absent from [CURRENT_POLICY].
   - CONFLICTING_CONSTRAINT: A rule that exists in both but with contradictory requirements.
   - WEAKENED_CONSTRAINT: A rule in [CURRENT_POLICY] that is less restrictive than [LATEST_POLICY] requires.
   - DEPRECATED_CONSTRAINT: A rule in [CURRENT_POLICY] that has been removed or superseded in [LATEST_POLICY].
   - VERSION_MISMATCH: The version identifier of [CURRENT_POLICY] does not match the expected latest version.
3. For each mismatch, provide:
   - The specific rule or constraint text from both policies.
   - The mismatch type.
   - The compliance risk if the mismatch is not resolved.
   - A recommended update to bring [CURRENT_POLICY] into alignment.
4. Produce a staleness flag: STALE if any mismatches are found, CURRENT if the policies are identical in substance.

# OUTPUT SCHEMA

Return a JSON object with this exact structure:
{
  "staleness_flag": "STALE" | "CURRENT",
  "version_comparison": {
    "current_version": "string | null",
    "latest_version": "string | null",
    "version_match": true | false
  },
  "mismatches": [
    {
      "mismatch_type": "MISSING_CONSTRAINT" | "CONFLICTING_CONSTRAINT" | "WEAKENED_CONSTRAINT" | "DEPRECATED_CONSTRAINT" | "VERSION_MISMATCH",
      "current_policy_text": "string",
      "latest_policy_text": "string",
      "compliance_risk": "string",
      "recommended_update": "string"
    }
  ],
  "summary": "A concise summary of findings suitable for a compliance reviewer.",
  "human_review_required": true
}

# CONSTRAINTS

- If [CURRENT_POLICY] and [LATEST_POLICY] are identical in substance, return staleness_flag: CURRENT with an empty mismatches array.
- If version numbers are provided and do not match, flag a VERSION_MISMATCH even if the text appears identical.
- For any mismatch in a regulated domain, set human_review_required to true.
- Do not fabricate mismatches. Only report differences you can cite from the provided text.
- If [COMPLIANCE_DOMAIN] is provided, assess each compliance_risk in the context of that domain's requirements.
- If [POLICY_METADATA] is empty or unavailable, note that version verification is limited.

To adapt this prompt, replace the square-bracket placeholders with your actual policy documents. The [CURRENT_POLICY] should be pulled from your production system prompt or policy store at runtime. The [LATEST_POLICY] should be fetched from your policy registry or approval system. Wire the output into a deployment gate: if staleness_flag is STALE and human_review_required is true, block automated policy updates and route the mismatch report to a compliance reviewer. For high-stakes domains, always require a human to sign off on the recommended_update before applying any changes to production.

This prompt is designed to run as a scheduled or event-driven check within a copilot deployment pipeline, not as a real-time user-facing interaction. The primary trigger is a policy version change event—when a new policy document is published to the internal policy registry, the harness should execute this prompt with the [CURRENT_POLICY] representing the assistant's active behavioral contract and the [LATEST_POLICY] representing the newly published version. The model choice should favor a high-capability, instruction-following model (such as Claude 3.5 Sonnet or GPT-4o) because the task requires precise comparison of structured policy documents and reliable extraction of version mismatch details. Do not use a smaller, faster model for this workflow; the cost of a missed policy update in a regulated domain far exceeds the inference cost of a capable model.

The application harness must enforce a strict validation layer on the model's output before any policy change is applied to the copilot. Parse the JSON output and validate that the policy_staleness_flag is a boolean, that version_mismatch_details contains non-empty strings when staleness is detected, and that recommended_constraint_updates is a valid array of constraint objects with field, old_value, and new_value keys. If the output fails schema validation, retry once with the same inputs and a stronger constraint instruction appended to the prompt. If the retry also fails, log the failure, alert the on-call channel, and block the policy update—never silently apply a policy change when the detection output is malformed. For compliance-impacting changes, the harness must route the output to a human review queue before any automated policy update is applied. The review queue should present the full prompt output alongside a diff of the old and new policy documents, and require explicit approval from an authorized reviewer. Log every execution—including model, timestamp, input hashes, raw output, validation result, retry count, and reviewer decision—to an append-only audit store for governance traceability.

When wiring this into a CI/CD pipeline for copilot policy updates, treat the prompt output as a gating signal. If policy_staleness_flag is true and the compliance_impact field indicates a material change, the deployment pipeline must halt and await human approval. If the flag is false, the pipeline can proceed, but the harness should still log the negative result for audit completeness. Avoid the temptation to cache or skip executions when no obvious policy change is visible—policy documents can be updated with subtle but important constraint modifications that only a thorough comparison will catch. The harness should also maintain a version history of policy documents and prompt outputs, enabling retrospective analysis of when a policy became stale and why the detection fired or missed. Finally, test this harness with a golden dataset of known policy version pairs—including identical documents, minor wording changes, and substantive constraint updates—to calibrate the detection threshold and measure false-positive and false-negative rates before production deployment.