LAYER · VALIDATE · ACTIVATE
Dynamic reload: keep the complete last-good revision
Edit real JSON layers. Trace each winning value and compare the candidate with the configuration that is actually active.
Scroll the diagram horizontally to compare candidate and active values. The table below gives the same fields as text.
Edit candidate layers
Use synthetic values only. Do not paste credentials. Request overrides allow only timeoutMs, maxTokens and temperature.
Validation report
Your experiment
Revision 1 is serving. Load the retry-budget example in reload mode: compare the rejected candidate with the unchanged active revision. Then restore the valid example and watch one atomic switch to revision 2; finally try the same failure in startup mode.
Explicit teaching schema
timeoutMs: integer 50–60,000; maxTokens: integer 1–8,192; temperature: number 0–2; retries: integer 0–5. timeoutMs × (retries + 1) must not exceed 90,000 ms. Model: atlas-lite or atlas-pro. Secret reference: fixture:team-a:v1/v2 or fixture:team-b:v1/v2, matching the selected tenant.
Defaults apply first and request overrides last. The middle layers use the selected precedence. All fields are validated, even when a later layer would overwrite them. A rejected candidate changes nothing in the active revision.
Value provenance and active revision
| Field | Candidate value | Winning source | Currently active value |
|---|
Applied-field history
Offline teaching model, not an ADK/Gemini configuration API or a security boundary. Precedence, validation ranges, allowed keys and retry budget are explicit lesson policies. Environment JSON is manually entered: this page never reads process environment variables. Secret references resolve to synthetic metadata; there are no secret values, network requests, cloud credentials or real IAM checks. Unknown fields, invalid types, forbidden request overrides and failed bindings reject the complete candidate. Production reload semantics depend on the application and must be tested separately. Configuration separation · Secret-reference and version guidance.
Reload builds a complete candidate first
In Reload mode revision 1 is already serving: timeoutMs 1000, maxTokens 256, temperature 0.7, retries 2, model atlas-lite. A reload assembles a new candidate from defaults, environment, tenant and request layers, validates every field and the cross-field retry budget, binds its secret reference, which must belong to the Fixture tenant, and only then swaps the whole candidate in. Until the swap the active revision is untouched, and the provenance table shows candidate and active values side by side.
The opening reload switches once
With the valid example the candidate takes timeoutMs 2500 from the environment, maxTokens 1024 from the tenant, temperature 0.2 from the request, and activates as revision 2 at 49 inspection seconds: every changed field switches at the same moment. Change Middle-layer precedence to Tenant then environment and the environment’s maxTokens 512 wins instead of the tenant’s 1024, still in one switch.
An invalid reload keeps the last good revision
Use Load a complete example to load Retry budget too large: the tenant layer sets timeoutMs 60000 and retries 5. Each field is individually valid, but the worst-case retry time is 60000 x 6 = 360,000 ms, above the 90,000 ms limit, so validation rejects the candidate and revision 1 keeps serving all of its old values. The Invalid environment string example (timeoutMs given as 5 seconds) is rejected the same way. Restore valid example and the next reload switches cleanly to revision 2.
Startup has nothing to fall back to
Choose Startup as Activation mode and load the retry-budget example again. There is no previous revision, so the application stays stopped rather than starting with a partly valid configuration. The same holds for secret failures: with Synthetic pinned version set to Runtime identity denied, reload keeps revision 1 and startup stays blocked. Fail-closed startup and last-good reload are two answers to the same rule: never run a configuration that did not pass every check.
Reading the run and its limits
Play, Next stage, Restart inspection, Speed and Inspection time step through the eight phases over 49 inspection seconds; the canvas and the provenance table give the same candidate, sources and active revision. Each experiment is one reload of a fixed revision 1, not a persistent server: there are no in-flight requests pinned to the old revision, no file watchers and no distributed rollout of configuration.