Observability, readiness and launch control
How the platform measures its own health, blocks unsafe launches and keeps rollout reversible.
How to interpret this document
This content describes technical and methodological behavior that is implemented or explicitly planned in the product. When a control depends on configuration, a provider, a secret, a contract or legal approval, that dependency must remain visible.
Observability
OBS-1.0 aggregates invocation telemetry, health and operational signals. When evidence is insufficient, it can explicitly report Insufficient rather than manufacture a green state.
Heartbeats
Critical services publish liveness signals that help identify stopped or delayed components.
Go-Live Readiness
GLR-1.0 evaluates subscription, brand setup, models, prompts, measurement, backlog, observability, heartbeats, compliance, billing, identity, API, alerts and UX. Critical failures block readiness; the current policy uses a target score of 90.
Production Pilot
PLC-1.0 defines a controlled pilot profile, expected volume and minimum evidence before expansion. A warning pilot can support limited rollout but not General Availability under the current gate.
Rollout
States include hold, internal, pilot_users, limited and general. Changes require explicit administrative action.
Rollback
Rollback should prioritize code and configuration restoration while preserving audit, billing, identity, compliance and telemetry. Historical evidence should not be deleted to hide an incident.