Date Validation Against Business Rules Prompt Template

This prompt is for compliance engineers, booking system operators, and backend developers who need to programmatically validate dates against a set of explicit business rules. The job-to-be-done is not just checking if a string looks like a date, but confirming whether a given date is permissible within a specific operational context—such as 'must be a future date,' 'must fall within the next 90 days,' or 'must not be a company holiday.' The ideal user is someone integrating this validation into an application pipeline, where a pass/fail result with structured violation details is required for downstream logic, not a conversational explanation.

Use this prompt when you have a known set of rules that can be expressed as clear constraints (e.g., [RULES]). It is designed for synchronous validation steps within a larger workflow, such as checking a user-submitted date in a booking form before writing to a database. The prompt expects a specific date input and a defined rule set, and it returns a deterministic structure: a valid boolean, a list of violations with rule references, and suggested corrections. This structure makes it directly consumable by application code. Do not use this prompt for open-ended date reasoning, natural language querying of a calendar, or for generating date sequences. It is a validation gate, not a conversational agent.

Before implementing, define your rule set precisely. Ambiguous rules like 'reasonable timeframe' will produce inconsistent results. Instead, use concrete boundaries: 'must be after [CURRENT_DATE]', 'must be within [WINDOW_START] and [WINDOW_END]', or 'must not match dates in [HOLIDAY_LIST]'. For high-stakes domains like healthcare scheduling or financial compliance, always route failures to a human review queue and log the full prompt and response for audit trails. The next step is to copy the prompt template and wire it into your application's validation harness, ensuring that the [RULES] and [HOLIDAY_LIST] placeholders are populated from a single source of truth in your system.

This template is designed to be dropped directly into your application's validation layer. It accepts a date string, a set of business rules expressed in natural language, and an optional reference context (such as a holiday calendar or operating hours). The model acts as a deterministic validator, not a conversational assistant. It must return a structured JSON object that your application can parse and act on—no explanations, no apologies, no markdown wrapping.

textCopy
You are a date validation engine. Your only job is to check whether the provided date satisfies the given business rules. You must return a strict JSON object with no additional text, markdown, or commentary.

INPUT DATE: [INPUT_DATE]

BUSINESS RULES:
[BUSINESS_RULES]

REFERENCE CONTEXT (if any):
[REFERENCE_CONTEXT]

OUTPUT SCHEMA:
{
  "valid": boolean,
  "violations": [
    {
      "rule_id": "string identifier matching the rule that was violated",
      "rule_description": "human-readable description of the violated rule",
      "violation_detail": "specific explanation of how the date violates this rule",
      "suggested_correction": "a concrete alternative date or action that would satisfy the rule, or null if no correction is possible"
    }
  ],
  "evaluation_notes": "brief technical notes about edge cases encountered during validation, or null if none"
}

CONSTRAINTS:
- If the date is valid, return valid=true and an empty violations array.
- If the date is invalid, return valid=false and populate violations for every rule that fails.
- Do not hallucinate rules. Only evaluate the rules provided in BUSINESS_RULES.
- If a rule references REFERENCE_CONTEXT (e.g., 'must not be a holiday'), use the provided context to evaluate it. If context is missing or insufficient, flag it in evaluation_notes and treat the rule as unevaluable.
- For date parsing, assume ISO 8601 format unless the rule specifies otherwise. If the date string is ambiguous or unparseable, return a single violation with rule_id "PARSE_ERROR".
- Do not add, remove, or reinterpret business rules.

To adapt this template, replace each square-bracket placeholder with values from your application context. [INPUT_DATE] should be the date string under validation. [BUSINESS_RULES] should be a numbered or bulleted list of rules in plain English—for example, '1. Must be a future date. 2. Must not fall on a weekend. 3. Must be within 90 days of today.' [REFERENCE_CONTEXT] is optional but critical for rules that depend on external data; inject your holiday calendar, operating hours, or blackout periods here as structured text. After copying the template, test it against known-valid and known-invalid dates before wiring it into a production pipeline. If your rules involve time-of-day constraints, extend the INPUT_DATE to include a time component and update the schema to include a violated_time field where relevant.

This prompt is designed to be called as a post-extraction validation gate in a data pipeline or booking system. The typical flow is: (1) a date value is extracted or received from user input, (2) the application injects that date along with the relevant business rules into this prompt, and (3) the model returns a structured pass/fail verdict. The application should never take action on a date until this verdict is parsed and confirmed. Because the output is a structured JSON object with a valid boolean, the integration code can branch cleanly: if valid → proceed with the date; if not valid → surface the violation details to the user or log for manual review.

Wiring the prompt into code requires a thin harness that handles three responsibilities. First, input assembly: collect the date string to validate, the business rules (future-only, within-window, non-holiday, etc.), and any reference context like a holiday calendar or cutoff timestamp. Second, output parsing: expect a JSON object with valid, violations, rule_references, and suggested_correction fields. Use a JSON schema validator in your application code—do not trust the model to always return perfect JSON. If parsing fails, retry once with a stricter output instruction appended to the prompt. Third, decision routing: on valid: true, pass the date downstream; on valid: false, log the full violation payload and either block the transaction or route to a human review queue depending on the severity field in the violation details.

Model choice and latency considerations matter here. This is a classification-plus-explanation task, not a generative task, so smaller and faster models (e.g., Claude Haiku, GPT-4o-mini, or a fine-tuned open-weight model) often perform well. If your application validates dates in a synchronous user flow (e.g., a booking form submission), target sub-500ms response times by using a lightweight model and keeping the prompt under 500 tokens. For batch validation of thousands of records, run the prompt asynchronously with a concurrency limit and collect violation reports for offline review. Always log the raw prompt, raw response, and parsed verdict to your observability platform so you can trace false positives and false negatives back to specific rule phrasing or model behavior.

Retry and escalation logic should be explicit. If the model returns malformed JSON, retry once with the original prompt plus a repair instruction: Your previous response was not valid JSON. Return ONLY a valid JSON object with the fields specified. If the second attempt also fails, log the failure and escalate to a human operator with the original date and rules attached. For high-risk domains like compliance or financial booking, do not auto-correct dates based on the model's suggested_correction field—treat it as a hint for a human reviewer, not an automated fix. The prompt includes a [RISK_LEVEL] placeholder; when set to high, your harness should require explicit human approval before any date is accepted, regardless of the model's verdict.

Testing and evaluation should be built into the harness from day one. Maintain a golden dataset of date-rule pairs with known pass/fail outcomes, including boundary cases (e.g., a date exactly at the cutoff, a date during a holiday, a date with ambiguous timezone). Run this dataset through the prompt on every prompt change and model upgrade. Track precision and recall on violation detection separately—false negatives (accepting an invalid date) are typically more costly than false positives (flagging a valid date for review). If your application uses a holiday calendar or business-hours reference, version that reference data alongside the prompt so you can reproduce results. Finally, set up a production sampling loop where 5% of validations are shadow-reviewed by a human to catch drift in model behavior before it causes business impact.