Staged Autonomy Policy Definition Prompt

This prompt is for AI governance leads and risk managers who need to create a single, comprehensive master policy document that defines every autonomy stage, transition gate, and operational rule for an AI system. Use it when you are designing a new autonomous system from scratch, formalizing an existing ad-hoc autonomy implementation, or preparing for a compliance audit that requires a documented policy specification. The output is a structured policy artifact that engineering teams can implement directly and governance teams can review.

Do not use this prompt for evaluating a single gate decision or defining a one-off reversion trigger; those tasks have dedicated sibling prompts in this content group. This prompt is also inappropriate when you only need a lightweight operational runbook—it produces a full specification with stage definitions, transition rules, authority scopes, exception handling, and consistency validation. Before running this prompt, gather your system's action catalog, known risk categories, existing human-approval workflows, and any regulatory constraints that must be encoded as policy rules.

After generating the master policy, validate it against the sibling prompts for gate evaluation, reversion triggers, and audit trail generation to ensure the policy is both complete and implementable. Avoid treating the output as a static document; it should be version-controlled alongside your system configuration and updated whenever new capabilities, risk findings, or regulatory requirements emerge.

This prompt template is the core engine for defining your system's graduated autonomy. It takes your high-level requirements—such as the system's purpose, risk tolerance, and available tools—and produces a structured policy specification. The template is designed to be pasted directly into the system message of a capable frontier model. The square-bracket placeholders are the only parts you need to replace before execution. The prompt's internal structure enforces a logical flow: it first defines the context, then demands a specific output schema, and finally imposes strict validation rules to ensure the resulting policy is internally consistent and complete.

markdownCopy
You are an AI Governance Architect. Your task is to generate a comprehensive Staged Autonomy Policy for an AI system based on the provided inputs. The policy must be precise, internally consistent, and ready for human review.

## INPUTS
- **System Purpose:** [SYSTEM_PURPOSE_DESCRIPTION]
- **Available Actions/Tools:** [LIST_OF_ALL_ACTIONS_AND_TOOLS]
- **Risk Classification:** [RISK_LEVEL: LOW, MEDIUM, HIGH, CRITICAL]
- **Performance Metrics Available:** [LIST_OF_MEASURABLE_PERFORMANCE_METRICS]
- **Regulatory or Compliance Constraints:** [LIST_OF_APPLICABLE_REGULATIONS_OR_NONE]
- **Stakeholder Roles:** [LIST_OF_HUMAN_ROLES_FOR_APPROVAL_AND_OVERSIGHT]

## OUTPUT SCHEMA
Generate a JSON policy document with the following structure. Do not include any text outside the JSON object.
{
  "policy_name": "string",
  "version": "1.0",
  "stages": [
    {
      "stage_id": "string (e.g., 'STAGE_0_SHADOW')",
      "stage_name": "string (e.g., 'Shadow Mode')",
      "description": "string",
      "authority_scope": {
        "allowed_actions": ["action_id"],
        "blocked_actions": ["action_id"],
        "requires_approval_for": ["action_id"]
      },
      "promotion_criteria": {
        "performance_gates": [
          {
            "metric": "string",
            "threshold": "string (e.g., '>= 0.95')",
            "measurement_window_days": "integer"
          }
        ],
        "minimum_duration_days": "integer",
        "human_review_requirement": "string (e.g., 'All actions reviewed')"
      },
      "demotion_triggers": [
        {
          "trigger_id": "string",
          "condition": "string (e.g., 'error_rate > 0.05')",
          "severity": "string (e.g., 'HIGH')",
          "immediate_action": "string (e.g., 'REVERT_TO_STAGE_0')"
        }
      ]
    }
  ],
  "global_rules": {
    "maximum_autonomy_stage": "string",
    "default_incident_stage": "string",
    "audit_log_requirements": ["string"]
  }
}

