Control
Fallback model or provider path skips the safeguards of the primary path
When the primary model or provider fails, times out or is rate-limited, the fallback path (another provider, a smaller model, a retry with a different prompt, a cached or canned answer) applies the same system prompt, moderation, data screening, disclosures and tool restrictions as the primary path, and is tested as part of the release.
Informational data, not legal advice. Summaries and rules have not been reviewed by a lawyer: always verify official law text for decisions. A suggested guard is intended to address each rule; adding it is not a statement of compliance to that law.
Reach
Trust and provenance
How far the rules this guard addresses have been checked. Each rule links to its provision, with its citation, official text and its own panel.
- This control
- Audit-grade: meets all 3 checks of the TwinEthos audit standard that apply to it.
- Lanes
- TwinEthos recommendation (not law) 1
- Data release
- Data release 2026.10.03.4, data as of 3 Oct 2026, schema 0.3.10. This page also reflects corpus changes made after that release; they ship in the next one.
- Legal review
- None of the 1 rule has been reviewed by a lawyer; no TwinEthos rule has been legally reviewed yet. Treat each as research to check against the official text; it is not legal advice.
- Audit standard
- 1 of 1 rule audit-grade. The audit standard is TwinEthos's own quality bar for provenance, dates, applicability, detectors, fixtures, remediation and licences; it is not a legal review.
- Detectors
- 1 detector, all experimental: written from the rule's text and not yet measured for precision on real code, so treat a hit as a lead to verify. Each provision lists its detectors' known limits.
The guard to add
Apply the same moderation, screening, disclosures and tool limits on the fallback path as on the primary path.
Put the safeguards in one place that every path passes through: a wrapper around the model call, or guard calls applied after the try/except to whichever result came back, so the primary call, the fallback provider, the smaller model and any cached or canned answer all go through the same moderation, PII screening, disclosure and tool-allowlist code. Configure fallback models (LiteLLM Router fallbacks, provider failover) with the same system prompt, tools and guardrail settings, and add a test that forces the fallback and asserts the safeguards ran.
Where it goes: 1 application source code, 8 model configuration, 9 AI output handling.
What reviewers look for: no except or catch branch that calls a second model and returns its output without the guard calls the try branch used; a shared wrapper or post-call guard; a fallback test.
Example (Python + two providers), before:
try:
reply = primary.chat.completions.create(model=M, messages=msgs).choices[0].message.content
reply = moderate(reply)
except openai.APIError:
reply = backup.messages.create(model=B, max_tokens=800, messages=msgs).content[0].text
return replyAfter:
try:
reply = primary.chat.completions.create(model=M, messages=msgs).choices[0].message.content
except openai.APIError:
reply = backup.messages.create(model=B, max_tokens=800, system=SYSTEM, messages=msgs).content[0].text
return moderate(reply) # the same guard on whichever path answeredEngineering guidance, not legal advice. Each provision below may add its own details (a cadence, a deadline, a required notice element): open it for those.
Every rule this guard addresses
TwinEthos recommendation (not law) (1)
- Everywhere (*)
- Keep the same guardrails on every fallback model or provider path TwinEthos derivation — guardrail.opint-fallback-keeps-guardrails
Informational data, not legal advice. Summaries are TwinEthos's own words and rules have not been reviewed by a lawyer: check the official text before relying on any of it. A guard addresses an item; adding it is not a statement that your code meets any law.