Conditional Approval Expiry and Re-Approval Prompt

This prompt is designed for compliance engineers, platform teams, and operations leads who manage time-bounded approvals in automated workflows. Its job is to evaluate a previously granted approval against expiry conditions—such as elapsed time, changes in the target environment, new risk factors, or policy updates—and output a structured decision on whether the approval is still valid, has expired, or requires re-approval. The ideal user is someone integrating AI into a system of record where stale permissions create a compliance or security risk, and where the logic for expiry is too dynamic to hardcode.

To use this prompt effectively, you must provide the original approval record (including its timestamp, scope, and conditions), the current state of the target environment, and any relevant policy documents that define expiry rules. The prompt expects these as structured inputs, not as a conversational history. It is not designed for initial approval routing—use a sibling prompt like Role-Based Approval Routing for first-time decisions. It also should not be used as a real-time authorization engine; its output is a recommendation that should be logged, reviewed, and then enforced by an application-layer gate.

A concrete implementation would wire this prompt into a scheduled job or an event-driven hook that fires before a gated action executes. For example, a deployment pipeline might call this prompt with the original change advisory board (CAB) approval and the current deployment window. The prompt would return an EXPIRED status if the window has shifted, along with the re-approval routing path. Always validate the output against a schema that requires an explicit status field (VALID, EXPIRED, RE_APPROVAL_REQUIRED) and a routing array. In high-risk domains, the prompt's decision should be treated as a recommendation that a human reviews before the system blocks or allows the action.

Do not use this prompt when the expiry logic is purely deterministic and can be expressed as a simple timestamp comparison in application code. Its value is in handling conditional expiry where the rules are nuanced, policy-driven, or require reasoning about environmental changes. Before putting this into production, build a test suite with cases for: an approval that is clearly expired by time, one that is still valid, one where the environment has changed in a way that should trigger re-approval, and one where the policy itself has been updated. These tests will catch the most common failure mode: the model missing a subtle environmental change that should invalidate the approval.

This prompt template is designed to be the core decision engine for time-bounded and condition-bounded approvals. It takes a previously granted approval, its original context, and the current state, then produces a structured JSON decision. The prompt is built to be wired into an application harness that supplies the dynamic context, parses the output, and routes the result to either an automated continuation path or a human re-approval queue. The primary goal is to prevent stale or invalid approvals from silently authorizing high-risk actions.

codeCopy
You are an approval validity evaluator for a compliance-critical system. Your task is to determine if a previously granted approval remains valid or has expired and requires re-approval.

Evaluate the [ORIGINAL_APPROVAL] against the [CURRENT_CONTEXT] using the [EXPIRY_POLICY].

[ORIGINAL_APPROVAL]: {
  "approval_id": "[APPROVAL_ID]",
  "action_type": "[ACTION_TYPE]",
  "requestor": "[REQUESTOR]",
  "approver": "[APPROVER]",
  "granted_timestamp": "[GRANTED_TIMESTAMP]",
  "original_conditions": {
    "environment": "[ORIGINAL_ENVIRONMENT]",
    "risk_score": [ORIGINAL_RISK_SCORE],
    "data_scope": "[ORIGINAL_DATA_SCOPE]",
    "justification": "[ORIGINAL_JUSTIFICATION]"
  },
  "approval_type": "[APPROVAL_TYPE]"
}

[CURRENT_CONTEXT]: {
  "evaluation_timestamp": "[EVALUATION_TIMESTAMP]",
  "current_environment": "[CURRENT_ENVIRONMENT]",
  "current_risk_score": [CURRENT_RISK_SCORE],
  "current_data_scope": "[CURRENT_DATA_SCOPE]",
  "environmental_changes": [
    "[CHANGE_DESCRIPTION_1]",
    "[CHANGE_DESCRIPTION_2]"
  ],
  "new_risk_factors": [
    "[NEW_RISK_FACTOR_1]"
  ]
}

[EXPIRY_POLICY]: {
  "max_age_hours": [MAX_AGE_HOURS],
  "risk_score_tolerance": [RISK_SCORE_TOLERANCE],
  "environment_change_triggers_expiry": [true/false],
  "data_scope_change_triggers_expiry": [true/false],
  "new_risk_factor_triggers_expiry": [true/false]
}

[OUTPUT_SCHEMA]: {
  "approval_id": "string",
  "is_valid": boolean,
  "expiry_reason": "string | null",
  "re_approval_required": boolean,
  "re_approval_routing": {
    "required_approver_role": "string | null",
    "escalation_reason": "string | null",
    "priority": "low | medium | high | critical"
  },
  "evaluation_summary": "string"
}

