Structured Output PII Field Validation Prompt Template

This prompt is designed for integration engineers and backend developers who need a post-generation safety net before structured model outputs—such as JSON, XML, or CSV payloads—are written to a database, logged, or returned to a client. Its primary job is to scan a fully-formed structured payload field-by-field, detect any Personally Identifiable Information (PII) the model may have inadvertently included, flag those fields, and produce a sanitized version alongside a machine-readable audit log of every change. The ideal user is someone operating a production pipeline where structured output is the contract, and a single PII leak into logs or storage is a compliance incident.

You should reach for this prompt when you have a known output schema and need field-level inspection, not just a full-text regex sweep. It is particularly valuable when the model generates records from retrieved context, user-provided data, or multi-turn conversations where PII can propagate unexpectedly. The prompt requires a strict [OUTPUT_SCHEMA] defining field names and expected types, the raw [MODEL_OUTPUT] to scan, and a set of [PII_RULES] that specify which categories to detect (e.g., emails, phone numbers, physical addresses, government IDs). You must also provide [REDACTION_STRATEGY] instructions—such as replace_with_placeholder, nullify_field, or hash_value—to control how each category is handled.

Do not use this prompt as your sole PII defense when the model output is free-text narrative, streaming token-by-token, or when you need real-time blocking rather than post-hoc repair. It is also not a replacement for input-side PII filtering or retrieval-augmented generation (RAG) source sanitization. If your pipeline already has strict schema validation that rejects extra fields, combine this prompt with a schema-mismatch repair step to handle redacted fields that may become null or change type. For high-risk regulated domains such as healthcare (HIPAA) or payments (PCI DSS), always route flagged outputs to a human review queue before automated redaction is applied, and log the full audit trail for compliance evidence.

This prompt template is designed to be wired into a post-generation validation pipeline. It receives a structured payload that has already passed basic schema validation but may contain sensitive data inadvertently included by the model. The template instructs the model to scan each field against configurable PII detection rules, produce a sanitized version of the payload, and generate an audit log of every change made. Use it when you need a safety net between model output and database insertion, log storage, or user-facing surfaces.

textCopy
You are a PII detection and redaction specialist operating on structured data payloads.

Your task is to scan the provided [INPUT_PAYLOAD] field-by-field for personally identifiable information (PII), credentials, and sensitive data. You must produce a sanitized version of the payload and a complete audit log of all changes.

## Detection Rules
Apply the following detection categories with the specified redaction strategy for each:

[DETECTION_RULES]

## Output Schema
Return a valid JSON object matching this exact structure:

{
  "sanitized_payload": { ... },
  "audit_log": [
    {
      "field_path": "$.user.email",
      "original_value": "jane.doe@example.com",
      "detected_category": "EMAIL_ADDRESS",
      "redaction_strategy": "MASK",
      "redacted_value": "j***@example.com",
      "confidence": 0.97,
      "rule_triggered": "email_regex_v2"
    }
  ],
  "summary": {
    "total_fields_scanned": 42,
    "total_redactions": 3,
    "categories_detected": ["EMAIL_ADDRESS", "PHONE_NUMBER"],
    "high_confidence_count": 2,
    "low_confidence_count": 1
  }
}

## Redaction Strategies
- MASK: Partially obscure the value while preserving format hints (e.g., j***@domain.com)
- REDACT: Replace the entire value with [REDACTED]
- DELETE: Remove the field entirely from the sanitized payload
- TOKENIZE: Replace with a consistent anonymous token (e.g., [USER_123])

## Constraints
[CONSTRAINTS]

## Examples
[EXAMPLES]

## Input Payload
[INPUT_PAYLOAD]

## Instructions
1. Parse the input payload and identify its structure.
2. Scan every field recursively, including nested objects and arrays.
3. For each field, check against all detection rules in [DETECTION_RULES].
4. When a match is found, apply the specified redaction strategy.
5. Record every redaction in the audit_log with the exact JSON path, original value, detected category, strategy used, redacted value, confidence score, and the rule that triggered.
6. If a field value matches multiple categories, record each match separately and apply the most restrictive strategy.
7. Do not redact fields that are explicitly listed in the allowlist within [CONSTRAINTS].
8. Preserve all non-sensitive fields exactly as they appear in the input.
9. If no PII is detected, return the original payload unchanged with an empty audit_log.
10. If the input payload is malformed or unparseable, return an error object: {"error": "UNPARSEABLE_INPUT", "detail": "..."}