## CONSTRAINTS
1. **Completeness:** Every action from the `Available Actions/Tools` list must be explicitly categorized as `allowed`, `blocked`, or `requires_approval_for` in every stage.
2. **Consistency:** A promotion to a higher stage must grant strictly greater or equal authority than the previous stage. A demotion trigger must always revert to a lower-authority stage.
3. **Risk Alignment:** For a [RISK_LEVEL] of HIGH or CRITICAL, the `maximum_autonomy_stage` must not grant `allowed_actions` for irreversible or high-impact operations without a `requires_approval_for` condition.
4. **Grounding:** Base all promotion criteria and demotion triggers only on the `Performance Metrics Available` list. Do not invent metrics.
5. **Regulatory Check:** If `Regulatory or Compliance Constraints` are provided, add a `compliance_gate` object to each stage explaining how the stage's rules satisfy the listed constraints.

## VALIDATION (SELF-CHECK BEFORE OUTPUT)
Before finalizing the JSON, perform the following checks internally and correct any violations:
- **Action Coverage Check:** Is every input action present in every stage's scope?
- **Progression Check:** Does each successive stage have a superset of the previous stage's `allowed_actions`?
- **Reversion Check:** Does every `demotion_trigger.immediate_action` point to a valid, lower `stage_id`?
- **Metric Check:** Are all referenced metrics in `promotion_criteria` present in the `Performance Metrics Available` input list?

To adapt this template, start by meticulously filling in the INPUTS section. The quality of the generated policy is directly dependent on the precision of your inputs. For instance, instead of a vague action like 'manage data,' list specific API calls: ['database:delete_record', 'database:update_schema', 'api:send_notification']. After running the prompt, the self-validation step will catch many structural errors, but you must still manually review the output for semantic correctness. Pay close attention to the demotion_triggers to ensure they are not so sensitive that they cause flapping between stages, or so insensitive that they fail to catch real degradation. The final policy document should be treated as a draft for stakeholder review, not a production-ready configuration to be deployed directly.

This prompt is not a one-off document generator; it is a policy compiler that should be integrated into a version-controlled governance pipeline. The generated policy specification must be treated as a candidate artifact that requires human review, consistency validation, and explicit approval before it governs any production system. Wire the prompt into a workflow that accepts a [SYSTEM_DESCRIPTION], [RISK_TOLERANCE], and [REGULATORY_CONTEXT] as structured inputs, produces a draft policy, runs automated validation checks, and then routes the output to a human governance lead for sign-off. The output should be stored in a policy registry with a unique version identifier, timestamp, and authoring context so that every autonomy stage definition is auditable.

Validation layer. Before the policy reaches a human reviewer, run automated consistency checks against the generated output. Validate that every defined stage has a unique name, clear entry criteria, explicit exit criteria, a bounded authority scope, and at least one reversion trigger. Check for orphaned transitions—stages that can be entered but never exited, or stages referenced in transition rules but never defined. Verify that high-risk actions (e.g., data deletion, financial writes, configuration changes) are not permitted at low-autonomy stages without explicit human approval. Implement a schema validator that enforces the expected output structure: a JSON object with stages, transitions, authority_scopes, reversion_triggers, and exception_handling sections. If validation fails, route the output to a repair loop that feeds the errors back to the model with a structured correction request before human review.

Model choice and tool use. This prompt benefits from a model with strong reasoning and structured output capabilities. Use a model that supports strict JSON mode or function calling to enforce the output schema. If the policy must reference existing organizational policies, wire a retrieval step before the prompt that pulls relevant internal governance documents, compliance requirements, and existing autonomy policies into the [CONTEXT] placeholder. Do not rely on the model's parametric knowledge for your organization's specific rules. For high-stakes deployments, consider a two-pass architecture: first generate the policy, then run a separate evaluation prompt that acts as a adversarial reviewer, checking for gaps, contradictions, and safety blind spots before the policy reaches a human.

Human review and approval gates. The final policy must never be deployed without human approval. Route the validated draft to a review queue with a structured approval interface that shows: the full policy document, the validation report, any flagged risks or gaps, and a diff against the previous policy version if one exists. Require explicit sign-off from at least one governance lead, and log the approval with a timestamp and reviewer identity. For multi-stakeholder environments, extend the workflow to route different sections (e.g., financial authority scopes, data access rules) to domain-specific reviewers before final assembly. The prompt's output is the starting point for a governance decision, not the decision itself.