Contact Import Pre-Flight Validation Prompt Template

This prompt is designed for CRM administrators, data engineers, and integration developers who need to validate contact records before they enter a production system. It accepts a batch of contact records and a set of custom validation rules, then produces a structured validation report that flags field-level errors, format violations, duplicate warnings, and required-field completeness. Use this prompt when you need a pre-flight check that stops bad data before it reaches your CRM, CDP, or customer database. This prompt belongs in the data ingestion pipeline, not in post-ingestion cleanup. Run it before any INSERT or UPSERT operation.

The ideal scenario is a batch import workflow where contact data arrives from multiple sources—form submissions, API integrations, model-generated outputs, or file uploads—and you need a consistent, auditable gate before the data touches your system of record. The prompt expects two inputs: a JSON array of contact records and a validation rules object that defines required fields, format patterns, uniqueness constraints, and acceptable value ranges. It returns a structured report with per-record pass/fail status, field-level error details, and aggregate batch statistics. Do not use this prompt for real-time single-record validation where latency is critical; a deterministic validator in application code will be faster and cheaper. Do not use it for post-ingestion data cleansing, deduplication across existing records, or enrichment—those are separate workflows covered by sibling playbooks like Contact Record Deduplication and Golden Record Selection.

Before deploying this prompt, ensure your validation rules are explicit and testable. Ambiguous rules like 'email should look valid' will produce inconsistent results. Instead, define rules with regex patterns, allowed enum values, and explicit required-field lists. Wire the prompt into your ingestion pipeline with a hard cutoff: records that fail validation should be quarantined, not silently dropped. Log every validation report for audit trails. If your batch exceeds the model's context window, chunk it and run validation per chunk with consistent rules. For high-risk domains like healthcare or finance, add a human review step for records flagged with warnings rather than hard failures—the model may misinterpret edge-case formats that a domain expert would accept.

This prompt template is designed to be copied directly into your application's prompt layer. It accepts a batch of contact records, a set of custom validation rules, and an output schema, then produces a structured validation report. Every placeholder is enclosed in square brackets and must be replaced with concrete values at runtime—either hardcoded in your prompt version or injected by your application harness. Do not ship this template with unresolved placeholders.

textCopy
You are a contact import validation engine. Your job is to inspect a batch of contact records and produce a validation report that flags every field-level error, format violation, duplicate warning, and required-field gap before the records enter a CRM.

## INPUT
[CONTACT_BATCH]

## VALIDATION RULES
Apply the following rules to every record in the batch. Rules marked REQUIRED must fail the record if violated. Rules marked WARNING should be noted but do not block ingestion.

[VALIDATION_RULES]

## OUTPUT SCHEMA
Return a single JSON object with this exact structure:
{
  "batch_summary": {
    "total_records": <integer>,
    "passed": <integer>,
    "failed": <integer>,
    "warnings_only": <integer>
  },
  "records": [
    {
      "record_index": <integer>,
      "status": "passed" | "failed" | "warning",
      "fields": {
        "<field_name>": {
          "value": <original value or null>,
          "status": "valid" | "invalid" | "missing" | "warning",
          "error": <string or null>,
          "suggested_fix": <string or null>
        }
      },
      "duplicate_of": <integer or null>,
      "duplicate_confidence": <float between 0 and 1 or null>
    }
  ]
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Validate every record against every applicable rule.
2. For duplicate detection, compare records within the batch using the fields specified in [DUPLICATE_MATCH_FIELDS].
3. If a field is required by the rules and missing or empty, mark it as "missing" with status "invalid".
4. If a field is present but violates a format rule, mark it as "invalid" and include a specific error message.
5. If a field triggers a WARNING rule, mark it as "warning" and include the warning reason.
6. Never invent or guess field values. If a field is missing, set its value to null.
7. If [RISK_LEVEL] is "high", flag any record with more than [MAX_ALLOWED_FAILURES] failed fields for human review by setting status to "failed" and adding a top-level "requires_review": true flag.
8. Return ONLY the JSON object. No markdown, no commentary, no code fences.

To adapt this template for your pipeline, replace each placeholder with concrete values. [CONTACT_BATCH] should receive your serialized contact records—typically a JSON array of objects. [VALIDATION_RULES] must be a structured description of your field requirements, format rules, and duplicate detection logic. If your CRM expects email addresses to match RFC 5322, state that explicitly. If phone numbers must be E.164, say so. [CONSTRAINTS] should capture output limits like maximum batch size, field length caps, or disallowed characters. [EXAMPLES] should include at least one passing record, one failing record with field-level errors, and one duplicate pair. [DUPLICATE_MATCH_FIELDS] defines which fields to compare—typically email, phone, or a composite key. [RISK_LEVEL] and [MAX_ALLOWED_FAILURES] control whether the prompt escalates records for human review. Test your filled template against a golden dataset of known-good and known-bad records before deploying.

The Contact Import Pre-Flight Validation prompt is designed to sit between your contact data source and your CRM ingestion endpoint. In a typical implementation, you'll receive a batch of contact records—from a CSV upload, an API payload, a model extraction pipeline, or a manual data entry form—and you need to validate them before they hit your system of record. The prompt expects a structured input containing the contact batch, your validation rules, and the expected output schema. You should wrap this prompt in an application layer that handles chunking for large batches, enforces rate limits, and manages partial failures without losing validated records.

For production wiring, implement a validation harness that does the following: (1) Split large batches into chunks of 50-100 records to stay within context windows and avoid token exhaustion. (2) Pre-process each chunk to extract the fields your validation rules reference—don't send raw, unparsed blobs. (3) Call the prompt with a structured [INPUT] object containing records, validation_rules, and [OUTPUT_SCHEMA]. (4) Parse the model's JSON response and run it through a schema validator (JSON Schema or Pydantic) before trusting the output. If the response fails schema validation, retry once with the validation error injected into [CONTEXT]. If it fails twice, route the chunk to a human review queue with the raw records and the partial validation output. (5) Log every validation run with the prompt version, model, chunk ID, timestamp, and pass/fail counts for auditability. For model choice, GPT-4o and Claude 3.5 Sonnet handle structured validation reliably; avoid smaller models for batches with complex custom rules or nested field dependencies.

The most common production failure mode is custom rule injection breaking the output schema. When users supply free-text validation rules in [CONSTRAINTS], the model may produce a valid report that doesn't match your expected JSON structure—missing fields, extra commentary, or nested objects where arrays are expected. Mitigate this by always including a strict [OUTPUT_SCHEMA] with required fields, types, and enum constraints. For high-stakes imports (financial data, healthcare contacts, compliance-sensitive records), add a human approval step before the validated batch reaches your CRM. The prompt's [RISK_LEVEL] parameter should gate this: set it to high for regulated data, which triggers a review flag in your harness. Finally, build a regression test suite with known-bad contact batches—duplicate emails, malformed phone numbers, missing required fields, encoding artifacts—and run it against every prompt version before deployment. This catches silent regressions where a prompt update fixes one validation case but breaks another.