Performance Gate Criteria Definition Prompt

Use this prompt when you need a formal, machine-readable specification for the performance gates that control whether an AI system advances, holds, or reverts autonomy stages. This is not a prompt for evaluating a single action. It is for defining the criteria itself: the metrics, thresholds, measurement windows, and evidence requirements that become the contract for your graduated autonomy system. Engineering leads and risk managers use this before deploying any staged release framework. The output feeds directly into gate evaluation prompts, monitoring dashboards, and compliance documentation.

The ideal user is an engineering lead or risk manager who needs to codify the rules of the road for AI autonomy. You must bring a clear understanding of your system's action categories, the metrics you can reliably measure, and the risk tolerance of your organization. Required context includes the current autonomy stage, the target stage, the specific actions or capabilities under consideration, and the operational data sources available for measurement. Without this context, the prompt will produce a generic template that fails to capture the real-world constraints of your deployment.

Do not use this prompt when you need a one-off risk judgment or a simple pass/fail check on a single output. Those tasks are better served by the Confidence Threshold Escalation Prompt or the Risk Score Threshold and Anomaly Escalation Prompt. This prompt is also not a substitute for the Staged Autonomy Policy Definition Prompt, which defines the master policy document. Instead, this prompt creates the specific, measurable criteria that instantiate that policy for a particular transition. If you are evaluating whether a system currently meets its gates, use the Graduated Autonomy Gate Evaluation Prompt Template. If you are defining the triggers that force an immediate reversion, use the Autonomy Reversion Trigger Prompt.

This prompt instructs the model to act as a reliability architect and produce a formal specification for performance gates that control an AI system's progression through autonomy stages. It is designed to be pasted directly into your AI system after you replace the square-bracket placeholders with your specific system context, risk tolerance, and operational constraints. The output is a structured document, not a conversation, and should be suitable for review by engineering leads, risk managers, and governance teams.

codeCopy
You are a principal reliability architect defining measurable performance gates for an AI system's graduated autonomy. Your task is to produce a formal Performance Gate Criteria Specification based on the provided context.

## SYSTEM CONTEXT
- System Name: [SYSTEM_NAME]
- System Purpose: [SYSTEM_PURPOSE]
- Current Autonomy Stage: [CURRENT_STAGE]
- Target Autonomy Stage: [TARGET_STAGE]
- Action Categories Under Consideration: [ACTION_CATEGORIES]
- Existing Operational Metrics Available: [AVAILABLE_METRICS]
- Risk Tolerance Level: [RISK_TOLERANCE]
- Regulatory Constraints: [REGULATORY_CONSTRAINTS]

## OUTPUT SCHEMA
Generate a JSON object with the following structure:
{
  "specification_metadata": {
    "spec_name": "string",
    "version": "string",
    "created_date": "string",
    "target_stage": "string",
    "review_cadence": "string"
  },
  "performance_gates": [
    {
      "gate_id": "string",
      "gate_name": "string",
      "metric_definition": {
        "metric_name": "string",
        "description": "string",
        "calculation": "string",
        "data_source": "string"
      },
      "thresholds": {
        "promotion_threshold": "string",
        "demotion_threshold": "string",
        "warning_threshold": "string"
      },
      "measurement_window": {
        "duration": "string",
        "minimum_observations": "integer",
        "aggregation_method": "string"
      },
      "evidence_requirements": ["string"],
      "hysteresis_rule": "string"
    }
  ],
  "composite_scoring": {
    "formula": "string",
    "weighting_rationale": "string",
    "minimum_gates_required": "integer"
  },
  "edge_cases_and_exceptions": [
    {
      "scenario": "string",
      "handling_rule": "string"
    }
  ],
  "cold_start_policy": "string"
}

## CONSTRAINTS
- Every threshold must be measurable with the available metrics listed in [AVAILABLE_METRICS]. If a required metric is missing, flag it in an `unavailable_metrics` array at the top level.
- Include hysteresis rules to prevent rapid stage oscillation.
- Define a cold-start policy for when insufficient data exists for a measurement window.
- Address edge cases such as low traffic, deployment rollbacks, and data pipeline delays.
- The composite scoring formula must be explicit and auditable.
- Do not invent metrics that cannot be derived from [AVAILABLE_METRICS].
- If [REGULATORY_CONSTRAINTS] apply, ensure evidence requirements satisfy audit trail needs.

