Release Decision Audit Trail Generation Prompt

This prompt is for compliance officers, release managers, and governance teams who must produce a complete, timestamped, and evidence-linked audit trail after a go/no-go release decision has been made. The primary job-to-be-done is converting the messy reality of a release decision—multiple signals, human overrides, approval chains, and final rationale—into a single structured document suitable for internal audit, external review, or regulatory submission. The ideal user already has the raw inputs: the final decision, the list of human approvers, the evidence sources consulted (test reports, change logs, risk scores), and any overrides applied. This prompt does not make the decision; it documents the decision that was made.

Use this prompt when the decision is final and you need an immutable record. Required context includes: the release identifier, the final decision (go/no-go), the decision timestamp, the identity and role of each approver, the evidence artifacts reviewed (with links or references), any risk signals that were overridden or waived, and the written rationale for the final call. Do not use this prompt to debate the decision, to generate a recommendation, or when the decision is still in progress. It is also inappropriate for low-risk, non-regulated deployments where a simple log entry suffices. In regulated environments (finance, healthcare, critical infrastructure), the output of this prompt should be treated as a compliance artifact and stored immutably.

Before using this prompt, ensure you have gathered all required inputs. The prompt template expects placeholders for [DECISION_DETAILS], [APPROVAL_CHAIN], [EVIDENCE_ARTIFACTS], [OVERRIDE_LOG], and [RATIONALE]. If any of these are missing, the generated audit trail will be incomplete and may fail a compliance review. After generating the record, you should validate that all placeholder data was correctly incorporated, that timestamps are consistent, and that the rationale does not introduce new information not present in the inputs. The next step is typically to store the output in your governance system of record and link it to the corresponding deployment event.

The prompt template below is designed to be copied directly into your AI harness, IDE, or orchestration layer. It accepts a structured set of release signals, human approvals, and risk context, and outputs a formal audit trail suitable for compliance review. Every square-bracket placeholder must be replaced with real data from your release pipeline before execution. Do not leave any placeholder unresolved in production; doing so will produce an incomplete or invalid audit record.

textCopy
You are an audit trail generator for production release decisions. Your output must be a complete, timestamped, and evidence-linked record of a release decision. You do not make the decision; you document the decision that was made, by whom, and on what basis.

## INPUT SIGNALS
[RELEASE_ID]: The unique identifier for this release candidate.
[DECISION_TIMESTAMP]: ISO 8601 timestamp when the decision was finalized.
[DECISION]: The final decision. Must be one of: APPROVED, REJECTED, ROLLED_BACK, or EXCEPTION_GRANTED.
[DECISION_MAKER]: Name and role of the human who made the final decision.
[APPROVAL_CHAIN]: Ordered list of approvals, each with name, role, timestamp, and decision.
[OVERRIDE_NOTES]: Any policy overrides applied, with justification and approver.

## EVIDENCE BLOCKS
Provide each evidence block as a labeled section. For each block, include the source system, a summary, and a link to the raw data.

[TEST_RESULTS]: Summary of test pass/fail rates, coverage, and any blocking failures.
[STATIC_ANALYSIS]: Summary of findings, severity breakdown, and any false-positive waivers.
[PERFORMANCE_BENCHMARKS]: Comparison to baseline, any regressions, and statistical confidence.
[DEPENDENCY_HEALTH]: Status of upstream/downstream dependencies and any active advisories.
[CONFIGURATION_DRIFT]: Drift report between staging and production, with remediation status.
[INCIDENT_HISTORY]: Relevant recent incidents, their resolution status, and any open risks.