To adapt this template for your environment, replace the square-bracket placeholders with concrete values. [DETECTION_RULES] should contain your specific PII categories, regex patterns, and redaction strategies—for example, mapping credit card numbers to REDACT and email addresses to MASK. [CONSTRAINTS] should specify allowlists for fields that legitimately contain PII-like strings (such as test data or public contact information) and any maximum field depth or payload size limits. [EXAMPLES] should include at least one positive case showing correct redaction and one negative case showing a benign string that should not be flagged. [INPUT_PAYLOAD] is the structured output from your model that needs scanning—this will typically be injected programmatically by your validation harness.

Before deploying this prompt, test it against a golden dataset of known PII-positive and PII-negative payloads. Measure both recall (did it catch all PII?) and precision (did it flag only actual PII?). Pay special attention to nested fields, arrays of objects, and edge cases like empty strings, null values, and very long text fields. If your use case involves regulated data such as PHI or PCI, always route low-confidence detections to human review rather than relying on automated redaction alone.

This prompt is designed to sit inside a post-generation validation pipeline, not as a standalone chatbot interaction. After your primary model produces a JSON, XML, or CSV payload, route that payload through this prompt before it reaches a database, log, or user-facing surface. The prompt expects a structured input, a schema definition, and a set of scanning rules. It returns a sanitized version of the payload plus an audit log of every field that was flagged, redacted, or left unchanged. The implementation harness must handle three states: clean pass (no PII found), redacted output (PII found and sanitized), and ambiguous cases (low confidence flags that require human review).

Wire the prompt into your application as a synchronous post-processing step with a strict timeout. Use a structured output API (e.g., OpenAI's response_format with a JSON schema, or equivalent tool-calling mode) to enforce the expected return shape: { sanitized_payload, audit_log: [{ field_path, original_hash, action, confidence, reason }] }. Validate the returned structure before accepting it. If the model fails to return valid JSON matching the expected schema, retry once with a simplified instruction that says 'Return ONLY the JSON object with sanitized_payload and audit_log fields. No markdown, no commentary.' If the second attempt fails, escalate the original payload to a human review queue and log the failure. Do not silently pass unsanitized data downstream.

For high-throughput pipelines, implement field-level caching for repeated values that have already been classified as safe or sensitive. Before calling the model, check each field value against a local cache keyed by a hash of the value plus the field's semantic type. If a cached decision exists with high confidence, apply it directly and skip the model call for that field. This reduces latency and cost for repetitive structured data like templated API responses. For fields that require model evaluation, batch multiple fields into a single prompt call rather than making one call per field. Include a circuit breaker: if the PII detection model call fails more than three times in a 60-second window, stop processing and alert the on-call channel. Never allow a broken validation step to become a silent pass-through.

Log every decision to an immutable audit store that is separate from your application logs. The audit log returned by the prompt should be enriched with a trace ID, the model version used, the timestamp, and the identity of the calling service. This is critical for compliance review and for debugging false positives. If a field is redacted, store only a salted hash of the original value in the audit log—never the raw PII. For regulated environments (HIPAA, PCI DSS, GDPR), add a human approval gate for any field flagged with confidence below 0.85. Route those cases to a review queue where a human operator can inspect the redacted field and either approve the redaction, revert it, or apply a different masking strategy. The review decision should be fed back into the field-level cache to improve future automated decisions.

Choose a fast, cost-efficient model for this task. The validation prompt is a high-volume, low-latency operation that runs on every structured output. A smaller model (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned open-weight model) is usually sufficient because the task is narrow: field-by-field classification with a known schema. Avoid using a large, expensive model unless your false positive rate demands it. If you observe a false positive rate above 2% in production, evaluate whether the prompt's scanning rules are too aggressive or whether the model needs more examples of benign-but-PII-shaped values (e.g., test credit card numbers, sample email addresses). Adjust the [CONSTRAINTS] and [EXAMPLES] placeholders in the prompt template to include domain-specific disambiguation guidance before switching to a larger model.

Finally, treat this prompt as product code. Version it in your repository alongside the rest of your application. Write regression tests that include known PII payloads (with synthetic data) and verify that the sanitized output matches expected redactions. Test edge cases: empty payloads, deeply nested fields, arrays of objects, fields with null values, and payloads where every field contains PII. Run these tests in CI before deploying prompt changes. Monitor production metrics: PII detection rate, false positive rate, model call latency, cache hit rate, and human review queue depth. If the human review queue grows beyond a threshold, pause automated processing and investigate.