Error Code Consistency Audit Prompt

API governance teams and platform engineers use this prompt to audit error responses across multiple services for consistency violations. The prompt checks naming conventions, HTTP status code alignment, payload structure uniformity, and remediation guidance quality against a defined standard. This is a compliance audit tool, not a design tool—it assumes you already have an error code standard or style guide to audit against. Use this when you have error code definitions from multiple services and need a structured compliance report before a release, during a standardization initiative, or as part of an API review gate.

The ideal input is a collection of error code definitions from at least two services, each including the error code identifier, HTTP status code, response body schema, and any existing remediation text. The prompt works best when you also supply your organization's error code standard as [STANDARD], which should specify naming conventions (e.g., DOMAIN_CATEGORY_REASON), allowed HTTP status codes per error category, required payload fields, and remediation guidance requirements. Without a clear standard, the audit becomes subjective and loses enforcement value. If you need to build that standard first, use the Error Code Taxonomy Builder Prompt instead.

Do not use this prompt for one-off error code reviews or for services that share no common standard. It is designed for cross-service comparison and will produce noisy, low-value output when applied to a single service in isolation. Also avoid using it when the error definitions are still in draft form and the standard itself is unsettled—auditing against a moving target generates churn without improving consistency. For runtime error validation against a live API contract, use the Error Body Schema Validation Prompt. For security-focused error response review, use the Error Code Security Implication Review Prompt. After running this audit, feed the compliance report into your API review gate and track violations as tickets in your backlog.

This template is the core instruction set for an Error Code Consistency Audit. It is designed to be dropped into an AI orchestration layer, a batch evaluation script, or a manual review workflow. The prompt instructs the model to act as an API governance auditor, comparing error responses from multiple services against a defined standard. Replace the square-bracket placeholders with your specific API contracts, error catalogs, and organizational standards before execution.

textCopy
You are an API governance auditor. Your task is to audit error codes across multiple services for consistency.

## AUDIT SCOPE
[ERROR_CATALOG_OR_SPEC]: The canonical error code reference or OpenAPI specification to audit against.
[SERVICE_ENDPOINTS]: A list of service endpoints and their error responses to audit.

## AUDIT CRITERIA
Check each error response against the following standards:
1. **Naming Consistency**: Error codes must follow the [NAMING_CONVENTION] pattern (e.g., UPPER_SNAKE_CASE, domain:code).
2. **HTTP Status Code Alignment**: The HTTP status code must match the error type as defined in [STATUS_CODE_MAPPING_RULES].
3. **Payload Structure Uniformity**: The JSON error body must conform to the [ERROR_BODY_SCHEMA] schema.
4. **Remediation Guidance Quality**: Every error must include a non-empty, actionable `remediation` field that is specific to the error condition.

## OUTPUT FORMAT
Produce a JSON compliance report with the following structure:
{
  "audit_summary": {
    "total_errors_audited": <int>,
    "violations_found": <int>,
    "services_audited": [<string>]
  },
  "violations": [
    {
      "service": "<string>",
      "endpoint": "<string>",
      "error_code": "<string>",
      "violation_type": "NAMING | STATUS_MISMATCH | SCHEMA_VIOLATION | MISSING_REMEDIATION",
      "current_value": "<string>",
      "expected_value": "<string>",
      "suggested_correction": "<string>"
    }
  ]
}

## CONSTRAINTS
- Do not flag errors that are not in the provided [ERROR_CATALOG_OR_SPEC] unless they violate the [ERROR_BODY_SCHEMA].
- If a service is unreachable or returns no errors, note it in the summary but do not fabricate violations.
- For ambiguous cases, set violation_type to "MANUAL_REVIEW" and explain the ambiguity in suggested_correction.

To adapt this template, start by populating the [ERROR_CATALOG_OR_SPEC] with a machine-readable version of your standard, such as a JSON object mapping error codes to their expected status codes and schemas. The [SERVICE_ENDPOINTS] placeholder should be replaced with a structured list of endpoints and their actual response payloads, not just URLs. If you are wiring this into an automated pipeline, ensure the output JSON is validated against the schema before it is ingested by a dashboard or ticketing system. For high-risk APIs where a false negative could mask a critical incident, always route violations with a severity score to a human review queue before auto-applying corrections.

The Error Code Consistency Audit Prompt is designed to run as a batch or CI-integrated step, not as a one-off chat interaction. The primary integration point is a script or service that collects OpenAPI specifications, error catalogs, and actual API response samples from staging or production gateways, then feeds them into the prompt as structured [INPUT]. The output is a structured compliance report that downstream systems can parse to open tickets, block releases, or update dashboards. Do not use this prompt in a synchronous user-facing flow; it is a governance tool meant for API platform teams and should run on a schedule (e.g., weekly) or as a pre-release gate in a CI/CD pipeline.

Integration pattern: Build a harness that (1) fetches the latest OpenAPI specs and error documentation from your source of truth, (2) samples recent error responses from your API gateway logs or a dedicated error-tracking store, (3) assembles the prompt with these inputs plus your organization's error standards document as [CONSTRAINTS], and (4) calls the model with response_format set to a strict JSON schema matching the expected compliance report structure. Validation: After receiving the model output, validate that every reported violation includes a source_location (file path, line number, or endpoint-path + status code), a violation_type from your defined taxonomy, and a suggested_correction. Reject and retry outputs that fail schema validation or contain violations referencing endpoints not present in the input specs. Retry logic: If validation fails, re-invoke the prompt once with the validation errors appended as additional context. If the second attempt also fails, log the failure and escalate to a human reviewer rather than silently accepting a partial report.

Model choice and tool use: Use a model with strong structured output capabilities and a large context window (200K+ tokens) if you are auditing multiple services in a single run. For very large API surfaces, split the audit by service or domain and run parallel invocations, then merge the reports. This prompt does not require tool calling or RAG in its basic form, but you may extend it with a retrieval step that pulls your organization's error standards and style guide from an internal knowledge base to populate the [CONSTRAINTS] field automatically. Human review gate: For high-risk APIs (payments, auth, healthcare), always route the compliance report to a human reviewer before auto-opening tickets or blocking releases. The reviewer should confirm that suggested corrections do not introduce breaking changes and that severity classifications align with your SLA definitions. Logging: Log every invocation with the input specs version, the model version, the raw output, validation results, and the reviewer's disposition. This audit trail is essential for demonstrating API governance to compliance teams and for debugging model drift over time.