Autonomy Transition Logging Prompt

This prompt is designed for the exact moment an AI system's autonomy stage changes. It is not for logging routine actions within a stable stage, nor is it a general-purpose audit logger. Its sole job is to produce a structured, immutable record of a stage transition—such as moving from 'supervised' to 'semi-autonomous,' or an emergency reversion from 'full autonomy' to 'human-required.' The ideal user is a governance engineer, compliance officer, or platform developer responsible for maintaining an auditable chain of custody for AI decision-making authority. You need a defined autonomy policy with named stages (e.g., supervised, semi-autonomous, full-autonomy) and a clear trigger event before using this prompt.

Use this prompt when the transition record must be ingested by a downstream system of record, such as a compliance database, SIEM, or audit log. The output is a structured JSON object, not a narrative summary for a human dashboard. It assumes you can provide the trigger reason, supporting evidence, the identity of the approving authority, the affected system scope, and the previous and new autonomy stages. If you lack any of these inputs, the prompt will flag the record as incomplete rather than fabricating missing fields. Do not use this prompt for real-time operational monitoring, performance metric dashboards, or logging individual tool calls within a stage—those are separate concerns that require different output schemas and retention policies.

Before wiring this into a production system, confirm that your autonomy policy is versioned and that the prompt's stage names match your policy exactly. A mismatch between the prompt's expected stages and your actual policy will produce records that fail downstream validation. Also, ensure that the system calling this prompt has access to the full transition context at the moment of the stage change. If the trigger event, evidence, or approving authority are stored in separate services, assemble them before invoking the prompt. For high-risk domains such as healthcare, finance, or safety-critical infrastructure, always require human review of the generated log entry before it is committed to the immutable audit trail.

This prompt template is the core instruction set you will send to a language model to produce a single, valid transition log entry. It is designed to be wired into an application harness where the variables are populated programmatically before inference. The prompt enforces a strict JSON output schema and instructs the model not to produce any conversational text outside the object, making the output safe for direct ingestion into a logging pipeline or audit database.

textCopy
Generate a structured, auditable log entry for an AI system's autonomy stage transition. Use the provided variables to populate the record. The output must be valid JSON conforming to the specified schema. Do not add commentary outside the JSON object.

TRANSITION DETAILS:
- Trigger Reason: [TRIGGER_REASON]
- Previous Stage: [PREVIOUS_STAGE]
- New Stage: [NEW_STAGE]
- Approving Authority: [APPROVING_AUTHORITY]
- Timestamp (ISO 8601): [TIMESTAMP]
- Affected Scope (System/Component IDs): [AFFECTED_SCOPE]
- Evidence Summary: [EVIDENCE_SUMMARY]
- Transition ID: [TRANSITION_ID]

OUTPUT SCHEMA:
{
  "transition_id": "string, from TRANSITION_ID",
  "timestamp": "string, ISO 8601 format, from TIMESTAMP",
  "previous_stage": "string, from PREVIOUS_STAGE",
  "new_stage": "string, from NEW_STAGE",
  "trigger": {
    "reason": "string, from TRIGGER_REASON",
    "evidence_summary": "string, from EVIDENCE_SUMMARY"
  },
  "authority": {
    "approver": "string, from APPROVING_AUTHORITY",
    "mechanism": "automatic | manual | scheduled"
  },
  "scope": {
    "affected_ids": ["array of strings, from AFFECTED_SCOPE"]
  },
  "completeness_checks": {
    "all_required_fields_populated": true,
    "timestamp_is_valid_iso8601": true,
    "transition_is_valid_per_policy": true
  }
}

CONSTRAINTS:
- Output ONLY the JSON object. No markdown fences, no explanatory text.
- The "mechanism" field must be exactly one of: "automatic", "manual", "scheduled".
- If any input variable is missing, use null for that field and set the corresponding completeness check to false.

To adapt this template, replace each bracketed variable with data from your application's state manager or autonomy controller. The [EVIDENCE_SUMMARY] should be a concise, human-readable string generated from the metrics or events that triggered the transition (e.g., 'Error rate of 0.2% sustained for 72 hours, meeting the 0.5% threshold for promotion'). The [AFFECTED_SCOPE] should be a comma-separated list of system or component IDs that will be converted into a JSON array. Before deploying, test the prompt with edge cases such as missing fields, invalid timestamps, and disallowed stage transitions to ensure the completeness checks behave as expected and the model does not hallucinate corrective data.

The Autonomy Transition Logging Prompt is not a standalone chat interaction; it is a structured logging function that should be called programmatically whenever a system's autonomy stage changes. The prompt expects a set of inputs—trigger reason, evidence, approving authority, timestamp, and affected scope—and produces a strictly formatted log entry. The implementation harness must treat this prompt as a deterministic record producer, not a conversational agent. Any failure to produce a valid, complete log entry should halt the autonomy transition or trigger an immediate fallback to a human operator who can manually create the record.

To wire this into an application, wrap the prompt call in a function that first assembles the required inputs from the system's state manager, approval service, and monitoring tools. The function should enforce a strict schema on the model's output using JSON mode or a tool-call definition with a typed transition_log_entry object. After receiving the response, run a validation layer that checks for: presence of all required fields, timestamp in ISO 8601 format, a non-empty evidence array, and a valid transition_type enum value (e.g., promotion, demotion, reversion). If validation fails, implement a single retry with the error details injected into the prompt context. If the retry also fails, the harness must block the autonomy transition and create an incident ticket for manual review. Log every attempt—success or failure—to a dedicated autonomy_transition_attempts table for auditability.

For high-assurance environments, do not rely solely on the model's output. After a valid log entry is generated, the harness should append a digital signature or hash of the entry and write it to an append-only store. The approving authority field should be cross-referenced against the actual approval record from your identity system, not just accepted from the model's output. Finally, emit a transition_logged event to your observability pipeline so that monitoring dashboards and downstream compliance systems can react in near real-time. Avoid treating this prompt as a one-off; it must be part of a closed-loop system where every stage change is recorded, verified, and traceable back to the human or automated gate that authorized it.