MODEL SETTINGS · VALIDATE, THEN ACTIVATE
Model settings: validate a candidate before activation
Push a candidate model configuration with one defect through schema, catalog and probe checks, and see what happens to live traffic when a check is missing.
Your experiment
The candidate changes the model, temperature and output token limit. Start with a model id typo, schema-only validation and an in-place edit, then add the catalog and probe checks, try each defect and compare activation styles.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, Speed changes the pace and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Fictional model ids, limits and traffic (100 requests per minute). The field names follow Gemini generation settings, but the 65,536-token limit is a fixture value, not a statement about any real model; check the provider’s current model documentation. A broken active configuration fails every request until someone rolls back.
A typo that schemas cannot see
The live configuration uses model chat-model-v1 with temperature 0.7 and an 8,192-token output limit. The candidate changes all three, but its model id has a typo, chat-model-lateset. Schema validation checks types and ranges, and a misspelled string is still a string, so the candidate passes. With Edit the live config field by field the model id is written first and every request then fails: MIXED CONFIG LIVE with 500 failed requests in the first five minutes, and the live values now match neither the old nor the new version.
Check the catalog before activating
Set Validation before activation to Schema and model catalog: the catalog has no such model, the candidate is rejected and the previous configuration keeps serving: REJECTED BEFORE ACTIVATION with 0 failed requests. Output token limit above the model limit is also a catalog failure, 100,000 against the fixture limit of 65,536. Temperature written as a string is the one defect schema-only validation catches by itself.
Some defects only show up in a real call
As the Defect in the candidate, Model not served in this region passes the schema and the catalog: the model exists and the numbers are valid, but the deployment region cannot serve it. Only Schema, catalog and a probe request rejects it, by sending one request from the serving region before switching. A probe costs one request and a few hundred milliseconds; skipping it costs the 500 failures.
Atomic swaps make rollback possible
With validation set to None, compare activations. Swap the whole config atomically still puts a broken configuration live, BROKEN CONFIG LIVE, but the previous version is intact and a rollback is a single swap back. The in-place edit leaves a mix of new and old fields with no known-good version to restore. Validate the whole candidate first, then switch versions as one unit.
Reading the run and its limits
Play, Next event, Restart, Speed and Inspection time step through the candidate, each validation stage, activation and serving across sixty seconds; the table records which stage rejected the candidate. Model ids, limits and the region rule are fictional fixtures. Real model settings also include safety thresholds and thinking budgets whose valid values depend on the model; check them against the provider’s current documentation before relying on any number here.