Prompt Assembly Playback for Debug Replay Prompt

This prompt is for AI operations engineers and developers who need to reproduce a specific production failure deterministically. The job-to-be-done is converting raw trace metadata—such as a trace ID, timestamp, and assembly version—into a self-contained replay script that reconstructs the exact assembled prompt and model request payload. Without this, debugging is speculative; with it, you can step through the identical input the model received, inspect every section, and isolate the root cause. The ideal user has access to your prompt assembly logs, trace storage, and the original assembly configuration, and needs to answer the question: 'What exactly did the model see when it produced this bad output?'

Use this prompt when you have a specific failure trace and need a byte-for-byte reconstruction of the assembled prompt for offline debugging, regression test creation, or incident postmortem evidence. It is appropriate when the failure mode is unclear from output alone—for example, when a model hallucinates despite correct retrieved context, ignores a system instruction, or calls a tool with malformed arguments. The prompt requires the following inputs: a [TRACE_ID] to locate the assembly event, the [ASSEMBLY_VERSION] or configuration hash to select the correct template logic, and access to the stored [ASSEMBLY_METADATA] containing variable bindings, branch decisions, and source context. The output should be a replay script that includes the fully assembled prompt, tool schemas, and model parameters, plus eval checks that verify the replay matches the original request hash.

Do not use this prompt for general prompt testing, performance benchmarking, or when you only have the model's output text without trace metadata. It is not a substitute for a prompt regression suite—it is a surgical debugging tool for a single known failure. Avoid using it in environments where trace data may contain unmasked PII or secrets; ensure all sensitive data is redacted before the replay script is generated or shared. If the trace storage is incomplete or the assembly logic has changed since the failure, the replay may be approximate rather than exact, and the prompt should flag this uncertainty. The next step after generating the replay is to run it in a controlled environment, compare the output against the original failure, and use the diff to identify the contributing factor—whether it was a context ordering issue, an instruction conflict, or a model behavior quirk.

This template generates a self-contained replay script from trace metadata. It takes the raw ingredients of a production request—the resolved prompt sections, tool schemas, model parameters, and assembly version—and produces a runnable script that reconstructs the exact payload the model received. The output is not a summary or a diff; it is a faithful reproduction suitable for local debugging, regression testing, or incident postmortems.

textCopy
You are a prompt assembly playback engine. Your task is to reconstruct the exact assembled prompt and model request that was sent to the model during a specific production request.

## INPUTS
- Trace Metadata: [TRACE_METADATA]
- Assembled Prompt Sections: [ASSEMBLED_SECTIONS]
- Tool Schemas (if any): [TOOL_SCHEMAS]
- Model Configuration: [MODEL_CONFIG]
- Assembly Version: [ASSEMBLY_VERSION]
- Request Timestamp: [REQUEST_TIMESTAMP]

## OUTPUT SCHEMA
Produce a JSON object with the following structure:
{
  "replay_metadata": {
    "trace_id": "string",
    "assembly_version": "string",
    "original_timestamp": "ISO8601",
    "replay_generated_at": "ISO8601",
    "model": "string",
    "model_parameters": {}
  },
  "assembled_prompt": {
    "sections": [
      {
        "section_id": "string",
        "section_type": "system_message | user_message | tool_definition | few_shot_example | retrieved_context | output_schema | conversation_turn",
        "content": "string",
        "token_count": "integer",
        "source": "string"
      }
    ],
    "total_tokens": "integer",
    "assembly_hash": "string"
  },
  "tool_definitions": [
    {
      "tool_name": "string",
      "schema": {},
      "injection_source": "string"
    }
  ],
  "replay_script": {
    "language": "python",
    "code": "string containing a runnable script that reconstructs the exact model request",
    "dependencies": ["string"],
    "execution_notes": "string"
  },
  "fidelity_checks": {
    "section_count_match": "boolean",
    "token_count_match": "boolean",
    "tool_schema_match": "boolean",
    "hash_match": "boolean",
    "warnings": ["string"]
  }
}

## CONSTRAINTS
- Reconstruct the prompt sections in the exact order they were assembled, not in logical or alphabetical order.
- Preserve all whitespace, newlines, and formatting exactly as they appeared in the original assembled prompt.
- Include every tool definition that was injected, even if the model did not call that tool.
- The replay script must be self-contained and runnable with only the dependencies listed.
- If any section contains redacted or missing data, mark it with [REDACTED] and include a warning in fidelity_checks.
- Do not summarize, paraphrase, or optimize the prompt content. Faithful reproduction is the only goal.
- If the trace metadata is incomplete, produce a best-effort reconstruction and list all gaps in fidelity_checks.warnings.

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace each square-bracket placeholder with the actual data from your trace system. [TRACE_METADATA] should contain the trace ID, session identifiers, and any routing tags. [ASSEMBLED_SECTIONS] is the fully resolved prompt content, section by section, as logged by your assembly pipeline. [TOOL_SCHEMAS] must include the exact schema definitions injected, not just the tool names. [MODEL_CONFIG] should capture temperature, max_tokens, stop sequences, and any other parameters that affect output. [EXAMPLES] should include one or two representative replay outputs to anchor the model's behavior. [RISK_LEVEL] controls the strictness of fidelity checks—set to high for incident investigations where any deviation must be flagged, or standard for routine debugging where minor formatting differences are acceptable.

Before relying on the replay output, validate the fidelity_checks block. A hash_match: false or token_count_match: false indicates the reconstruction diverged from the original request. In high-risk debugging scenarios, require human review of any replay where fidelity_checks.warnings is non-empty. Wire this prompt into your incident response runbook so that when a production failure is escalated, the first automated step is generating a replay script from the trace. Store the replay output alongside the incident record for auditors and future regression tests.

The Prompt Assembly Playback for Debug Replay Prompt is designed to be invoked as part of an incident response or failure analysis pipeline, not as a standalone chat interaction. When a production failure is detected—such as a hallucination, a tool-call error, or an unexpected refusal—the system should retrieve the stored trace metadata for that request and feed it into this prompt. The output is a self-contained replay script that can be executed deterministically against the same model configuration to reproduce the exact assembled prompt and model request. This harness must be integrated with your observability backend so that trace IDs, assembly versions, and raw payloads are available at debug time.

To wire this into an application, build a debug service that accepts a trace ID and a failure report as input. The service fetches the corresponding assembly trace from your logging store—including the final assembled prompt, tool schemas, variable bindings, and model configuration—and passes them into the prompt template as [TRACE_METADATA] and [FAILURE_DESCRIPTION]. The generated replay script should be written to a version-controlled debug artifacts store with a unique replay ID. Before executing the replay, run the provided eval checks for replay fidelity: verify that the replayed assembled prompt matches the original byte-for-byte (or token-for-token, depending on your tolerance), that all variable substitutions resolve identically, and that the model request payload is structurally equivalent. If the replay fails these checks, flag it for manual review rather than trusting the reproduction.

Model choice matters here. Use a model with strong instruction-following and code-generation capabilities, such as Claude 3.5 Sonnet or GPT-4o, because the output is an executable script that must be syntactically correct and runnable without manual edits. Set temperature to 0 for deterministic script generation. Implement a retry loop with a maximum of 2 attempts if the output fails schema validation or produces a non-executable script. Log every replay attempt with its replay ID, the original trace ID, the generated script hash, and the pass/fail status of the fidelity evals. For high-severity incidents where the replay will be used in postmortems or compliance reviews, require human approval of the generated script before execution. Never execute a replay script in a production environment; always isolate replay execution to a sandboxed debugging environment that mirrors the production model configuration but cannot affect live traffic.