Contact Data Trust Score Assignment Prompt Template

This prompt is designed for data governance teams and data quality engineers who need to assign a reliability score to contact records produced by model pipelines, extraction workflows, or multi-source reconciliation jobs. The core job-to-be-done is not just flagging bad records, but producing a calibrated, explainable trust score that downstream systems—such as CRM ingestion, identity resolution, or customer data platforms—can use to make automated routing decisions. The ideal user is someone who already has contact records with associated metadata (source freshness, validation results, completeness metrics) and needs a repeatable, auditable method to convert that evidence into a single trust signal.

You should use this prompt when you have per-record provenance and validation context available. Required inputs include the contact record itself, a source identifier, a timestamp indicating data freshness, a completeness ratio, and the results of any prior validation checks (email syntax, phone number format, address parsability). The prompt is most effective when these inputs are provided as structured fields rather than free-text descriptions, allowing the model to reason over concrete signals. It is not a replacement for upstream validation—if you haven't yet normalized emails or canonicalized phone numbers, run those repair prompts first. The trust score output is a downstream synthesis step, not a data cleaning step.

Do not use this prompt when you lack provenance metadata or when the contact records have not passed through basic format validation. Without source freshness and completeness signals, the model will be forced to guess, producing unreliable scores that erode trust in the pipeline. This prompt is also inappropriate for real-time user-facing flows where latency constraints prevent the inclusion of rich context; it belongs in batch processing or asynchronous ingestion paths. If the contact data contains regulated PII that cannot be sent to an external model, ensure you are using a private deployment or have redacted sensitive fields before invoking this prompt. Finally, if your downstream system requires a binary accept/reject decision rather than a continuous score, pair this prompt with a threshold calibration step based on your own ground-truth evaluation set—do not rely on the model's raw score boundaries without tuning.

The following prompt template is designed to be copied directly into your prompt management system, evaluation harness, or orchestration layer. It accepts a batch of contact records along with their metadata—source, extraction timestamp, validation results, and completeness profile—and returns a trust score for each record with structured reasoning. Use square-bracket placeholders to inject your specific inputs, output schema, constraints, and risk thresholds before sending the prompt to the model.

textCopy
You are a contact data quality analyst. Your task is to assign a trust score to each contact record based on the evidence provided.

## INPUT
Contact records with metadata:
[CONTACT_RECORDS]

## SCORING CRITERIA
Evaluate each record on these dimensions (0.0 to 1.0 scale):
1. **Source Freshness**: How recently was this record extracted or updated? Newer sources get higher scores. Consider [FRESHNESS_WINDOW_DAYS] as the recency threshold.
2. **Completeness**: What percentage of [REQUIRED_FIELDS] are populated with non-null, non-empty values?
3. **Validation Results**: How many fields passed their respective validators? Use [VALIDATION_RESULTS] for per-field pass/fail data.
4. **Provenance Strength**: Is the source system authoritative (e.g., CRM, HRIS) or inferred (e.g., email signature extraction)? Use [SOURCE_AUTHORITY_MAP] to weight sources.

## OUTPUT SCHEMA
Return a JSON array of objects with this exact structure:
[OUTPUT_SCHEMA]

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
- Compute a weighted trust score for each record using the formula: (freshness * [FRESHNESS_WEIGHT]) + (completeness * [COMPLETENESS_WEIGHT]) + (validation_pass_rate * [VALIDATION_WEIGHT]) + (provenance * [PROVENANCE_WEIGHT]).
- Include a `reasoning` field that explains the score breakdown for each record.
- Flag any record with a trust score below [LOW_TRUST_THRESHOLD] with `requires_review: true`.
- If [RISK_LEVEL] is "high", also flag records where any single dimension score is below [CRITICAL_DIMENSION_THRESHOLD].
- Do not invent or infer missing field values. If a field is absent, treat it as incomplete.
- Return only valid JSON. No markdown, no commentary outside the JSON structure.

