Skip to main content
The previous case study 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: 
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

{
  "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:
FallbackIf regeneration still cannot pass
logReturn the best attempt and record the outcome.
blockReject the reply (422) and hand off.
human_reviewReject 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.

Safe Regeneration

How the evaluate-and-rewrite loop works.

Governing a support chatbot

The first half of this story: catching the failing reply.