Data Residency Gate Check Prompt

This prompt acts as an automated compliance gate for cloud infrastructure and platform engineers who need to validate that a proposed data storage or processing location satisfies residency requirements before any infrastructure-as-code change is applied. The primary job-to-be-done is preventing a deployment to a non-compliant region from ever reaching production by inserting a structured, reviewable decision between the engineering proposal and the execution pipeline. The ideal user is a platform engineer or compliance reviewer who has access to the organization's data residency policy, the target jurisdiction list, and the specific technical proposal—such as a Terraform plan, a cloud region selection, or a database provisioning request.

Use this prompt when you have a concrete, single-scope proposal: one dataset, one processing purpose, one target region or set of regions, and a defined residency policy document. The prompt is designed for pre-execution gating, not post-hoc audit. It works best when the residency policy is provided as grounded context in the prompt itself, rather than relying on the model's parametric knowledge of regulations, which may be outdated or incomplete. Do not use this prompt for multi-jurisdiction legal analysis, for interpreting novel or ambiguous regulatory guidance, or for making final legal determinations. The output is a compliance decision with supporting reasoning, not legal advice.

The prompt requires several specific inputs to function reliably: the proposed data categories, the processing purpose, the target jurisdiction(s), and the full text of the applicable residency policy or policy excerpt. Without all four inputs, the gate check will produce unreliable results. The prompt also expects a defined risk level—such as 'low,' 'medium,' or 'high'—which controls the strictness of the evaluation and whether borderline cases are blocked or flagged for human review. For high-risk data categories like health records, financial data, or government-classified material, always route the output to a human compliance reviewer regardless of the model's pass/fail determination. The prompt is a decision-support tool, not a replacement for accountable human judgment in regulated environments.

This template is the core of the Data Residency Gate Check. It accepts a proposed data action, the target jurisdiction(s), and the relevant policy or regulatory text, then returns a structured decision with jurisdiction mapping, transfer mechanism checks, and blocking conditions. The prompt is designed to be wired into a CI/CD pipeline, a cloud provisioning workflow, or an internal compliance review queue. Every placeholder is a square-bracket token that your application must resolve before sending the request to the model.

textCopy
You are a data residency compliance gate. Your job is to evaluate whether a proposed data storage or processing location complies with the provided residency requirements. You must ground every determination in the supplied policy text. Do not invent regulations, jurisdictions, or transfer mechanisms.

## INPUT
Proposed Action: [DATA_ACTION_DESCRIPTION]
Data Categories: [DATA_CATEGORIES]
Source Jurisdiction: [SOURCE_JURISDICTION]
Target Jurisdiction(s): [TARGET_JURISDICTIONS]
Transfer Mechanism(s) Claimed: [TRANSFER_MECHANISMS]

## POLICY CONTEXT
[RESIDENCY_POLICY_TEXT]

## OUTPUT SCHEMA
Return a single JSON object with exactly these fields:
{
  "decision": "ALLOWED" | "BLOCKED" | "NEEDS_REVIEW",
  "jurisdiction_assessment": {
    "source": "string",
    "targets": [
      {
        "jurisdiction": "string",
        "residency_requirement": "string",
        "compliance_status": "COMPLIANT" | "NON_COMPLIANT" | "UNCERTAIN",
        "policy_reference": "string"
      }
    ]
  },
  "transfer_mechanism_check": {
    "mechanism_claimed": "string",
    "valid": true | false,
    "policy_reference": "string",
    "gap_description": "string or null"
  },
  "blocking_conditions": ["string"],
  "required_approvals": ["string"],
  "reasoning_summary": "string"
}

## CONSTRAINTS
- If any target jurisdiction is non-compliant and no valid transfer mechanism covers it, decision must be BLOCKED.
- If any target jurisdiction status is UNCERTAIN, decision must be NEEDS_REVIEW.
- Every policy_reference must quote or paraphrase a specific clause from POLICY CONTEXT.
- blocking_conditions must list specific, actionable reasons. Never leave it empty for BLOCKED decisions.
- Do not assume adequacy decisions, SCC applicability, or derogations unless explicitly stated in POLICY CONTEXT.
- If the policy text is insufficient to decide, set decision to NEEDS_REVIEW and explain what is missing.

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace each square-bracket placeholder with data from your application context. [DATA_ACTION_DESCRIPTION] should describe the specific operation (e.g., 'Store customer PII in us-east-1'). [RESIDENCY_POLICY_TEXT] must contain the exact policy, contract clause, or regulatory excerpt the model should reason from—never ask the model to recall regulations from training data. [RISK_LEVEL] can be set to LOW, MEDIUM, HIGH, or CRITICAL to influence the strictness of the model's interpretation. For CRITICAL workflows, always route NEEDS_REVIEW decisions to a human compliance officer and log the full prompt and response for audit. Before deploying, run this prompt against a golden dataset of known compliant and non-compliant scenarios to verify that the model does not hallucinate regulations or approve transfers that should be blocked.

The Data Residency Gate Check Prompt is designed to be called synchronously before any infrastructure-as-code apply, data store creation, or cross-region replication configuration. It should be integrated as a policy enforcement point within your deployment pipeline or internal developer platform. The prompt expects structured input describing the proposed data location, data categories, and applicable policy documents. The output is a deterministic JSON decision that downstream systems can parse to either proceed, block, or flag for human review.

To wire this into an application, build a thin service wrapper that accepts a ResidencyCheckRequest object containing the target region, data classifications, and a list of active policy texts. The service should inject these into the prompt's [PROPOSED_LOCATION], [DATA_CATEGORIES], and [POLICY_DOCUMENTS] placeholders. After receiving the model's JSON response, validate it against a strict schema that requires a decision field (exact values: COMPLIANT, NON_COMPLIANT, NEEDS_REVIEW), a jurisdiction string, and a blocking_conditions array. Reject any response that does not parse or contains extra decision values. Log the full prompt, response, and validation result to an immutable audit store for every check. For NEEDS_REVIEW and NON_COMPLIANT decisions, automatically create a ticket in your review queue with the blocking_conditions and evidence fields attached. Never allow a NON_COMPLIANT decision to be overridden by code; it must require a human operator to acknowledge the risk and manually approve an exception in a separate system.

Model choice matters here. Use a model with strong instruction-following and low hallucination rates on structured tasks, such as claude-sonnet-4-20250514 or gpt-4o. Avoid smaller or older models that may invent regulation names or misclassify jurisdictions. Implement a retry layer with a maximum of two attempts. If the first response fails schema validation, append the validation error to the prompt context and retry once. If the second attempt also fails, escalate the entire request to a human reviewer with the raw model output and error context. Do not proceed with deployment on a failed validation. For high-frequency pipelines, cache residency decisions for identical (location, data category, policy hash) tuples with a TTL of one hour to reduce latency and cost, but invalidate the cache immediately if any policy document is updated.

Finally, build an eval harness that runs before you deploy any prompt changes. Your eval set must include: a compliant scenario (e.g., US data in a US region), a clearly non-compliant scenario (e.g., EU personal data in a region with no adequacy decision), an ambiguous scenario requiring review (e.g., data classified as 'internal' in a region with a new data law), and an adversarial scenario where the input tries to trick the model into approving a blocked region. Measure precision and recall on NON_COMPLIANT decisions. A false negative (approving a non-compliant location) is a critical production incident; your eval must have zero tolerance for it. If you observe any hallucinated regulations in the blocking_conditions, add those examples to your eval set and consider adding a retrieval step that grounds the model in your actual policy library before the gate check runs.