Instruction Audit Trail Prompt for Governance Workflows

This prompt is for governance, risk, and compliance (GRC) engineers, AI safety teams, and platform architects who must produce a verifiable link between a specific model output and the exact set of instructions that governed it. The job-to-be-done is not to generate a correct answer, but to generate a traceable audit record that captures which instruction layers were active, their version identifiers, their declared priority, and how any conflicts between them were resolved for a given decision. Use this when you are building AI features for regulated industries, internal policy enforcement, or any product surface where an auditor, a customer, or a regulator will later ask, 'What rule made it say that?'

This prompt is designed to be wired into a post-generation step, not a real-time chat flow. It requires a structured input payload containing the original user query, the final model output, and a serialized representation of the active instruction hierarchy (system prompt, developer messages, policy layers, tool contracts). The output is a machine-readable audit log, not a user-facing explanation. You should only use this prompt when you have a formal instruction versioning system in place; if your system prompt is a raw string in a config file with no version hash, this prompt will produce a low-value record. Do not use this for debugging why a model hallucinated a fact—use it for proving which policy instruction was enforced when a model refused a disallowed action or cited a specific regulatory clause.

Before implementing, ensure your application layer can capture the required metadata: a unique instruction_set_id, a version hash for each instruction layer, and a timestamp of when the instruction set was loaded. If you cannot provide these inputs, the audit trail will be incomplete and may fail a real governance review. The next step is to integrate this prompt into a post-processing pipeline that stores the resulting audit record alongside the conversation log, indexed by decision_id, so it can be retrieved during a compliance check without re-running the prompt.

This template is the core of the Instruction Audit Trail workflow. It instructs the model to act as a governance auditor, analyzing a given input and output pair against a set of declared instruction layers. The model's job is not to re-perform the task, but to produce a structured, traceable record explaining why a particular output was generated, citing the governing rules. This is essential for compliance, debugging, and trust in regulated or high-stakes applications. The template uses square-bracket placeholders for all dynamic inputs, making it ready to be wired into a production harness.

textCopy
You are a Governance Audit Agent. Your sole task is to produce a traceability audit record for a given AI interaction. You will receive the active instruction layers, their versions, the user input, and the final model output. You must analyze the output and determine which instruction layers governed the response.

## INPUTS
- **INSTRUCTION_LAYERS**: [INSTRUCTION_LAYERS]
- **USER_INPUT**: [USER_INPUT]
- **MODEL_OUTPUT**: [MODEL_OUTPUT]

## INSTRUCTION_LAYERS SCHEMA
The `[INSTRUCTION_LAYERS]` input is a JSON array of objects, each with the following fields:
- `layer_id`: (string) Unique identifier for the instruction layer.
- `layer_type`: (string) One of `system`, `developer`, `user`, `tool`, `policy`.
- `priority`: (integer) Precedence rank where 1 is the highest priority.
- `version`: (string) Semantic version of the instruction.
- `content`: (string) The full text of the instruction.

## TASK
1.  **Analyze**: Review the `[MODEL_OUTPUT]` against the `[INSTRUCTION_LAYERS]` and `[USER_INPUT]`.
2.  **Identify Governing Rules**: Determine which specific instruction layers directly influenced the `[MODEL_OUTPUT]`. Cite the `layer_id` and `version`.
3.  **Detect Conflicts**: If multiple instructions applied and were in conflict, identify the conflict and explain which instruction took precedence based on the `priority` field.
4.  **Generate Audit Record**: Produce a JSON object strictly conforming to the `[OUTPUT_SCHEMA]`.

## CONSTRAINTS
- Do not generate any text outside the JSON object.
- If no specific instruction governed a part of the output, set `governing_layer` to `null` and `confidence` to `low`.
- If the `[MODEL_OUTPUT]` violates a higher-priority instruction, you must flag this as a `violation` in the `conflict_resolution` field.
- Base your analysis strictly on the provided `[INSTRUCTION_LAYERS]` and `[MODEL_OUTPUT]`. Do not infer intent.

## OUTPUT_SCHEMA
```json
{
  "audit_record": {
    "interaction_id": "string",
    "timestamp": "string (ISO 8601)",
    "findings": [
      {
        "output_segment": "string (a concise, quotable part of the MODEL_OUTPUT)",
        "governing_layer_id": "string | null",
        "governing_layer_version": "string | null",
        "confidence": "high | medium | low",
        "rationale": "string (brief explanation of why this layer applies)",
        "conflict_resolution": {
          "conflict_detected": "boolean",
          "conflicting_layer_ids": ["string"],
          "winning_layer_id": "string | null",
          "resolution_rule": "string (e.g., 'priority_override', 'no_conflict')",
          "violation_flag": "boolean"
        }
      }
    ],
    "overall_assessment": "string (summary of governance adherence)"
  }
}

To adapt this template, start by replacing the [INSTRUCTION_LAYERS] placeholder with a serialized JSON array of your actual system, policy, and developer prompts. The [USER_INPUT] and [MODEL_OUTPUT] should be populated from your application logs. For high-risk governance workflows, the [OUTPUT_SCHEMA] is your contract; validate the model's JSON output against this schema before accepting it. A common failure mode is the model summarizing the output instead of quoting a specific output_segment. To mitigate this, you can add a [FEW_SHOT_EXAMPLES] placeholder with one correct and one incorrect example to guide the model's behavior. The next step is to embed this prompt in an implementation harness that can feed it log data and validate its structured output.

The Instruction Audit Trail prompt is not a standalone artifact; it is a component inside a larger governance workflow. The application layer must supply the prompt with the exact instruction set that was active at the time of the decision, including version identifiers, priority declarations, and any conflict resolution metadata. This means the harness must capture a snapshot of the system prompt, developer directives, policy layers, and tool outputs before calling the model. Relying on the model to recall its own instructions from conversation history is insufficient for an audit trail—the prompt must explicitly receive the governing rules as structured input.

Wire the prompt into a pipeline that executes after a model decision is made but before the output is surfaced to the user or logged as final. The application should construct the [ACTIVE_INSTRUCTIONS] block by pulling the canonical instruction versions from a configuration store or prompt registry, not from the model's context window. Include [DECISION_OUTPUT] as the raw model response, [CONFLICT_LOG] as any recorded instruction conflicts and their resolutions, and [SESSION_METADATA] with timestamps, user identifiers, and interaction IDs. After the audit prompt returns, validate the output against a strict JSON schema that requires fields like governing_instruction_id, priority_level, conflict_resolution_applied, and traceability_gap. If validation fails, retry once with a more explicit schema reminder; if it fails again, flag the record for human review and do not auto-approve the audit entry.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o or Claude 3.5 Sonnet, and set the temperature low (0.0–0.2) to reduce variance in audit record generation. Log every audit prompt request and response pair immutably, including validation failures and retry attempts. For regulated environments, the audit record produced by this prompt should be treated as a draft until a human reviewer confirms that the governing instruction mapping is correct. Never expose the raw audit prompt or its output to end users; this is an internal control surface. The next step after implementation is to build a regression test suite that replays known decision scenarios and verifies that the audit trail correctly identifies the governing instruction, flags gaps, and never fabricates an instruction version that wasn't supplied in the input.