Service Level and Performance Standard Extraction Prompt

This prompt is built for a single, high-stakes job: converting the quantitative and formulaic service level commitments buried in SaaS and IT contracts into machine-readable JSON records. The ideal user is a legal engineer, compliance analyst, or procurement operations specialist who needs to feed structured SLA data into an obligation tracking system, a vendor risk dashboard, or an automated compliance monitor. The required input is the full text of the SLA exhibit, service level schedule, or the performance standard sections of a master agreement. Without the complete source text—including definitions sections, measurement methodology appendices, and exclusion footnotes—the extraction will be incomplete and unreliable.

Use this prompt when you need to capture measurable performance metrics (e.g., '99.9% uptime'), service credit formulas (e.g., '10% of monthly fees for each 1% below target'), measurement periods (monthly, quarterly, annual), calculation methodologies (measurement points, monitoring tools, data sources), and exclusion windows (scheduled maintenance, force majeure, customer-caused outages). The prompt is designed to reject vague commitments like 'commercially reasonable efforts' and flag them as non-extractable. It requires explicit citation to the source document for every extracted field, which is essential for auditability. Do not use this prompt for general contract summarization, obligation extraction outside of service levels, or for contracts where SLA terms are not present. It will hallucinate rather than return empty results if forced to operate on irrelevant text.

Before wiring this into a production pipeline, you must define the downstream schema that the extracted JSON must satisfy. The prompt expects an [OUTPUT_SCHEMA] placeholder where you inject your target JSON Schema. This schema should enforce field types (e.g., uptime_percentage as a number, not a string), required fields, and enum constraints for fields like measurement_period_unit. The prompt also accepts a [CONSTRAINTS] placeholder for business rules, such as 'flag any service credit that is capped at less than 100% of monthly fees' or 'require explicit citation to a page and paragraph for every numeric value.' Without a strict schema and constraints, the model may return well-formed but semantically wrong data—like extracting a 99.9% uptime target as a string 'ninety-nine point nine percent' or missing that a service credit applies only after a 3-consecutive-month failure window.

The primary failure mode is silent extraction of incorrect formulas. A service credit of '10% of monthly fees per 1% of downtime' is fundamentally different from '10% of monthly fees per incident.' The prompt includes internal validation instructions that ask the model to restate the formula in plain language before outputting the structured field, which gives you a human-reviewable checkpoint. For production use, pair this prompt with a post-extraction validation step that recalculates example service credits from the extracted formula and compares them to examples in the source text. If the recalculated values don't match, route the extraction for human review. Never send unverified SLA credit formulas directly to a financial system.

This prompt template is designed to be dropped directly into your contract review pipeline. It instructs the model to extract service level commitments, performance standards, measurement methodologies, service credit calculations, uptime guarantees, and exclusion windows from the provided [CONTRACT_TEXT]. The critical design principle is strict extraction: the model is explicitly forbidden from inferring, calculating, or fabricating values not present in the source text. Every extracted field must be paired with a precise citation to the source section, and any missing field must be explicitly set to null with a confidence of 0. This approach reduces hallucination risk in high-stakes legal and procurement workflows.

Below is the copy-ready template. Replace the [CONTRACT_TEXT] placeholder with the full text of the agreement you are analyzing. The [OUTPUT_SCHEMA] placeholder should be replaced with your application's expected JSON schema structure, which should include fields for service_levels, measurement_periods, service_credits, uptime_guarantees, and exclusion_windows. For each extracted item, the schema must capture the value, source_citation (section, paragraph, or page), and a confidence score (0.0 to 1.0). For service credit formulas, extract the exact formula language and any calculation examples provided. For measurement periods, extract specific calendar periods, measurement windows, and minimum measurement thresholds. For exclusion windows, extract all planned maintenance, force majeure, and other carve-out periods with their duration limits. For uptime guarantees, extract the percentage target, the measurement denominator, and any tiered service level structures.

textCopy
Extract all service level commitments, performance standards, measurement methodologies, service credit calculations, uptime guarantees, and exclusion windows from the contract text below. Return a structured JSON object with precise citations to the source sections. If a field is not present in the source text, set its value to null and set the confidence to 0. Do not infer or calculate values that are not explicitly stated in the contract language. For service credit formulas, extract the exact formula language and any calculation examples provided in the source. For measurement periods, extract the specific calendar periods, measurement windows, and any minimum measurement thresholds. For exclusion windows, extract all planned maintenance, force majeure, and other carve-out periods with their duration limits. For uptime guarantees, extract the percentage target, the measurement denominator, and any tiered service level structures.

[CONTRACT_TEXT]

[OUTPUT_SCHEMA]

To adapt this prompt for your specific use case, start by defining a strict [OUTPUT_SCHEMA] that your downstream application can validate. For example, your schema might require service_credits to be an array of objects, each with a trigger_condition, credit_formula, and calculation_example. Before deploying, run this prompt against a golden dataset of contracts where you know the ground truth for SLA terms. Measure precision and recall on extracted fields, and pay close attention to false positives where the model hallucinates a service credit that doesn't exist. If your contract corpus includes scanned documents, ensure you have a robust OCR and layout-aware text extraction step before this prompt, as garbled input text will degrade extraction quality. In high-risk procurement workflows, always route extractions with a confidence score below your threshold (e.g., <0.9) for human review before they enter your contract management system.

Before calling the model, isolate the SLA section from the full contract using a document structure parser or section classifier. This step targets the relevant exhibit or schedule, reducing context window waste and preventing the model from confusing general contract language with specific SLA commitments. Feed only the extracted SLA text into the prompt's [INPUT] placeholder to keep the model focused on performance standards, service credits, and uptime guarantees.

After receiving the model response, validate the JSON structure against the expected output contract. Run a calculation consistency check: if the service credit formula includes a percentage of fees, verify that the extracted formula matches any examples provided in the source text. Flag any extraction where confidence is below 0.8 for human review. Log every extraction with the source document version, extraction timestamp, and model version for audit trail purposes. For production deployments, implement a retry loop with temperature variation if the initial extraction fails JSON schema validation.

Route extractions with missing uptime guarantees or service credit formulas to a human review queue before loading into obligation tracking systems. This gating step prevents incomplete SLA data from propagating into downstream compliance dashboards or contract management platforms. Consider implementing a structured diff against previous extractions of the same document to detect regression in extraction quality when prompt versions change.