To adapt this template for your pipeline, replace each placeholder with concrete values. [CONTACT_RECORDS] should be a JSON array of contact objects with their metadata attached. [OUTPUT_SCHEMA] must define the exact fields you expect in the response—typically record_id, trust_score, dimension_scores, reasoning, and requires_review. [CONSTRAINTS] can include field-specific rules like "email must pass RFC validation to count as complete" or "records from source X always require human review." [EXAMPLES] should include at least two few-shot demonstrations: one high-trust record and one low-trust record with annotated reasoning. Before deploying, run this prompt through your eval harness using ground-truth trust scores to calibrate the weights and thresholds. If the workflow feeds into automated CRM ingestion, require human review for all records below the low-trust threshold rather than silently accepting them.

The Contact Data Trust Score Assignment prompt is designed to be called as a post-extraction scoring step inside a data pipeline, not as a standalone interactive prompt. After your extraction or normalization pipeline produces a contact record, pass that record—along with its provenance metadata, validation results, and freshness timestamps—into this prompt to receive a structured trust score object. The output should be consumed programmatically: parse the JSON, validate the score range (0.0–1.0), and write the result to your data catalog or feature store alongside the record. Do not treat this as a user-facing chat interaction; it is a machine-to-machine scoring function implemented via an LLM call.

Input assembly requires five placeholders: [CONTACT_RECORD] (the full record as JSON), [SOURCE_METADATA] (origin system, ingestion timestamp, update frequency), [VALIDATION_RESULTS] (field-level pass/fail from your schema validator), [COMPLETENESS_STATS] (filled vs. total fields, critical field presence), and [PROVENANCE_CHAIN] (upstream transforms applied). Build these inputs from your pipeline context before calling the model. Model choice matters: use a model with strong JSON-following behavior (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set temperature=0 to minimize score variance across identical inputs. Enable structured output mode if your provider supports it, binding the response to a schema with trust_score (float), confidence (float), scoring_factors (array of objects with factor, score, weight, evidence), and flags (array of strings for human review triggers).

Validation and retry logic should be implemented in the application layer, not left to the model. After receiving the response, validate that trust_score is a number between 0 and 1, that scoring_factors contains at least the required dimensions (freshness, completeness, validation, provenance), and that weights sum approximately to 1.0. If validation fails, retry once with the same input and an explicit error message appended to [CONSTRAINTS]. If the second attempt fails, log the failure and route the record to a human review queue with the raw model output attached. For high-throughput pipelines, implement a circuit breaker: if the failure rate exceeds 5% in a rolling window, pause automated scoring and escalate. Log every scoring call with the input hash, model version, response, validation result, and latency for auditability.

Human review integration is critical because trust scores downstream gate access to CRM updates, identity resolution merges, and compliance reporting. Any record with a trust_score below your calibrated threshold (start with 0.6 and adjust based on eval results) should be flagged for review. Additionally, any record where the model sets a flag value indicating conflicting signals—such as high completeness but low provenance—should route to a review interface that displays the original record, the scoring breakdown, and an override control. Store both the model-assigned score and the human-adjusted score with timestamps and reviewer identity. Use these overrides to calibrate future scoring thresholds and to build a ground-truth dataset for evaluating prompt changes.

Testing before production requires a golden dataset of contact records with known trust characteristics: records with intentionally stale sources, incomplete fields, failed validation, and broken provenance chains. Score this dataset with your prompt and compare against expected score ranges. Measure score stability by running the same record through the prompt five times; scores should not vary by more than 0.05. If variance is higher, tighten your prompt instructions or switch to a model with lower temperature support. Before shipping a prompt update, run the new version against the golden dataset and compare score distributions—a significant shift without a corresponding change in scoring logic indicates prompt drift that needs investigation.

What to avoid: do not call this prompt on every record in a high-volume stream without batching and cost controls. Do not use the trust score as the sole gate for destructive operations (deletes, merges) without human review for scores in the ambiguous middle range. Do not skip logging—without per-call traces, you cannot debug scoring anomalies or demonstrate audit readiness. Finally, do not assume the model will correctly weight factors without calibration; run the eval rubric from the companion playbook regularly and adjust your [CONSTRAINTS] placeholder to correct systematic over- or under-weighting of specific dimensions.