Session-Level Instruction Compliance Evidence Prompt

This prompt is for regulated-industry engineers and compliance teams who must assemble audit packets proving that an AI system followed its governing rules during a specific conversation session. The job-to-be-done is not debugging a single bad output, but producing a defensible, evidence-backed compliance report that shows which policy instructions were active, when they were triggered, and whether the model adhered to each constraint. The ideal user is an engineer or auditor who already has access to the full conversation trace, the system prompt, and any policy instruction versions that were deployed at the time of the session. Without this complete context, the prompt cannot produce a reliable compliance report.

Use this prompt when you need to demonstrate to an internal reviewer, external auditor, or regulator that instruction compliance was maintained throughout a session. It is appropriate for post-hoc review of high-stakes interactions, such as financial advice sessions, clinical documentation workflows, or legal intake conversations. The prompt works best when the instruction hierarchy is well-defined—meaning you have clear separation between system instructions, developer directives, user messages, tool outputs, and policy constraints—and when you can provide the exact text of each instruction layer. If your instruction architecture is ad-hoc or undocumented, this prompt will surface that gap rather than paper over it.

Do not use this prompt for real-time intervention or live guardrail enforcement. It is designed for offline audit analysis, not for blocking actions mid-session. It is also not a substitute for a proper instruction regression test suite; use the Instruction Regression Test Audit Prompt for pre-release validation. If you need to debug why a single decision went wrong, the Decision Provenance Extraction Prompt is a more targeted tool. This prompt assumes you are auditing an entire session for compliance completeness, which requires a higher evidence standard and more structured output. Always route the final report through human review before submitting it as regulatory evidence, and ensure that the conversation trace and instruction versions are archived alongside the report for independent verification.

This template is the core engine for producing an audit packet from a full conversation session. It instructs the model to act as a compliance auditor, systematically comparing every model action and user interaction against a provided set of policy instructions. The output is a structured report that proves which rules were active, when they were triggered, and whether the model adhered to each constraint, complete with evidence citations from the transcript. Use this template as the starting point for your own compliance scanning workflow, adapting the placeholders to match your specific regulatory requirements and data formats.

markdownCopy
You are a compliance audit engine. Your task is to analyze the provided [CONVERSATION_TRANSCRIPT] and produce a structured compliance evidence report based on the active [POLICY_INSTRUCTIONS].

For each policy instruction in [POLICY_INSTRUCTIONS], perform the following analysis:
1. Determine if the policy was relevant to any turn in the conversation.
2. If relevant, identify every turn where the policy should have been triggered.
3. For each triggered turn, cite the exact text from [CONVERSATION_TRANSCRIPT] that serves as evidence of compliance or violation.
4. Assign a compliance status: `compliant`, `violation`, `not_applicable`, or `indeterminate`.
5. If `indeterminate`, explain what information is missing to make a determination.

[CONVERSATION_TRANSCRIPT]:
```json
[TRANSCRIPT_JSON]

[POLICY_INSTRUCTIONS]:

jsonCopy
[POLICY_JSON]

Generate your report strictly according to the following [OUTPUT_SCHEMA]:

jsonCopy
[OUTPUT_SCHEMA_JSON]

[CONSTRAINTS]:

• Do not infer intent beyond the explicit text of the transcript and policies.
• If a policy conflict is detected, flag it with a conflict status and explain the conflicting rules.
• For any violation, include a severity rating of critical, major, or minor based on the policy's defined risk level.
• The report must be self-contained and suitable for external audit review without access to the original system.

To adapt this template, replace the square-bracket placeholders with your concrete data and schemas. [TRANSCRIPT_JSON] should contain the full multi-turn conversation, including user messages, model responses, tool calls, and tool outputs, each with a timestamp and turn ID. [POLICY_JSON] must be a structured list of your governing rules, each with a unique ID, description, risk level, and the exact instruction text. The [OUTPUT_SCHEMA_JSON] is critical for downstream automation; define a strict JSON schema that includes arrays for policy results, evidence citations, and a summary of findings. For high-stakes regulatory use, always route violation and indeterminate findings to a human reviewer before finalizing the audit packet. Do not treat this prompt's output as a final legal record without independent verification.

The Session-Level Instruction Compliance Evidence Prompt is not a standalone chat prompt—it is a batch audit tool designed to run as part of a scheduled or event-driven pipeline. In production, you will typically invoke this prompt after a conversation session closes, a user flags an interaction, or a compliance review window triggers. The prompt expects a complete conversation transcript, an instruction version manifest, and a policy rule set as inputs. Because the output is a structured compliance report with evidence citations, the implementation harness must validate that every claimed violation or adherence event is backed by a turn-level citation before the report enters any permanent audit log.

Wire this prompt into an application by building a wrapper function that assembles the three required inputs: [CONVERSATION_TRANSCRIPT] (the full multi-turn session), [INSTRUCTION_MANIFEST] (a JSON object mapping instruction layer IDs to their versioned text and priority), and [POLICY_RULE_SET] (the specific compliance rules to check). After calling the model, run a post-processing validator that checks three things: (1) every evidence_citation field contains a valid turn index within the transcript bounds, (2) every rule_triggered field maps to a rule ID present in the input policy set, and (3) the adherence_status enum is one of the expected values (COMPLIANT, NON_COMPLIANT, INSUFFICIENT_EVIDENCE, NOT_APPLICABLE). If validation fails, retry once with the validation errors appended as a [CONSTRAINTS] block. If the retry also fails, route the session to a human review queue with the partial report and validation errors attached. Log every invocation—including model, prompt version, input hashes, and validation results—to an append-only audit table.

For high-stakes regulated workflows, never treat the model's output as a final compliance determination. The prompt produces evidence for human reviewers, not a pass/fail verdict. After validation passes, store the structured report alongside the session transcript and instruction manifest in a tamper-evident audit store. Implement a review UI that highlights each rule, its adherence status, and the cited turn so that compliance officers can spot-check findings. Avoid running this prompt on streaming or real-time conversations; it is designed for post-session batch analysis where latency is acceptable and completeness matters more than speed. If you need real-time policy enforcement, pair this audit prompt with a separate inline guardrail system that blocks disallowed actions at inference time, and use the session-level prompt only for retrospective evidence collection.