Conditional Autonomy Expansion Prompt

This prompt is for platform engineers and AI product leads who need to generate a conditional policy that dynamically expands or restricts an AI system's autonomy based on specific operational contexts. The job-to-be-done is translating a high-level business rule—like 'the agent can auto-approve refunds under $50 during business hours for VIP customers'—into a structured, machine-readable policy mapping. The ideal user is someone building an AI harness that must enforce context-dependent authority rules, not a static role-based access control list. You need a policy specification that can be directly consumed by an orchestration engine, a guardrails service, or a human-in-the-loop review queue.

Use this prompt when you have a clear set of contextual factors—such as user role, risk score, time of day, geographic region, or action value—that should modulate the system's autonomy level. It is most effective when the desired output is a complete policy object, including explicit ALLOW, DENY, and ESCALATE rules, along with the conditions that trigger them. You should not use this prompt for defining the initial, baseline autonomy stages for a new system; that is the job of the Staged Autonomy Policy Definition Prompt. Similarly, if your goal is to define the performance metrics that gate a permanent stage promotion, use the Performance Gate Criteria Definition Prompt instead. This prompt is specifically for runtime, context-dependent adjustments within an already-defined stage framework.

Before using this prompt, you must have a clear inventory of the contextual signals available to your system at decision time (e.g., user.tier, transaction.amount, request.geolocation). The prompt's effectiveness depends on the quality and specificity of the [CONTEXTUAL_FACTORS] you provide. A vague input like 'consider user risk' will produce a vague, un-implementable policy. A precise input like 'FACTOR: user_risk_score (integer 0-100), SOURCE: fraud_service API' will yield a concrete, testable rule. After generating the policy, you must validate it for completeness gaps (unhandled context combinations) and policy conflicts (contradictory rules) using the evaluation criteria described in the implementation harness. Do not deploy a generated policy without running these conflict-detection and gap-analysis evals.

This prompt template is designed to produce a structured, machine-readable policy for conditional autonomy expansion. It forces the model to reason about specific operational contexts, user roles, and environmental factors before granting or restricting authority. The output is a policy document that can be parsed by an application to dynamically adjust an agent's tool access, approval requirements, and action limits at runtime. Use this when you need a context-dependent authority map that goes beyond simple static stages.

textCopy
You are an AI policy architect designing a conditional autonomy expansion policy for an AI agent. Your task is to produce a strict, structured policy that maps specific operational contexts to expanded or restricted autonomy levels. The policy must be unambiguous and directly usable by an application's authorization layer.

## INPUTS
- Agent Role and Base Autonomy Level: [AGENT_ROLE_AND_BASE_LEVEL]
- Available Actions and Tools: [AVAILABLE_ACTIONS_AND_TOOLS]
- Operational Contexts to Evaluate: [OPERATIONAL_CONTEXTS]
- User Roles and Attributes: [USER_ROLES_AND_ATTRIBUTES]
- Environmental Factors: [ENVIRONMENTAL_FACTORS]
- Risk Tolerance and Constraints: [RISK_TOLERANCE_AND_CONSTRAINTS]

## OUTPUT SCHEMA
You must output a single JSON object conforming to this exact structure. Do not include any text outside the JSON object.
{
  "policy_name": "string",
  "version": "string",
  "base_autonomy_level": "string",
  "context_rules": [
    {
      "rule_id": "string",
      "description": "string",
      "condition": {
        "all_of": [
          {
            "factor": "string (e.g., 'user_role', 'time_of_day', 'data_sensitivity')",
            "operator": "string (e.g., 'equals', 'in', 'greater_than', 'matches')",
            "value": "string or array"
          }
        ],
        "any_of": []
      },
      "autonomy_modifier": {
        "new_level": "string (e.g., 'expanded', 'restricted', 'full', 'none')",
        "granted_actions": ["string"],
        "requires_approval": ["string"],
        "approval_roles": ["string"],
        "time_to_live_seconds": "integer or null"
      },
      "priority": "integer (lower number = higher priority)",
      "conflict_resolution": "string (e.g., 'most_restrictive', 'highest_priority')"
    }
  ],
  "default_rule": {
    "autonomy_modifier": {
      "new_level": "string",
      "granted_actions": ["string"],
      "requires_approval": ["string"]
    }
  },
  "policy_gaps": [
    {
      "gap_description": "string",
      "severity": "string (high, medium, low)",
      "recommendation": "string"
    }
  ]
}

## CONSTRAINTS
1. Every rule must have a unique `rule_id`.
2. Conditions must be based only on the provided inputs. Do not invent new factors.
3. The `default_rule` must be the safest possible configuration if no context rules match.
4. Explicitly identify any `policy_gaps` where the provided inputs are insufficient to make a safe autonomy decision. A gap exists if a plausible operational scenario is not covered by any rule.
5. For any action that is irreversible, involves PII, or has financial impact, `requires_approval` must be set to `true` and `approval_roles` must be populated.
6. If the `new_level` is 'expanded' or 'full', the `time_to_live_seconds` field must be set to enforce automatic reversion.

To adapt this template, replace the square-bracket placeholders with concrete data from your application's context. The OPERATIONAL_CONTEXTS input should be a structured list of scenarios you want the policy to cover, such as 'user is a database administrator performing a schema change during a maintenance window.' The model will use these to generate the context_rules. After generation, validate the output JSON against the schema and check for policy gaps. A critical next step is to run this policy through a conflict detection eval: feed two conflicting contexts to the policy engine and verify the conflict_resolution strategy produces the expected, safe outcome. For high-risk deployments, a human must review and approve the generated policy before it is loaded into any production authorization system.

The Conditional Autonomy Expansion Prompt is not a one-shot generation task; it is a policy synthesis engine that should be integrated into a governed, auditable workflow. The prompt produces a conditional policy mapping, but the application layer is responsible for validating that mapping, resolving conflicts, and enforcing the resulting rules in production. Treat the model's output as a draft policy artifact that requires deterministic validation before it can gate real-world autonomy decisions.

To wire this prompt into an application, first assemble the required inputs: the current autonomy stage definitions, the operational context variables (e.g., user role, time window, risk score, environment), and the existing authority boundaries. Feed these into the prompt template as [AUTONOMY_STAGE_DEFINITIONS], [CONTEXT_VARIABLES], and [AUTHORITY_BOUNDARIES]. The model will return a structured mapping, ideally in a strict JSON schema defined by [OUTPUT_SCHEMA]. Before accepting the output, run it through a policy conflict detector: a deterministic function that checks for overlapping conditions with contradictory autonomy levels, undefined context gaps, and privilege escalation paths. If conflicts are found, log them and either retry the prompt with the conflict report appended as [CONSTRAINTS] or escalate to a human reviewer via a review queue. For high-risk domains, always require human approval before the generated policy is committed to the policy store.

After validation, store the approved policy as a versioned artifact in a policy registry with a unique policy_id, a created_at timestamp, and the approved_by reviewer identity. The application's autonomy gate evaluation loop should then reference this policy ID when making real-time decisions. Log every evaluation event—including the context snapshot, the matched policy rule, and the resulting autonomy level—to an autonomy transition log for auditability. Avoid common failure modes: do not allow the model to directly execute policy changes, do not skip the conflict detection step, and do not deploy a generated policy without a rollback plan. If the model produces an incomplete or ambiguous mapping, fall back to the most restrictive autonomy level defined in your baseline configuration and alert the operations team.