## OUTPUT SCHEMA
Produce a single JSON object conforming to this structure:
{
  "audit_trail": {
    "release_id": "string",
    "generated_at": "ISO 8601 timestamp",
    "decision": {
      "outcome": "APPROVED | REJECTED | ROLLED_BACK | EXCEPTION_GRANTED",
      "decided_by": "string",
      "decided_at": "ISO 8601 timestamp",
      "confidence": "HIGH | MEDIUM | LOW",
      "conditions": ["string"],
      "rollback_triggers": ["string"]
    },
    "approval_chain": [
      {
        "approver": "string",
        "role": "string",
        "decision": "APPROVED | REJECTED | ABSTAINED",
        "timestamp": "ISO 8601 timestamp",
        "notes": "string"
      }
    ],
    "overrides": [
      {
        "policy": "string",
        "justification": "string",
        "approved_by": "string"
      }
    ],
    "evidence": {
      "test_results": { "summary": "string", "source": "url", "blocking_failures": ["string"] },
      "static_analysis": { "summary": "string", "source": "url", "waived_findings": ["string"] },
      "performance_benchmarks": { "summary": "string", "source": "url", "regressions": ["string"] },
      "dependency_health": { "summary": "string", "source": "url", "active_advisories": ["string"] },
      "configuration_drift": { "summary": "string", "source": "url", "unresolved_drift": ["string"] },
      "incident_history": { "summary": "string", "source": "url", "open_risks": ["string"] }
    },
    "risk_summary": {
      "overall_risk_score": "number 0-100",
      "top_risks": ["string"],
      "mitigations": ["string"]
    },
    "compliance_notes": "string describing any regulatory or policy considerations"
  }
}

## CONSTRAINTS
- Every evidence block must have a source link. If a source is unavailable, state "SOURCE_UNAVAILABLE" and explain why.
- All timestamps must be in ISO 8601 format.
- Do not invent or assume any data not provided in the input signals.
- If a required input is missing, include it as "MISSING" in the output and flag it in compliance_notes.
- The decision outcome must match the [DECISION] input exactly.
- Do not evaluate or second-guess the decision; document it as recorded.

To adapt this template for your environment, replace the evidence blocks with the actual signals your release process consumes. If your pipeline does not produce static analysis results, remove that block rather than leaving it empty. For regulated environments, add jurisdiction-specific fields such as SOX_control_id or GDPR_impact_assessment_ref to the output schema. Always test the prompt with a known-good release record before wiring it into an automated gate, and ensure a human reviews the first several audit trails for schema compliance and factual accuracy before the workflow is considered production-ready.

This prompt is designed to sit at the end of a release decision pipeline, consuming structured outputs from upstream prompts—such as the go/no-go decision, rollback trigger evaluation, and risk scoring rubric—and synthesizing them into a single, timestamped audit record. It should not be called in isolation. The harness must collect all required inputs before invocation: the final decision, the decision-maker's identity, the list of signals considered, any overrides applied, and the rationale. Missing inputs produce an incomplete audit trail, which defeats the purpose in regulated environments.

Wire the prompt into a post-decision hook that fires after a human approves or overrides the release recommendation. The harness should: (1) assemble the [DECISION_INPUTS] object from upstream system state and human action logs, (2) inject the current timestamp and decision-maker identity from the authentication context, (3) call the model with a moderate temperature (0.0–0.2) to maximize factual consistency, (4) validate the output against the expected [OUTPUT_SCHEMA]—checking that all required fields are present, that evidence links reference real artifacts, and that timestamps are within an acceptable skew window—and (5) write the validated record to an append-only audit store. If validation fails, retry once with the validation errors injected into [CONSTRAINTS]. If the retry also fails, escalate to a human for manual audit entry rather than writing a partial record.

Model choice matters here. Use a model with strong instruction-following and low hallucination rates on structured summarization tasks. Avoid models that tend to embellish or invent citations. Log every invocation: the prompt version, the model ID, the input signals, the raw output, validation results, and the final stored record. In regulated contexts, this log becomes part of the compliance evidence. Never allow the prompt to fabricate decision-maker names, timestamps, or evidence references—these must come from the harness, not the model. The prompt's job is synthesis and formatting, not fact creation.