LAYER · VALIDATE · ACTIVATE
Configuration and secrets: bind before activation
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
The candidate is valid and binds its pinned synthetic secret reference, so revision 2 activates. Now deny the runtime identity access to that secret version, then load the cross-tenant and request-override examples: each candidate is rejected as a whole and no secret bytes are ever shown.
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.
A secret is a reference until binding
The candidate configuration has six typed fields, and one of them, secretRef, is a pinned reference such as fixture:team-a:v1 rather than a value. The pipeline merges defaults, the environment layer, the tenant layer and the request layer, validates every field and the retry budget, and only then binds the reference: it checks that the reference belongs to this tenant, that the pinned version is enabled and that the runtime identity may read it. Binding produces mock metadata; no secret bytes exist anywhere in the lesson.
The opening candidate binds and activates
With Fixture tenant set to Team A, Activation mode set to Reload and Load a complete example set to Valid candidate, the candidate takes timeoutMs 2500 from the environment, maxTokens 1024 from the tenant layer, temperature 0.2 from the request and secretRef fixture:team-a:v1 from the defaults. Validation passes at 35 inspection seconds, binding succeeds at 42 and revision 2 activates at 49. Switch Fixture tenant to Team B and the default reference becomes fixture:team-b:v1, which binds for Team B.
Binding failures reject the whole candidate
Set Synthetic pinned version to Runtime identity denied: every field still validates, but binding fails with the runtime identity denied secret access, and revision 1 keeps serving with all of its old values. Disabled version fails the same way. In Startup mode either failure leaves the application stopped instead, because there is no earlier revision to keep. A candidate is never activated with some fields new and a secret unresolved.
References that must never bind
Under Load a complete example, choose Cross-tenant reference: the tenant layer sets secretRef to fixture:team-b:v2. The format is valid, so validation passes, but binding rejects a secret belonging to another tenant. Choose Forbidden request override: a request tries to set secretRef, and validation rejects it before binding because request overrides may change only timeoutMs, maxTokens and temperature. Editing the Environment JSON, Tenant JSON and Request JSON boxes directly gives the same checks for your own candidates, and Restore valid example puts the opening candidate back.
Reading the run and its limits
Play, Next stage, Restart inspection, Speed and Inspection time step through start, the four layers, validation, binding and activation over 49 inspection seconds; Middle-layer precedence decides which of the environment and tenant layers wins a shared field, so Tenant → environment takes maxTokens 512 from the environment instead of 1024 from the tenant; the provenance table shows each field’s winning source and the active value. Secrets here are synthetic reference strings with three fixed states; real systems also need rotation, caching with expiry, audit of reads and least-privilege identities. Never paste real credentials into the boxes.