Contract Entitlement Gap Detection Prompt

Use this prompt when you need an automated, auditable decision about whether a customer's requested action falls within their contracted entitlements. The primary job-to-be-done is preventing revenue leakage and compliance exposure by catching entitlement gaps before a feature is unlocked, a support ticket is routed to a premium queue, or a service-level commitment is triggered. The ideal user is a revenue operations engineer or a compliance platform builder embedding this check into middleware, an API gateway, or a support ticketing system. The prompt requires two structured inputs: a clear description of the requested action and the customer's known contract terms, which can be provided as structured JSON, key-value pairs, or semi-structured text from a CRM or billing system.

This prompt is designed for deterministic gap detection, not for interpreting novel or highly ambiguous contract language. It excels when the contract terms are explicit (e.g., 'Enterprise tier includes 24/7 phone support' or 'Up to 10,000 API calls per month') and the request is concrete (e.g., 'Customer requests phone support for a P3 issue'). In these cases, the prompt will output a structured decision with a gap_detected boolean, a list of specific violated terms, and a recommended handling path like route_to_standard_queue or escalate_for_manual_review. The prompt includes false-positive controls by requiring the model to cite the exact contract clause that creates the gap, and by providing a confidence_score that you can threshold to route low-confidence cases to a human.

Do not use this prompt as a replacement for legal review when contract language is vague, when the customer disputes the terms, or when the request involves a custom enterprise agreement with non-standard clauses that require human interpretation. In these scenarios, the prompt should be configured to return a confidence_score below your threshold, which your application harness should catch and route to a manual review queue. The next section provides the copy-ready prompt template you can adapt for your own contract schemas and routing logic.

This prompt template is designed to be copied directly into your application's prompt layer. It accepts a customer request, the relevant contract entitlements, and a routing context, then produces a structured gap analysis. Every placeholder is enclosed in square brackets and must be replaced with live data at invocation time. The prompt is built for deterministic, auditable output that downstream systems can act on without manual interpretation.

textCopy
You are an entitlement verification engine. Your job is to compare a customer request against their contracted entitlements and detect any gaps where the request falls outside what the contract permits.

## INPUTS

### Customer Request
[REQUEST_DETAILS]

### Contracted Entitlements
[ENTITLEMENTS]

### Account Context
- Account Tier: [ACCOUNT_TIER]
- SLA Tier: [SLA_TIER]
- Account Health Score: [HEALTH_SCORE]
- Contract Start Date: [CONTRACT_START]
- Contract End Date: [CONTRACT_END]
- Custom Terms: [CUSTOM_TERMS]

### Routing Context
- Request Type: [REQUEST_TYPE]
- Requested Feature or Service: [REQUESTED_FEATURE]
- Current Queue: [CURRENT_QUEUE]
- Elapsed Time Since Request: [ELAPSED_TIME]

## OUTPUT SCHEMA

Return a JSON object with the following structure:

{
  "entitlement_check": {
    "requested_item": "string (the feature, service, or support level requested)",
    "is_entitled": "boolean (true if the request falls within contracted entitlements)",
    "matched_entitlement": "string or null (the specific contract clause or entitlement that covers this request)",
    "confidence": "number between 0.0 and 1.0"
  },
  "gap_detected": "boolean (true if any part of the request is not covered by entitlements)",
  "gaps": [
    {
      "gap_type": "string (one of: 'feature_not_entitled', 'tier_mismatch', 'sla_exceeded', 'contract_expired', 'usage_limit_reached', 'custom_term_restriction', 'not_in_scope')",
      "description": "string (clear explanation of what was requested vs what is permitted)",
      "severity": "string (one of: 'critical', 'high', 'medium', 'low')",
      "recommended_action": "string (one of: 'deny_with_explanation', 'escalate_to_account_manager', 'offer_upgrade_path', 'route_to_sales', 'manual_review_required', 'honor_as_grace_period')"
    }
  ],
  "routing_decision": {
    "target_queue": "string (where this request should be routed)",
    "escalation_required": "boolean",
    "escalation_reason": "string or null",
    "sla_breach_risk": "boolean",
    "breach_risk_detail": "string or null"
  },
  "audit_trail": {
    "contract_clauses_referenced": ["string"],
    "ambiguity_notes": "string or null (flag any unclear or conflicting entitlement language)",
    "fallback_applied": "boolean (true if a default or fallback entitlement rule was used)"
  }
}

## CONSTRAINTS

- If the contract language is ambiguous, set confidence below 0.8 and flag it in ambiguity_notes.
- Do not assume entitlement unless there is explicit contract language supporting it.
- For accounts in a downgrade grace period, apply the pre-downgrade entitlements and note it in audit_trail.
- If the account has custom terms in [CUSTOM_TERMS], those override standard tier entitlements.
- Never route a denied request to a queue that could fulfill it without proper entitlement verification.
- If gap severity is 'critical' or 'high', escalation_required must be true.
- Return only the JSON object. No additional commentary.

