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

# Case study: auto-fixing low-scoring replies

> How safe regeneration turns a reply that fails the policy into one that passes, with the real before-and-after.

The [previous case study](/use-cases/support-chatbot-governance) showed a dismissive support reply being caught and blocked. Blocking protects the customer, but it leaves the support agent with nothing to send. **Safe regeneration** closes that gap: instead of just rejecting a failing reply, it rewrites and re-scores it until it clears the threshold.

This walkthrough uses real output from `POST /railscore/v1/safe-regenerate`.

## The failing reply

The same dismissive reply from the support assistant, which scored **5.5** in deep mode:

> "That's not our problem, the charge is final. You probably forgot you bought it. We don't do refunds after 24 hours, so there's nothing I can do. Maybe read the terms next time."

## One call to fix it

Rather than score, reject, and re-prompt by hand, the team sends it to safe regeneration with their threshold:

```bash theme={null}
curl -X POST https://api.responsibleailabs.ai/railscore/v1/safe-regenerate \
  -H "Authorization: Bearer YOUR_RAIL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "That'\''s not our problem, the charge is final. ...",
    "mode": "basic",
    "threshold": 7.5,
    "max_regenerations": 3
  }'
```

RAIL evaluates the reply, rewrites it with targeted improvement guidance, and scores the new version, repeating until it passes or the iteration limit is reached.

## The result

```json theme={null}
{
  "result": {
    "status": "passed",
    "best_scores": { "rail_score": { "score": 7.6 } },
    "best_content": "We understand you're inquiring about a recent charge. Our policy states that purchases become final after 24 hours, and unfortunately we are unable to process refunds beyond that period. We encourage reviewing the full terms at the time of purchase, and we're happy to help with anything else."
  }
}
```

`status: passed` — the rewrite scored **7.6**, up from 5.5. Same policy position (refund declined), but now delivered with empathy, clarity, and ownership. That is the version the customer receives.

## Tying it to the policy

You do not have to call this endpoint by hand. When an application's policy uses `enforcement: "regenerate"`, a reply that fails the threshold on `/eval` is routed through this same flow automatically, and the policy's `fallback` decides what happens if even the best rewrite still falls short:

| Fallback       | If regeneration still cannot pass               |
| -------------- | ----------------------------------------------- |
| `log`          | Return the best attempt and record the outcome. |
| `block`        | Reject the reply (`422`) and hand off.          |
| `human_review` | Reject and flag for a person to handle.         |

So a single policy setting turns "catch bad replies" into "catch and fix bad replies," with a safety net for the rare case that cannot be salvaged.

<CardGroup cols={2}>
  <Card title="Safe Regeneration" icon="rotate" href="/concepts/safe-regeneration">
    How the evaluate-and-rewrite loop works.
  </Card>

  <Card title="Governing a support chatbot" icon="headset" href="/use-cases/support-chatbot-governance">
    The first half of this story: catching the failing reply.
  </Card>
</CardGroup>