[CONSTRAINTS]:
1. If the time elapsed since `granted_timestamp` exceeds `max_age_hours`, the approval is invalid and re-approval is required. Set `expiry_reason` to "TIME_EXPIRED".
2. If `environmental_changes` is not empty and `environment_change_triggers_expiry` is true, the approval is invalid. Set `expiry_reason` to "ENVIRONMENT_CHANGED".
3. If the `current_risk_score` exceeds `original_risk_score` by more than `risk_score_tolerance`, the approval is invalid. Set `expiry_reason` to "RISK_INCREASED".
4. If `current_data_scope` differs from `original_data_scope` and `data_scope_change_triggers_expiry` is true, the approval is invalid. Set `expiry_reason` to "DATA_SCOPE_CHANGED".
5. If `new_risk_factors` is not empty and `new_risk_factor_triggers_expiry` is true, the approval is invalid. Set `expiry_reason` to "NEW_RISK_FACTOR".
6. If multiple conditions trigger expiry, list the primary reason in `expiry_reason` and summarize all in `evaluation_summary`.
7. If re-approval is required, determine the `required_approver_role` based on the `action_type` and the highest severity trigger. For "TIME_EXPIRED", route to the original approver's role. For "RISK_INCREASED" or "NEW_RISK_FACTOR", route to a Security Officer. For environment or data scope changes, route to a Change Advisory Board.
8. Set `priority` to "critical" if a new risk factor or a risk score increase above tolerance is detected. Set to "high" for environment or data scope changes. Set to "medium" for time expiry.
9. Output only the valid JSON object specified in [OUTPUT_SCHEMA]. Do not include any other text or markdown fences.

To adapt this template, replace the square-bracket placeholders with actual values from your application's state. The [EXPIRY_POLICY] object should be sourced from a configuration service or policy document, not hardcoded, as these thresholds will change over time. The [ORIGINAL_APPROVAL] should be fetched from an audit log or approvals database, and the [CURRENT_CONTEXT] must be assembled by querying your live infrastructure, risk scoring engine, and change management system. The final paragraph of the prompt enforces strict JSON-only output, which is critical for reliable parsing in a production pipeline. Before deploying, test this prompt with a golden dataset that includes cases where no conditions have changed, where only time has elapsed, and where multiple expiry triggers fire simultaneously to ensure the routing logic behaves as expected.

This prompt is designed to be called as a policy evaluation step within a larger approval workflow, not as a standalone chatbot. It should sit between an action's execution request and the approval routing logic. When a previously approved action is re-submitted—whether due to a delayed execution, a retry, or a periodic review—the application calls this prompt to determine if the original approval is still valid. The prompt's output is a structured decision that downstream code uses to either proceed, block, or re-route for re-approval. Treat this as a deterministic policy gate with an AI reasoning layer, not as an advisory suggestion.

Integration pattern: The application should maintain a record of the original approval event, including a timestamp, the approving parties, the approved action payload, and a snapshot of the conditions at the time of approval (e.g., risk score, environment, data sensitivity). When re-evaluation is triggered, assemble these fields into the [PREVIOUS_APPROVAL] and [CURRENT_CONDITIONS] placeholders. The [EXPIRY_POLICY] placeholder should be injected from a configuration store, not hardcoded in the prompt, so that policy changes (e.g., shortening the approval window from 72 to 24 hours) take effect immediately without a prompt update. After receiving the model's output, validate the JSON schema strictly: expiry_status must be one of VALID, EXPIRED, or CONDITION_CHANGED. If re_approval_required is true, the re_approval_routing array must contain at least one role object with a role and reason field. Reject and retry any response that fails schema validation.

Retry and fallback logic: If the model returns malformed JSON after two retries, or if the confidence score (if your model provides token-level logprobs) falls below a defined threshold, do not guess. Escalate to a human operator with the full context packaged by the prompt's output schema. Log every evaluation—including the model's raw response, the validated output, and any override decisions—to an audit table. This is critical for compliance use cases where you must prove that expiry checks occurred and were acted upon correctly. For high-risk domains (finance, healthcare, access control), always require a human to confirm any EXPIRED or CONDITION_CHANGED determination before blocking an action, unless the system is explicitly designed for fully automated gating with a documented risk acceptance.

Avoiding re-approval loops: A common failure mode is a re-approval loop where the same unchanged conditions trigger repeated expiry. To prevent this, your application should compare the [CURRENT_CONDITIONS] snapshot against the conditions that existed when the most recent re-approval was granted, not just the original approval. If the conditions are identical and the time window has not elapsed, suppress the re-evaluation call entirely and treat the approval as valid. The prompt itself can help detect this by including an unchanged_condition_loop flag in the output schema, but the primary defense should be in the application's state machine. Wire this prompt into a workflow engine that tracks approval lineage, not just a single approval record.