## EXAMPLES
- A good threshold: "Action success rate >= 99.5% over a rolling 7-day window with a minimum of 1,000 observations."
- A good hysteresis rule: "Once promoted, the system will not be demoted unless the metric falls below the demotion threshold for 3 consecutive measurement windows."
- A good cold-start policy: "For the first 14 days of operation, the system remains in the current stage regardless of metrics, collecting baseline data only."

Generate the complete Performance Gate Criteria Specification JSON.

After pasting the template, focus your adaptation effort on the placeholders. The [AVAILABLE_METRICS] field is the most critical; the model will base all thresholds on these. If you provide vague metrics like "user satisfaction," the output will be vague. Instead, provide precise, queryable metrics such as human_approval_rate_last_7d, p99_latency_ms, or tool_call_success_rate. The [RISK_TOLERANCE] field should use a clear label like low, moderate, or high, which the model will interpret to calibrate threshold strictness. Always review the generated unavailable_metrics array; if the model flags a metric you believe you have, your placeholder description was likely insufficient. For high-risk action categories, ensure a human reviews the final specification before it is encoded into any production system.

This prompt is not a one-off brainstorming tool; it is a specification generator that feeds directly into automated gating systems. The output must be machine-readable, validated against a strict schema, and stored as an auditable artifact. Wire this prompt into a pipeline where the generated criteria specification is parsed, validated, and then used to configure monitoring dashboards, CI/CD release gates, or autonomous agent policy engines. The prompt's primary risk is producing vague, unmeasurable, or internally inconsistent criteria that look plausible but fail under automation. Therefore, the implementation harness must treat the LLM output as a draft that requires deterministic post-processing before it can be trusted.

Validation and Schema Enforcement: The prompt instructs the model to output JSON conforming to a specific schema. Your application must parse this JSON immediately and validate it against a formal schema definition (e.g., using Pydantic, Zod, or JSON Schema validators). Check for required fields (metric_name, threshold, measurement_window, evidence_requirements), data type correctness (numeric thresholds must be floats/ints, windows must be valid ISO 8601 durations), and logical consistency (a 'minimum' threshold should not exceed a 'maximum' threshold). If validation fails, do not silently fall back to a default. Instead, construct a targeted retry prompt that includes the raw output and the specific validation errors, asking the model to repair only the broken fields. After three failed repair attempts, escalate the raw output and error log to a human reviewer via a ticketing system or review queue.

Logging and Audit Trail: Every invocation must produce an immutable log entry. Capture the full prompt template with populated variables, the raw model output, the validated specification, the model ID and generation parameters, a timestamp, and a unique spec_id. Store this as a versioned artifact in a database or object store. This is critical because performance gates govern whether autonomous systems can take higher-risk actions; when an incident occurs, you will need to trace the exact criteria that permitted or blocked a stage transition. Log any human overrides to the generated criteria with a required justification field, creating a clear chain of accountability.

Human-in-the-Loop Integration: This prompt defines the rules for automation, so it carries high governance weight. The validated specification should not be deployed directly to production gating systems without review. Route the parsed and validated output to a human approval interface that displays the criteria in a readable format, highlights any fields that required retry repair, and provides a diff against the previously approved version. Require explicit approval from an authorized engineering lead before the specification is written to the live configuration store. The approval action should be logged with the reviewer's identity and timestamp, linking back to the spec_id.

Model Selection and Retry Strategy: Use a model with strong instruction-following and structured output capabilities (e.g., GPT-4o, Claude 3.5 Sonnet) for this task. Set temperature to 0 or a very low value (0.1) to maximize determinism in threshold values and schema adherence. Implement exponential backoff with jitter for API rate limits. For retries triggered by validation failures, include the previous attempt's errors in the new prompt context. For retries triggered by content policy refusals (the model refusing to define a gate for a sensitive action), log the refusal, flag the specification as blocked, and escalate immediately to a human with the refusal context.