ADR Compliance Mapping Prompt

Architects in regulated environments must prove that every architectural decision accounts for applicable compliance obligations. This prompt takes an ADR and a set of regulatory controls, standards, or internal policies and produces a traceability matrix that maps each ADR section to specific requirements. It also detects gaps where the ADR fails to address a mandatory control. Use this prompt before an ADR is approved, during audit preparation, or when a new regulation takes effect and existing decisions must be re-evaluated.

This is not a general-purpose compliance tool. It assumes the ADR text and the control catalog are already written and available as input. It does not interpret regulations, provide legal advice, or replace a qualified compliance officer. Human review is required for all gap findings before they become action items. The prompt works best when the control catalog is structured with clear identifiers and requirement text, and when the ADR contains explicit sections for context, decision, and consequences. If your ADR is a single paragraph of prose or your controls are vague policy statements, the mapping quality will degrade significantly.

Do not use this prompt to generate compliance evidence from scratch, to certify a system as compliant, or to interpret new regulations that have not been translated into discrete controls. The output is a traceability artifact that supports human review and audit workflows—it is not a substitute for a compliance officer's judgment. Before running this prompt in production, validate the output against a golden set of manually mapped ADRs to calibrate your acceptance criteria for gap detection precision and recall.

This prompt template is designed to produce a traceability matrix that links each section of an Architecture Decision Record to specific regulatory controls, standards, or policy requirements. It also flags gaps where compliance obligations are unmet. The template uses square-bracket placeholders that you replace with your actual ADR content, compliance framework, and output constraints before sending it to the model. The prompt is structured to enforce evidence grounding, require explicit control references, and produce a machine-readable output schema suitable for downstream compliance tooling.

textCopy
You are a compliance architect reviewing an Architecture Decision Record (ADR) against a regulatory framework. Your task is to produce a traceability matrix that maps each ADR section to applicable compliance controls and identifies gaps where obligations are unmet.

## INPUTS

### ADR Content
[ADR_CONTENT]

### Compliance Framework
[COMPLIANCE_FRAMEWORK]

### Additional Context
[CONTEXT]

## OUTPUT SCHEMA

Return a valid JSON object with this structure:

{
  "adr_identifier": "string",
  "framework": "string",
  "mapping": [
    {
      "adr_section": "string",
      "adr_claim": "string",
      "applicable_controls": [
        {
          "control_id": "string",
          "control_text": "string",
          "mapping_rationale": "string",
          "compliance_status": "mapped | partial | gap",
          "evidence_in_adr": "string or null",
          "gap_description": "string or null",
          "remediation_guidance": "string or null"
        }
      ]
    }
  ],
  "unmapped_controls": [
    {
      "control_id": "string",
      "control_text": "string",
      "reason_not_addressed": "string",
      "risk_level": "high | medium | low",
      "recommended_action": "string"
    }
  ],
  "summary": {
    "total_controls_mapped": "number",
    "total_controls_partial": "number",
    "total_gaps": "number",
    "overall_risk_assessment": "string"
  }
}

## CONSTRAINTS

- Only reference controls that actually exist in [COMPLIANCE_FRAMEWORK]. Do not invent control IDs.
- For each mapping, cite the specific text or claim from the ADR that addresses the control. If no text addresses it, set compliance_status to "gap" and evidence_in_adr to null.
- Do not assume compliance intent. If the ADR does not explicitly address a control, flag it as a gap.
- If a control is partially addressed, explain what is missing in gap_description.
- For unmapped_controls, list every control in [COMPLIANCE_FRAMEWORK] that has no corresponding ADR section. Do not skip controls.
- Use the exact control_id format from [COMPLIANCE_FRAMEWORK].
- If [RISK_LEVEL] is provided, use it to calibrate gap severity. Otherwise, assess risk based on control criticality.

## EXAMPLES

[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this prompt, replace each square-bracket placeholder with your actual data. [ADR_CONTENT] should contain the full text of the ADR you are reviewing. [COMPLIANCE_FRAMEWORK] should list the specific controls, standards, or policy requirements you need to map against—ideally with control IDs and full text. [CONTEXT] can include organizational policies, risk appetite statements, or domain-specific regulatory interpretations. [EXAMPLES] is optional but strongly recommended: provide one or two correct mapping examples to calibrate the model's judgment on what constitutes adequate evidence. [RISK_LEVEL] accepts values like high, medium, or low to calibrate gap severity assessment. After generating the output, validate the JSON schema before ingesting it into your compliance tracking system. For regulated environments, always route the output through human review before treating any gap as confirmed or closed.

This prompt is designed to be integrated into a document processing pipeline, not used as a one-off chat interaction. The typical harness ingests a draft ADR (often from a version-controlled repository), a compliance standard document, and a jurisdiction or risk profile tag, then produces a structured traceability matrix. Because the output is used for audit evidence, the harness must enforce schema validation, log every run, and route low-confidence or incomplete mappings to a human reviewer before the matrix is accepted.

Start by constructing the prompt with the required placeholders: [ADR_TEXT] should be the full markdown or plain text of the architecture decision record; [COMPLIANCE_STANDARD] should contain the relevant regulatory text, control catalog, or policy document (e.g., SOC 2 criteria, HIPAA Security Rule sections, or an internal InfoSec policy); [JURISDICTION] is a short tag like 'US-HIPAA', 'EU-GDPR', or 'PCI-DSS-4.0' that helps the model scope its mapping behavior. The [OUTPUT_SCHEMA] placeholder should be populated with a strict JSON schema defining the expected traceability matrix structure—each row must include the ADR section identifier, the mapped control ID, a confidence score, a rationale snippet, and a gap flag. Validate the model's output against this schema immediately. If validation fails, retry once with the validation error injected into the [CONSTRAINTS] field. If the second attempt also fails, escalate to a human review queue with the raw output and error log attached.

Model choice matters here. Use a model with strong instruction-following and long-context handling, such as claude-sonnet-4-20250514 or gpt-4o, because ADRs and compliance standards can each exceed several thousand tokens. Set temperature to 0 or a very low value (0.1) to maximize deterministic mapping behavior. For regulated environments where data must not leave a private boundary, deploy the prompt against a self-hosted model or a private cloud inference endpoint. Log every request and response, including the prompt version hash, model ID, timestamp, and validation result, to an append-only audit store. This log becomes part of the compliance evidence chain.

The most common production failure mode is a gap detection false negative—the model maps an ADR section to a control but misses a sub-requirement that is not explicitly stated in the standard text. Mitigate this by maintaining a curated list of known 'hidden requirements' for each standard and injecting them into the [CONTEXT] placeholder as supplementary guidance. A secondary failure mode is over-mapping, where the model forces a relationship between an ADR section and a control that doesn't genuinely apply. To catch this, implement a confidence threshold (e.g., 0.7) below which mappings are automatically flagged for human review. The human reviewer should be able to accept, reject, or amend each mapping row through a simple UI that writes the final approved matrix back to the ADR repository as an artifact.

Do not treat this prompt as a replacement for a qualified compliance officer or legal review. The harness should enforce that every generated matrix includes a mandatory human attestation step before it can be merged into the official ADR record. Wire the approval gate into your CI/CD pipeline if ADRs are stored in a version control system: the PR that adds the compliance mapping artifact should be blocked until an authorized reviewer approves it. This keeps the workflow auditable and prevents unverified AI output from becoming part of the compliance record.