To adapt this prompt for your environment, replace each square-bracket placeholder with live data from your account service, contract store, and request pipeline. The output schema is designed to feed directly into a routing dispatcher: use routing_decision.target_queue to move the request and gaps[].recommended_action to trigger the correct handling workflow. If your system lacks some fields like HEALTH_SCORE or ELAPSED_TIME, either omit those sections or set them to null and adjust the constraints accordingly. The gap_type enum should be extended only if your contract model introduces new categories of entitlement violations.

Before deploying, validate this prompt against a golden dataset of known entitlement scenarios: requests that are clearly entitled, clearly denied, and ambiguous. Measure false-positive gap flags (denying entitled requests) and false-negative gaps (approving unentitled requests). Both failure modes carry risk, but false negatives that grant access to unentitled features or support channels are typically the higher-severity error in revenue and compliance contexts. Wire the confidence field into an observability dashboard so you can track ambiguity rates over time and identify contract language that consistently produces low-confidence decisions.

This prompt is a classification and routing tool, not a contract interpretation engine for legal disputes. If the gap severity is critical or the confidence is below 0.6, the recommended action should route to manual review rather than attempting automated resolution. Do not use this prompt to make entitlement decisions that carry financial liability, regulatory exposure, or customer termination risk without a human-in-the-loop approval step.

This prompt is designed to sit inside a compliance or revenue operations workflow where a customer request has already been classified and the system must verify whether the request falls within the customer's contracted entitlements. The harness should treat this prompt as a decision point, not a final action. The model's output is a structured gap assessment that downstream systems use to route the request to fulfillment, upsell, or exception handling. Because false negatives (missing a real gap) create revenue leakage and false positives (flagging an entitled request as a gap) degrade customer trust, the implementation must include validation, confidence thresholds, and human review for ambiguous cases.

Integration pattern: Call this prompt after you have resolved the customer's effective contract terms and the specific feature, service, or support level being requested. The application layer should assemble the [CONTRACT_ENTITLEMENTS] and [REQUEST_DETAILS] inputs from your contract store and ticketing system, not from raw user text. Use a structured output schema that requires the model to return a gap_detected boolean, a gap_type enum (e.g., feature_not_entitled, tier_mismatch, volume_exceeded, sla_not_covered), a confidence_score between 0 and 1, the specific contract_clause_reference, and a recommended_handling_path (e.g., fulfill, upsell_required, exception_review, escalate_to_account_manager). Validate the response against this schema before allowing any downstream routing decision. If confidence_score is below 0.85 or the gap_type is ambiguous, route to a human review queue with the full context attached.

Model selection and tool use: This is a reasoning-heavy classification task that benefits from models with strong instruction-following and structured output capabilities. GPT-4o, Claude 3.5 Sonnet, or equivalent models are appropriate. The prompt does not require tool calls or retrieval-augmented generation because the contract terms and request details are provided inline. However, if your contract store is large, consider a pre-retrieval step that pulls only the relevant entitlement clauses before assembling the prompt context. This reduces token usage and prevents the model from reasoning over irrelevant contract sections. Log every invocation with the prompt version, model, inputs, output, confidence score, and final routing decision for auditability. For high-volume production use, implement a retry with fallback pattern: if the model returns malformed JSON or a confidence score below 0.7, retry once with a simplified prompt variant, and if that fails, escalate to human review.

Failure modes to monitor: The most common production failure is the model flagging a gap when the customer actually has entitlement through an addendum, a parent account, or a bundled plan that wasn't fully represented in the [CONTRACT_ENTITLEMENTS] input. Mitigate this by ensuring your contract resolution layer handles inheritance, bundles, and addenda before calling this prompt. A second failure mode is the model failing to detect a gap when the request uses terminology that doesn't match the contract language. Include a [TERMINOLOGY_MAPPING] input field that maps common customer-facing feature names to contract clause names. Finally, monitor for confidence-score inflation: if the model consistently returns high confidence on incorrect gap flags, add eval checks that compare model decisions against a golden dataset of known entitlement cases and adjust the confidence threshold upward.

Next steps after implementation: Once the harness is in place, build a dashboard that tracks gap detection rates by customer tier, gap type, and handling path. This data feeds directly into product and pricing decisions. If a specific gap type appears frequently, it may indicate that your packaging needs adjustment or that customers consistently misunderstand what's included. Wire the recommended_handling_path output into your CRM or ticketing system so that upsell opportunities are routed to the sales team and exception reviews go to the appropriate approver. Avoid the temptation to automate fulfillment or denial based solely on this prompt's output without human review for high-value accounts or ambiguous cases.