> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pylva.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Controls Workflow

> Roll out Pylva cost and reliability controls safely after telemetry is trusted.

Pylva controls should start as visibility, then alerts, then enforcement.

Use controls after telemetry is flowing and the dashboard shows the customer, step, pricing, and event data you expect.

## Choose the right control

| Need                           | Use                    | Behavior                                                                         |
| ------------------------------ | ---------------------- | -------------------------------------------------------------------------------- |
| Know when spend crosses a line | Cost threshold         | Post-call alert after usage is recorded.                                         |
| Warn on budget risk            | Budget limit warn      | The call proceeds, and Pylva records or alerts on spend.                         |
| Cap customer usage             | Budget limit hard stop | The SDK blocks before the provider call when an active cached rule applies.      |
| Steer a narrow model path      | Model routing          | Advanced pre-call model or provider steering.                                    |
| Recover from provider trouble  | Reliability failover   | Advanced pre-call reliability control that requires explicit cost-shift consent. |
| Find margin risk               | Margin protection      | Scheduled analysis and recommendations.                                          |

Use budget hard stops to cap customer usage; `customer_throttle` is not a supported public rule type.

## Rollout path

1. Confirm telemetry is trusted: customer, step, pricing, and dashboard events are visible.
2. Start with alert-only rules or warn mode before hard stops.
3. Use drafts for review before production activation.
4. Activate narrow scopes first: one customer, one step, or one model path.
5. Catch `PylvaBudgetExceeded` and return a product-specific fallback.
6. Monitor rule events, warnings, alerts, and budget behavior after activation.
7. Expand scope only after the narrow rollout behaves as expected.
8. Roll back by disabling the rule or moving it back to draft.

For how alerts reach your team or systems, see [Alert Delivery And Webhooks](alert-delivery-and-webhooks).

## Pre-call and post-call

Pre-call controls can block or steer a call before provider spend happens. Budget hard stops, model routing, and reliability failover are pre-call controls.

Post-call controls alert after usage is recorded. Cost thresholds and margin protection do not stop the provider call that already happened.

## Hard stops

Hard stops only block when the SDK has an active cached rule it can enforce safely.

When a hard stop fires, the SDK raises `PylvaBudgetExceeded`. Catch it and return a fallback such as a cached answer, smaller model path, queued job, "try again later" response, or human handoff.

Avoid retry loops that immediately reissue the same expensive call.

## Fail-open behavior

Pylva fails open when rule state, pricing, or backend access is unavailable, so Pylva does not become the reason your agent is down.

That means a call may proceed if the SDK does not have the active rule state needed to enforce safely. Review rule activation, SDK cache timing, and budget sync behavior when testing hard stops.