Configuration lifecycle¶
Mission Control combines reviewed configuration files with live administrative state. Knowing which one owns a setting tells you where to change it and when the change takes effect.
File configuration defines the available system¶
Global and Organization YAML define providers, virtual models, Connectors, declared tools and other configured policy. Environment variables supply service settings and referenced static secrets. Gateway and Console prepare and validate their configuration at startup.
Each process keeps that configuration view until restart. Unknown fields, invalid references or missing required secrets prevent startup. Validation does not prove an upstream account works: it performs no business call or OAuth consent.
Use the configuration check and restart procedure after a file or static-secret change. Coordinate gateway and Console so they load the intended files and environment.
Live state governs current access¶
| Change | How it takes effect |
|---|---|
| Human roles, Team allowance, key policy or status | Next current-authority check; no service restart |
| Budget or operating cap | Next applicable admission check; existing work still settles |
| Key secret rotation | Clients must reload the replacement secret; logical key history remains |
| Agent draft | Becomes an immutable snapshot when saved; Live stays on its published version |
| Agent publication | Deployment switches to the reviewed version without an application restart |
| Provider route, static credential or YAML guardrail assignment | Coordinated gateway/Console restart |
| OAuth connection | Its credential lifecycle; changed incompatible configuration can invalidate the grant |
A new catalog entry does not automatically expand every Team or selected key. Followed tool sets and inherited Team policies have their own documented behavior.
Configuration evidence explains a past request¶
A request records the configuration hash that applied when it was admitted. Historical configuration evidence is redacted and separately permissioned. It helps explain a past decision; it never replaces current authority or silently becomes the live configuration.
In-flight work keeps its acquired configuration view. A later independent request uses the currently loaded configuration and current access. This matters during a provider change or multi-instance rollout.
See Organization YAML, environment variables, review configuration, and upgrade and rollback.