Time-Boxed Autonomy Window Prompt Template

This prompt is designed for the specific job of generating a machine-readable authority specification that defines a time-boxed autonomy window. Use it when you have a system operating at a known, lower autonomy stage and need to temporarily elevate its permissions for a defined scope and duration. The ideal user is a platform engineer or an operations lead who already has defined autonomy stages and needs a precise, auditable grant on top of them, not a permanent policy change. The required context includes the current autonomy stage, the specific actions being authorized, the exact start time and duration, and the conditions that must trigger an immediate reversion to the lower stage.

This prompt is not a tool for defining permanent autonomy policies or for systems where the boundaries of authority are static. It assumes a dynamic operational environment where temporary elevation is necessary for tasks like a one-time data migration, a critical patch window, or a supervised troubleshooting session. The output is a structured specification meant to be consumed by an orchestration layer, not a human-readable policy document. You should wire the resulting specification into an application harness that enforces the time bounds, monitors for reversion triggers, and logs the entire window's activity for audit. Do not use this prompt for open-ended autonomy grants or for defining the initial autonomy stages themselves.

Before using this prompt, ensure you have a clear definition of the reversion triggers. Common failure modes include clock-skew between the AI system and the enforcing application, and ambiguous grace-period logic at the window's expiration. The prompt template includes placeholders for these edge cases, but the implementation harness must handle them with precise logic. After generating the specification, your next step is to validate it against your system's authorization schema and then deploy it within a tightly scoped execution environment that can enforce an automatic, irreversible reversion.

This prompt template generates a precise, time-bound authority specification for granting an AI system temporary autonomy. It is designed for operations teams who need to define exactly when an autonomy window starts, how long it lasts, what actions are permitted, and what conditions cause immediate reversion. The output is a structured specification that can be parsed by an application harness to enforce the window programmatically.

textCopy
You are an autonomy policy generator for AI operations. Your task is to produce a complete, machine-readable time-boxed autonomy window specification based on the provided context. The specification must be unambiguous and include all edge cases.

## Inputs
- [REQUESTED_ACTIONS]: The specific actions or capabilities being granted for the window.
- [WINDOW_DURATION]: The maximum duration of the autonomy window (e.g., '4 hours', '30 minutes').
- [START_CONDITION]: The event or signal that triggers the window to open (e.g., 'on-call engineer acknowledges page', 'deployment pipeline reaches stage 3').
- [OPERATIONAL_CONTEXT]: The system, environment, or scope where autonomy applies (e.g., 'production-us-east-1 cluster', 'customer ID 4523').
- [MAX_RISK_LEVEL]: The highest risk classification of action permitted during the window (e.g., 'MEDIUM', 'LOW').
- [REVERSION_TRIGGERS]: A list of conditions that immediately close the window and revoke autonomy, regardless of remaining time.
- [APPROVING_AUTHORITY]: The role or individual authorizing this window.
- [NOTIFICATION_CHANNELS]: Where to send window-open, window-close, and reversion alerts.

## Output Schema
Generate a JSON object with the following structure:
{
  "window_id": "string",
  "status": "PENDING_APPROVAL",
  "granted_by": "[APPROVING_AUTHORITY]",
  "scope": {
    "actions": ["string"],
    "environment": "[OPERATIONAL_CONTEXT]",
    "max_risk_level": "[MAX_RISK_LEVEL]"
  },
  "temporal_bounds": {
    "start_condition": "[START_CONDITION]",
    "max_duration_seconds": <integer>,
    "grace_period_seconds": <integer>,
    "expiration_behavior": "HARD_STOP"
  },
  "reversion_policy": {
    "immediate_triggers": ["string"],
    "on_expiration": "REVOKE_ALL_AND_LOG",
    "on_violation": "REVOKE_IMMEDIATELY_AND_ALERT"
  },
  "clock_skew_handling": {
    "max_tolerated_drift_seconds": 30,
    "drift_resolution": "TRUST_SYSTEM_CLOCK"
  },
  "notifications": {
    "channels": ["string"],
    "on_open": true,
    "on_close": true,
    "on_reversion": true
  },
  "audit_log_required": true
}

## Constraints
- The `max_duration_seconds` must be calculated from [WINDOW_DURATION].
- The `grace_period_seconds` must be a small, justifiable buffer (default 60 seconds) to allow in-flight actions to complete. It must not exceed 5% of the total window duration.
- Every action in [REQUESTED_ACTIONS] must appear in `scope.actions`.
- If [MAX_RISK_LEVEL] is 'HIGH' or 'CRITICAL', add a `required_secondary_approval: true` field to the root object.
- If any [REVERSION_TRIGGERS] include error-rate thresholds, include the specific metric and threshold in the trigger description.
- The `window_id` must be a unique, traceable identifier.

After copying this template, replace every square-bracket placeholder with values from your operational context. The model will produce a JSON specification that your application harness can parse to enforce the window. Validate the output against the schema before activating the window. For high-risk windows, route the generated specification through a human approval step before the start_condition is allowed to trigger.

The Time-Boxed Autonomy Window prompt is not a one-shot generator; it is a policy compiler. The application layer must treat the prompt's output as a machine-readable authority specification that is parsed, validated, and enforced by the runtime system. The prompt produces a structured window definition—start conditions, duration, scope limits, and reversion triggers—but the application is responsible for interpreting that specification, enforcing the clock, and executing the reversion when the window expires or a trigger fires. This means the implementation harness must include a policy parser, a clock-skew-tolerant timer, a scope enforcement layer, and a reversion executor that is guaranteed to run even if the primary agent process fails.

Wire the prompt into a pre-action authorization pipeline. Before the AI agent executes any action that falls under a potentially gated scope, the harness checks: (1) Is there an active autonomy window? (2) Does the current wall-clock time fall within the window's [START_TIME] and [EXPIRATION_TIME], accounting for a configurable grace period (default 30 seconds) to handle clock skew and propagation delay? (3) Does the requested action fall within the window's [SCOPE_LIMITS]? If all conditions are met, the action proceeds. If any condition fails, the harness must block the action and either escalate to a human reviewer or revert to the default supervised mode. The window specification itself should be stored in a durable, versioned record—such as a database row or a signed configuration object—so that the enforcement layer does not depend on the agent's in-memory state. Log every authorization decision with the window ID, timestamp, action, and decision for auditability.

Build validation and retry logic around the prompt's output, not inside it. After the model returns the window specification, run a strict schema validator that checks: required fields (window_id, start_condition, duration_seconds, scope_limits, reversion_triggers), valid ISO 8601 duration format, non-empty scope limits, and at least one reversion trigger. If validation fails, retry the prompt once with the validation errors injected into the [CONSTRAINTS] or as a follow-up correction message. If the second attempt also fails, log the failure, block any autonomy grant, and escalate to an on-call engineer. For high-risk domains, add a human approval step before the window is activated: present the parsed specification in a human-readable summary, require explicit confirmation, and record the approver's identity and timestamp. Never activate a time-boxed autonomy window without a guaranteed reversion path—implement a dead-man's switch using a persistent timer (e.g., a scheduled job or a message queue delayed message) that forcibly revokes the window when the expiration time is reached, independent of the agent process's health.