Skip to main content
Every AI capability in ChangeGuard AI reaches Amazon Bedrock through one router in the control plane. Nothing about judgment depends on it: SHIP / HOLD / BLOCK, the CSC Score, Permits, execution and verification make no model call.

The models

The fallback is a permanent part of the architecture. It stays configured, permitted, tested and monitored whether or not the preferred model is available; recovery of the preferred model never removes it. It was selected from a 30-scenario evaluation against Amazon Nova Pro using ChangeGuard AI’s production prompts and validators (76 real calls per model); it serves only the operations it passed: the Engineering Opinion (with Reasoning and Experience), root-cause analysis, @changeguard-ai replies, incident summaries and change predictions. Requests are processed in the United States: the US inference profile may route a request to any of the three Regions listed. Amazon Bedrock does not share prompts or outputs with model providers, and neither AWS nor the providers use them to train models. ChangeGuard AI has not enabled Bedrock model-invocation logging.

How failover works

  1. The preferred model is tried first.
  2. Only an access or availability failure moves the request to the fallback: access denied, throttled, service unavailable, a timeout, or the preferred model’s circuit being open after such failures. At most one fallback attempt per request.
  3. An answer is never second-guessed. A read you may not like is not a reason to ask another model, and a request the model rejected or a filtered or empty answer is not retried elsewhere.
  4. A circuit breaker opens after repeated availability failures and probes the preferred model by itself; when it answers again, it serves again. Recovery needs no action from anyone.
Operations that were not part of the evaluation have no fallback and fail closed while the preferred model is unavailable: Ask ChangeGuard, the weekly digest, the AI paragraph under pre-flight and validation verdicts (the verdict itself is unaffected), and the drafting of workload patches, which stays on the preferred model by policy.

What you see

Provenance in the record

Every AI result and its audit row record the model that answered, its provider and role (primary or fallback), why the fallback was used, the prompt version, token usage, latency, a correlation id and the Bedrock request ids. Customers read plain words and a reference; the provider’s own error text stays in ChangeGuard AI’s operational logs. Prompts are never logged.

Verified in production

The failover was exercised against real Amazon Bedrock on 9 November 2026 with the production configuration: the preferred model refused for the account, every approved operation answered by the fallback and passing the production validators, and a real both-models-down run reading as unavailable. The production acceptance that day formed an Engineering Opinion on the fallback, persisted it, audited it with the router’s provenance and showed it in the product with the line above. Details and evidence are in the release notes: Engineering intelligence GA release.