Error Code SLA Mapping Prompt

This prompt is designed for product managers and API governance teams who need to produce a structured, defensible Service Level Agreement (SLA) matrix for their API's error responses. The core job-to-be-done is translating a catalog of technical error codes into business-level commitments: defining target response times, severity classifications, and escalation policies for each error condition. The ideal user is someone who owns the API's reliability posture and must communicate these commitments clearly to both engineering teams (who build the response mechanisms) and customers (who rely on the SLA for their own operational planning).

Use this prompt when you have a defined set of error codes—from an OpenAPI specification, an internal error catalog, or a monitoring system—and need to assign measurable SLA parameters to them. The prompt requires a structured [ERROR_CATALOG] input containing error codes, their HTTP status codes, and descriptions. It also requires an [SLA_TIER_DEFINITIONS] context that defines your organization's standard response time bands (e.g., 'Critical: 15 min response, 1 hr resolution'). The prompt is designed to reason about error criticality based on status code families, the operation's business impact, and whether the error blocks a core customer workflow. It will flag errors that lack appropriate urgency and identify SLA definitions that are vague or unmeasurable.

Do not use this prompt for generating the error codes themselves—that is the job of the 'Error Code Catalog Generation Prompt' in this same content group. This prompt assumes a stable error taxonomy already exists. It is also not a substitute for legal review of your SLA terms; the output is a product and engineering artifact that should be validated by your legal and compliance teams before publication. Avoid using this prompt for purely internal operational runbooks; for that, use the 'Error Code to Runbook Mapping Prompt', which focuses on diagnostic steps rather than customer-facing commitments. The next step after generating the SLA matrix is to validate it against your team's actual incident response capacity and to wire the severity classifications into your alerting and escalation tooling.

This prompt template is designed for product managers and platform engineers who need to produce a structured SLA matrix from error code definitions and business requirements. It takes a list of error codes, their technical descriptions, and organizational SLA policies as input, then outputs a complete mapping with measurable commitments. Use this template when you have a defined error taxonomy and need to formalize operational response expectations. Do not use it to invent error codes or SLA policies from scratch—the prompt assumes those inputs already exist.

textCopy
You are an SLA architect for API products. Your task is to map a set of error codes to SLA tiers, response time targets, and escalation policies.

## INPUT
[ERROR_CODE_CATALOG]

## SLA POLICIES
[SLA_TIER_DEFINITIONS]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "sla_matrix": [
    {
      "error_code": "string",
      "http_status": "integer",
      "sla_tier": "string (must match a tier defined in SLA_TIER_DEFINITIONS)",
      "response_time_target": "string (ISO 8601 duration or human-readable with unit)",
      "escalation_policy": {
        "first_responder": "string (team or role)",
        "escalation_trigger": "string (condition that triggers escalation)",
        "escalation_target": "string (team or role)",
        "max_time_to_escalate": "string"
      },
      "communication_channel": "string",
      "requires_status_page_update": "boolean",
      "notes": "string (justification for tier assignment or edge case handling)"
    }
  ],
  "unmapped_errors": ["string (error codes from the catalog that could not be mapped)"],
  "coverage_gaps": ["string (SLA tiers with no mapped errors)"],
  "validation_warnings": ["string (inconsistencies or risks identified during mapping)"]
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Map every error code in the catalog to exactly one SLA tier.
2. If an error code does not fit any defined tier, place it in `unmapped_errors` with a note explaining why.
3. Flag any SLA tier that has no mapped errors in `coverage_gaps`.
4. Ensure response time targets are measurable and include the unit.
5. For critical-path errors (5xx, authentication failures, rate limit exhaustion), verify that the assigned tier has appropriate urgency. If not, add a `validation_warning`.
6. Escalation policies must specify a trigger condition, not just a time threshold.
7. If [RISK_LEVEL] is "high", require human review of the final matrix before publication.
8. Do not invent error codes or SLA tiers not present in the input.

To adapt this template, replace each square-bracket placeholder with concrete content. [ERROR_CODE_CATALOG] should contain your full error code list with HTTP status codes and descriptions. [SLA_TIER_DEFINITIONS] should define each tier's name, response time baseline, and escalation rules. [CONSTRAINTS] can specify regulatory requirements, business hours vs. 24/7 coverage, or maximum acceptable downtime. [EXAMPLES] should include at least two correctly mapped error codes to anchor the model's output format. [RISK_LEVEL] controls whether the prompt requires a human review gate—set it to "high" for customer-facing or revenue-critical APIs. After generating the matrix, validate that every critical-path error has a response time target below your business's maximum tolerable downtime, and run a completeness check to ensure no error code is left unmapped without explicit justification.

This prompt is designed to be integrated into a product management or API governance workflow, not as a one-off chat interaction. The primary integration point is a documentation pipeline or an internal tool that ingests an existing error code catalog and a set of SLA tier definitions. The application layer should first fetch the complete error code inventory from a source of truth, such as an OpenAPI specification, a database of record, or a static JSON file, and format it as the [ERROR_CATALOG] input. Simultaneously, it must retrieve the organization's standard SLA tier definitions, including response time targets, severity levels, and escalation policies, to populate the [SLA_TIERS] and [ESCALATION_POLICIES] inputs. The prompt should only be invoked when both inputs are complete and validated, as missing data will produce an incomplete or misleading SLA matrix.

The implementation must include a pre-processing validation step to ensure every error code in the catalog has a defined severity and that every SLA tier referenced has a measurable target. After the model returns the structured SLA matrix, a post-processing validation layer should parse the JSON output and run a series of checks: confirm that all critical-path errors (typically 5xx and key 4xx codes) are mapped to the highest-urgency tiers, verify that no SLA definition contains unmeasurable commitments like 'as soon as possible,' and ensure that every escalation policy referenced actually exists in the input. If validation fails, the system should log the specific failure, append the validation errors to the prompt context, and retry once. For high-stakes deployments, the final matrix should be routed to a human review queue in a tool like Jira or a custom internal dashboard before being published to an SLA page or an API contract.

Model choice matters here: use a model with strong JSON mode and schema-following capabilities, such as GPT-4o, Claude 3.5 Sonnet, or an equivalent. Set the response_format to json_schema and provide the exact output schema from the prompt template to guarantee structural validity. Log every invocation, including the input hashes, the model version, the raw and validated outputs, and the reviewer's decision, to create an audit trail for governance reviews. Avoid wiring this prompt directly into a customer-facing SLA page without the validation and human review gates; a hallucinated SLA commitment can create contractual risk. The next step after a successful run is to diff the new matrix against the previous version to generate a changelog of SLA changes, which can be fed into a downstream Error Code Changelog Generation Prompt for consumer communication.