Define service level objectives and an error budget

# Role
You help engineering teams set service level objectives that match what users need and what the service can really do, and turn them into an error budget the team and its stakeholders agree to follow.

# Goal
Define service level indicators, objectives and an error budget policy for {{service}}, for {{audience}} to agree on, so that the team has one shared answer to two questions: is the service reliable enough, and when does reliability work come before features.

# Success criteria
- Each indicator is a ratio of good events to valid events, defined precisely enough to compute from the data sources we have.
- Each objective rests on our measured history and on what users need, and is below 100%.
- The policy says what happens as the budget is spent, who decides, and when it is reviewed.

# Constraints
- Use only the history and data sources below. Do not invent past performance.
- Keep objectives (internal targets) apart from any SLA (a contractual promise to customers); an objective should be stricter than the SLA it protects.
- Do not exclude planned maintenance or a dependency's failures from the indicators unless our rules below say so.

# Output
1. Indicators: a table with the columns User flow, Indicator, Good event, Valid event, Data source. For example: "Checkout | availability | response not 5xx and under 800 ms | all checkout requests except health checks | load balancer logs". That example shows the form only.
2. Objectives: a table with the columns Indicator, Target, Window, Why this level, with the history it rests on.
3. Error budget: for each objective, the budget as a share of requests and as minutes of full outage over the window, with the arithmetic (for example 99.9% over 30 days leaves 0.1%, or 43.2 minutes).
4. Alerting: burn-rate alerts on each objective, with at least one fast window that pages and one slow window that opens a ticket, showing how each threshold is calculated.
5. Error budget policy, in up to 8 numbered rules: what happens at 50%, 75% and 100% of the budget spent, who can grant exceptions, and how incidents caused by a dependency are counted.
6. How often the objectives are reviewed, and what would make us change them.

Keep the whole answer under 1,000 words, not counting tables.

# Stop rules
If we have only a few weeks of history or less, give provisional targets marked "provisional" and say what to measure first. If the data sources cannot tell good events from bad, for example because there is no latency data, say which indicator cannot be measured yet instead of defining it anyway.

# Context
What the service does and who depends on it: {{service_description}}
Key user flows: {{user_flows}}

History (availability, latency percentiles, error rates, incidents) and the period it covers:
"""
{{history}}
"""

Data sources we have: {{data_sources}}
Customer SLAs or contracts, if any: {{slas}}
Our rules on maintenance and dependencies: {{rules}}