Service Level Objective Boundary Assignment Prompt

This prompt is for SREs, platform engineers, and architects who need to allocate Service Level Objectives (SLOs) across a chain of dependent services. It takes a dependency graph, a user-facing SLO target, and per-service SLI data, then produces an SLO allocation map with latency budgets, error budgets, and blast radius containment validation. Use it when you are designing SLOs for a new system, renegotiating error budgets after an architecture change, or auditing whether current allocations can actually meet the top-level objective.

The prompt requires structured inputs: a directed acyclic graph of service dependencies, the top-level SLO target (e.g., 99.95% availability), and measured or estimated SLI data for each service including latency distributions and error rates. It works best when you have real production data or load-test results. The output is a concrete allocation map that assigns each service a latency budget, an error budget, and a criticality tier. It also validates whether the allocation respects the dependency chain's mathematical constraints—if a downstream service depends on three upstream services each with 99.9% availability, the combined availability cannot exceed 99.7% without redundancy. The prompt flags these constraint violations explicitly.

Do not use this prompt for real-time incident response or for systems where you lack measured SLI data. It is a design-time analysis tool, not a runbook replacement. The allocations it produces are only as good as the input data; garbage SLI estimates produce garbage SLO allocations. For high-stakes production systems, always validate the output against actual telemetry and have a human SRE review the allocation map before codifying it in error budget policies. If your dependency graph contains cycles or the system uses dynamic routing that changes the dependency topology at runtime, this prompt's static analysis approach will produce misleading results—you need a simulation-based approach instead.

This prompt template is designed to be pasted directly into your AI workspace. It accepts a service dependency graph, baseline performance data, and business criticality tiers as input. The model will produce a structured SLO allocation map that assigns latency budgets, error budgets, and SLI aggregation rules to each service boundary. The output is intended for SREs and architects who need to translate high-level reliability targets into per-service operational contracts, ensuring that no single service consumes a disproportionate share of the overall error budget.

textCopy
You are an SRE architect assigning Service Level Objectives across a distributed system. Your task is to produce an SLO allocation map that distributes latency budgets, error budgets, and availability targets across service boundaries while respecting dependency chains and blast radius constraints.

## INPUT
[INPUT]

## CONTEXT
- Overall system SLO target: [SYSTEM_SLO_TARGET]
- Business criticality tiers: [CRITICALITY_TIERS]
- Dependency graph (services and their call paths): [DEPENDENCY_GRAPH]
- Baseline performance data per service (p50/p95/p99 latency, error rate, availability): [BASELINE_DATA]
- Budget buffer policy (percentage reserved for unallocated risk): [BUDGET_BUFFER_POLICY]

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT_SCHEMA
[OUTPUT_SCHEMA]

## INSTRUCTIONS
1. Parse the dependency graph to identify critical paths and fan-out dependencies. Services on critical paths with no redundancy receive tighter budgets. Services with parallel instances or fallbacks can receive looser budgets.
2. For each service, assign:
   - Latency budget (p95 target in milliseconds, derived from end-to-end latency SLO minus upstream and downstream budgets)
   - Error budget (percentage of total error budget allocated, must sum to <= 100% minus buffer)
   - Availability target (e.g., 99.9%, 99.95%, 99.99%)
   - SLI measurement point (which metric, at which boundary, measured how)
3. For each dependency chain, calculate the aggregated SLI and verify it meets the overall system SLO. Flag any chain where the sum of budgets exceeds the system target.
4. Identify blast radius containment boundaries: services whose failure should not cascade. Assign isolation budgets and circuit-breaker thresholds.
5. For cross-service SLI aggregation, specify the aggregation rule (e.g., AND for serial dependencies, weighted average for parallel fan-out, min for redundant paths).
6. Flag any service where the assigned budget is tighter than current baseline performance. Mark these as requiring remediation before the SLO can be adopted.
7. If [RISK_LEVEL] is "high" or "critical", include a human review checklist and rollback conditions for each budget assignment.

## OUTPUT FORMAT
Return a JSON object matching the output schema exactly. Do not include commentary outside the JSON.

## EXAMPLES
[EXAMPLES]

To adapt this prompt, replace each square-bracket placeholder with your system's actual data. The [INPUT] field should contain a structured description of the services, their dependencies, and any existing SLOs. The [OUTPUT_SCHEMA] should define the exact JSON shape you expect—include fields for service name, latency budget, error budget, availability target, SLI definition, aggregation rule, and remediation flags. The [CONSTRAINTS] field is where you specify hard rules such as "no single service may consume more than 30% of the total error budget" or "all latency budgets must be validated against p95 baseline data." The [EXAMPLES] field should contain one or two worked examples showing correct budget allocation for a simple dependency chain, which dramatically improves output quality. After generating the allocation map, validate that all error budget percentages sum correctly and that no dependency chain's aggregated latency exceeds the system SLO. For production use, always run the output through a schema validator and a budget-sum checker before applying it to monitoring systems.

This prompt is not a one-shot generator. It is a structured analysis tool that should be embedded in a pipeline where input data is validated before the prompt runs and output data is validated before it reaches a dashboard or alerting system. The prompt expects a service dependency graph, per-service SLI definitions, and a target aggregate SLO. In practice, wire this into an SRE toolchain that pulls topology from a service registry (e.g., Kubernetes labels, Consul, or an internal CMDB) and SLI definitions from an observability platform (e.g., Prometheus recording rules, Datadog SLOs, or a reliability spreadsheet). The prompt itself should be called with a model that supports structured output, such as GPT-4o or Claude 3.5 Sonnet, using a JSON schema constraint that matches the expected SLO allocation map format.

Validation and retry logic is critical here because an incorrect SLO allocation can cause teams to burn error budget on the wrong service or miss a dependency that silently consumes latency budget. Before calling the prompt, validate that the dependency graph is acyclic (or flag cycles explicitly in [CONTEXT]) and that every service in the graph has at least one SLI defined. After the prompt returns, run a validator that checks: (1) the sum of latency budgets along each critical path does not exceed the aggregate SLO target, (2) every service in the input graph appears in the output allocation map, (3) no service is assigned a budget tighter than its historical performance can support (compare against a 30-day p99 baseline), and (4) blast radius containment rules are satisfied—no single service failure should cascade budget exhaustion to more than [BLAST_RADIUS_LIMIT] downstream services. If validation fails, retry once with the validator's error messages appended to [CONSTRAINTS]. If the second attempt fails, escalate to a human reviewer with the partial output and failure reasons.

Logging and audit should capture the full prompt input, output, validator results, and any human overrides. Store these in an immutable audit log (e.g., a versioned S3 bucket or an internal reliability database) so that SLO allocation decisions are traceable during incident reviews. For high-risk production systems, add a human approval gate: the prompt's output should be rendered as a diff against the current SLO allocation, and an on-call SRE or reliability architect must approve the change before it is applied to monitoring dashboards or alerting thresholds. Never auto-apply SLO changes without human review when the system handles revenue, safety, or regulated data. The prompt is a reasoning accelerator, not a replacement for engineering judgment about where error budget should be spent.