Operator Workflow
Operator Workflow
Section titled “Operator Workflow”Operators own the running gateway path after a capability is approved. The workflow is to prove the control plane, data planes, connectors, sessions, telemetry, audit, and release posture are healthy without reading databases or copying private payloads.
Audience
Section titled “Audience”- Operators running the gateway day to day.
- Platform engineers checking data-plane projection and connector health.
- Security operators using emergency disable, revoke, and audit export paths.
- Release owners building a metadata-only handoff packet.
What is this?
Section titled “What is this?”This page is the public operations loop for V1. It starts from governed MCP behavior: approved projections reach data planes, calls evaluate Cedar policy, credential bindings resolve through the broker, private routes stay registered, sessions are explicit state, and audit remains metadata-only.
When do I use it?
Section titled “When do I use it?”Use it for daily baseline checks, incident triage, release-candidate handoff, or any question that starts with “is the gateway path healthy?” If the issue is a single symptom, move to Troubleshooting after the baseline.
What happens?
Section titled “What happens?”- Confirm the current branch, docs gate, deployment status, data-plane status, and audit export readiness.
- Check projection freshness before assuming a source, policy, or connector change has reached runtime.
- Review connector health and private-route availability before upstream traffic leaves the gateway.
- Review active sessions before drain, terminate, revoke, or upgrade work.
- Confirm telemetry and SIEM/export destinations are disabled, local, or customer-managed with metadata-only redaction.
- Record a handoff packet with command, result, reason code, safe resource IDs, redaction status, and V1 boundary notes.
Runtime checks
Section titled “Runtime checks”| Surface | Operator check | Fail-closed action |
|---|---|---|
| Deployment | deployment_status_ok from the status workflow | Keep rollout blocked until required integration refs validate. |
| Data planes | health, policy sync, config propagation, active-session counts | Block drain/upgrade when detail says readiness is blocked. |
| Connectors | lifecycle, approval, health, route availability, impact | Disable or revoke before allowing ambiguous private routing. |
| Sessions | active, reconnecting, draining, terminated, revoked, expired, failed | Reject new stateful sessions during drain and revoke affected sessions when needed. |
| Telemetry/SIEM | mode, delivery status, redaction, allowed actions | Preserve local audit metadata when export is denied or unsafe. |
| License/settings | safe read-model metadata and allowed capabilities | Mark behavior needs-source before documenting exact UI effects. |
What can go wrong?
Section titled “What can go wrong?”- Operators work around missing integration state by querying production databases. Normal V1 operations should use Admin API, CLI, or harness checks.
- A stale data-plane projection makes a policy or approval change look ineffective.
- Connector lifecycle state is treated as advisory even though disabled and revoked states block routes.
- Drain starts while active sessions are not tracked in PostgreSQL and Valkey.
- Telemetry, audit export, or a handoff packet includes secrets, prompts, request bodies, response bodies, tool payloads, or customer data.
- A requested recovery path depends on a Kubernetes operator, Terraform module, ClickHouse, NATS, Kafka, Redpanda, or managed MCP hosting. Those are not V1 defaults.
Source truth
Section titled “Source truth”- Read Connectors and Private Routing before changing private connectivity state.
- Read Sessions and Revocation before drain, terminate, or revoke work.
- Read Release Evidence before release-candidate handoff.
Type set in Geist, Source Serif 4, and Departure Mono.