Long-form
AuraScore 83/100

Architectural Decision Record Publication Audit Checklist

Comprehensive audit checklist to validate depth, trade-offs, and compliance in long-form architectural decision records.

Use this template when preparing or reviewing complex technical RFCs or architectural decision records (ADRs) prior to engineering board sign-off. It establishes a rigorous rubric covering context, alternatives, trade-offs, and failure domains.

Template

Role: Principal Systems Architect & Technical Documentation Lead with twenty years of experience designing fault-tolerant enterprise platforms.

Context

  • Target Platform Architecture: {{system_name}}
  • Primary Technical Readership: {{target_audience}}
  • Known Technical Disputes: {{consensus_blockers}}
  • Regulatory & Governance Baseline: {{compliance_standards}}
  • System Lifecycle Stage: {{lifecycle_stage}}
  • Review Committee: {{review_board}}

Task

Generate an exhaustive, multi-tier audit checklist that evaluates a long-form Architectural Decision Record (ADR) for technical thoroughness, trade-off clarity, failure-mode analysis, and governance alignment before formal submission to {{review_board}}.

Method

  1. Analyze {{system_name}} and its operational context within the {{lifecycle_stage}} lifecycle phase.
  2. Formulate audit criteria for the problem statement, ensuring business drivers and technical triggers are quantified.
  3. Establish verification items for alternative architecture evaluations, requiring explicit positive and negative trade-off scoring.
  4. Design checklist items assessing whether {{consensus_blockers}} are transparently addressed with empirical benchmarks or architectural proofs.
  5. Draft validation criteria for non-functional requirements including latency budgets, scaling ceilings, data consistency, and observability.
  6. Incorporate compliance checks specifically addressing {{compliance_standards}} obligations.
  7. Detail rollout, fallback, and schema evolution verification gates tailored to {{target_audience}}.

Constraints

  • Every checklist item MUST include an acceptance threshold and a validation test question.
  • You MUST NOT approve subjective assertions; every technical claim must require empirical or design-level evidence.
  • The checklist must strictly maintain an audit rubric format with binary pass/fail and mitigation notes.
  • Tone must remain objective, critical, and engineering-rigorous.

Output format

  1. Executive Summary Table (Metadata, Scope, Review Thresholds)
  2. Section 1: Problem Space & Context Checklist (4-6 items)
  3. Section 2: Alternative Solutions & Trade-off Matrix Checklist (4-6 items)
  4. Section 3: Non-Functional Requirements & Resilience Checklist (5-7 items)
  5. Section 4: Migration, Rollback & Operational Readiness Checklist (4-6 items)
  6. Section 5: Compliance ({{compliance_standards}}) & Governance Sign-off Checklist (3-5 items)

Self-review

  • Ensure all 6 context variables are directly embedded in the evaluation criteria.
  • Verify that every section contains actionable, unambiguous verification criteria rather than high-level advice.
  • Confirm the total checklist contains between 20 and 30 distinct audit points.
AuraScore breakdown
83/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness5/5 · Strong

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

writing-content
writing-long-form
software-engineering-debugging
architecture
adr
system-design