Platform Component Routing Prompt

This prompt is designed for infrastructure and platform engineering teams that need to automatically route incoming issues, questions, or requests to the correct component owner. It maps unstructured text to a defined taxonomy of platform services, databases, message queues, and infrastructure layers. Use this when your team owns a multi-component platform and manual triage is creating bottlenecks, misroutes, or delayed responses. The prompt assumes you have a stable component catalog with clear ownership boundaries. It is not suitable for routing end-user product feature requests or for platforms where component boundaries are undefined or constantly shifting.

Before deploying this prompt, you must have a well-defined and version-controlled component taxonomy. Each entry should include a canonical component name, a clear description of its boundaries, and an assigned owner or on-call rotation. The prompt works best when your component catalog is treated as a configuration artifact that can be updated independently of the prompt itself. If your platform has components with overlapping responsibilities—for example, a shared message queue used by multiple services—you need to define explicit routing precedence rules. Without these rules, the model will make arbitrary choices that create inconsistent routing and frustrate downstream owners.

Do not use this prompt as a general-purpose classifier for non-infrastructure domains. It will perform poorly on product feature requests, billing inquiries, or HR questions because its taxonomy is scoped to platform components. If you need to route across broader organizational boundaries, start with a top-level domain classifier from the Domain and Topic Categorization pillar before dispatching to this component-level prompt. For high-severity incidents where misrouting could delay a critical response, always include a human-in-the-loop escalation path that bypasses automated classification entirely.

This prompt template is designed to be pasted directly into your system prompt or classification step. It takes an unstructured infrastructure issue or question and maps it to a specific platform component—such as a database, message queue, or compute service—along with the responsible team. The template uses square-bracket placeholders that you must populate before each call with your current service catalog, ownership map, and any routing constraints. Do not leave placeholders unresolved in production; missing context will cause misrouting and silent failures.

textCopy
You are a platform component router for an infrastructure engineering organization.
Your job is to analyze the incoming issue or question and determine which platform component it relates to.

## INPUT
[INPUT]

## SERVICE CATALOG
[SERVICE_CATALOG]

## OWNERSHIP MAP
[OWNERSHIP_MAP]

## ROUTING RULES
[ROUTING_RULES]

## OUTPUT SCHEMA
Return a valid JSON object with exactly these fields:
{
  "component_id": "string (canonical component identifier from the service catalog)",
  "component_name": "string (human-readable component name)",
  "owner_team": "string (team name from the ownership map)",
  "confidence": "number (0.0 to 1.0)",
  "reasoning": "string (brief explanation of why this component was selected)",
  "alternative_components": [
    {
      "component_id": "string",
      "component_name": "string",
      "confidence": "number"
    }
  ],
  "requires_escalation": "boolean (true if confidence is below 0.7 or multiple components have similar scores)",
  "escalation_reason": "string or null (explain why escalation is needed if applicable)"
}

## CONSTRAINTS
- If the input does not clearly map to any component in the service catalog, set component_id to "UNKNOWN" and confidence to 0.0.
- If the input spans multiple components, select the primary one and list others in alternative_components.
- Do not invent component names or teams not present in the service catalog or ownership map.
- If confidence is below 0.7, set requires_escalation to true and provide a clear escalation_reason.
- For inputs mentioning security vulnerabilities, data loss, or outages, always set requires_escalation to true regardless of confidence.

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, start by populating [SERVICE_CATALOG] with a structured list of your platform components—include canonical IDs, names, descriptions, and any aliases or common shorthand terms your teams use. The [OWNERSHIP_MAP] should link each component ID to a specific team name and, optionally, an on-call rotation or escalation contact. [ROUTING_RULES] captures any business logic that overrides pure semantic matching, such as "all database performance issues route to the DBA team regardless of the specific database service." The [EXAMPLES] placeholder should contain 3–5 few-shot examples covering clear-cut routing, multi-component ambiguity, and out-of-scope rejection. Set [RISK_LEVEL] to "low," "medium," or "high" to adjust the model's caution; high-risk environments should bias toward escalation. Before deploying, validate that every component in your service catalog appears in the ownership map and that your examples cover at least one edge case where confidence should be low.

After pasting this template into your classification step, test it against a golden dataset of 50–100 labeled infrastructure issues before production use. Measure component-level precision and recall, and pay special attention to false positives where an issue is confidently routed to the wrong team—these are more damaging than low-confidence escalations. If your platform adds or deprecates components, update the service catalog and ownership map immediately; stale routing tables are the most common failure mode in production. For high-severity incidents, pair this prompt with a human-in-the-loop approval step that reviews any classification where requires_escalation is true or confidence is below your operational threshold.

The Platform Component Routing Prompt is designed to sit behind an API endpoint or message queue consumer that receives unstructured infrastructure issues, questions, or alerts. The application layer is responsible for assembling the prompt with the correct [INPUT], [COMPONENT_CATALOG], and [ROUTING_RULES] before invoking the model. The model's output—a JSON object containing the assigned component, confidence score, and routing rationale—must be validated before any downstream dispatch occurs. This is not a fire-and-forget prompt; incorrect routing can send a database outage alert to the message queue team, delaying incident response and breaking on-call contracts.

Build the harness with four mandatory stages: pre-validation, model invocation, post-validation, and dispatch with fallback. Pre-validation checks that the [INPUT] is non-empty, within length limits, and does not contain prompt injection patterns before the model sees it. Model invocation should use a low-temperature setting (0.0–0.2) for deterministic routing and include a response_format constraint matching the expected [OUTPUT_SCHEMA]. Post-validation must confirm the returned component exists in the [COMPONENT_CATALOG], the confidence score exceeds your configured threshold (start at 0.80 and tune based on eval results), and the rationale field is non-empty. If validation fails, implement a single retry with the same input; if it fails again, route to a human triage queue rather than guessing. Log every routing decision with the input hash, assigned component, confidence, rationale, and whether the route was automatic or escalated. This log becomes your audit trail for ownership disputes and model drift detection.

For high-reliability environments, add an ownership verification step after routing. Before dispatching an alert or ticket, query your service catalog or on-call rotation to confirm the assigned component has an active owner. If the component exists in the catalog but has no current on-call responder, escalate to the platform engineering lead rather than silently dropping the request. This prevents the common failure mode where the model routes correctly to a deprecated or unowned component. Wire the dispatch action through your existing incident management or ticketing API, not through the model. The model's job ends at classification; the application owns the side effects. Start with a shadow mode deployment where routing decisions are logged but not acted upon for at least one week, comparing model-assigned components against human-routed baselines before cutting over to automated dispatch.