Reliability and Failure Semantics

Target architecture — not the current operating contract

This page includes reliability contracts for future modules. For implemented recovery behavior, see Operations.

The current release propagates request, W3C Trace/Span, Organization, Team, key and owner, deployment and managed execution, optional Session and customer, and idempotency identities. It does not allocate, open, finalize, or recover a Mission Control Run resource. The Run identifier below is a future target-layer concept.

Mission Control treats control and evidence guarantees as part of successful execution. Availability measures do not justify bypassing identity, policy, approval, version, or evidence controls.

Identifier contract

Every request carries or receives:

Identifier	Purpose
Request identifier	Uniquely identifies one API or gateway request and its attempts
Run identifier	Correlates the top-level execution across applications, agents, Workflows, gateways, policy, evaluations, costs, and outcomes
Trace and span identifiers	Preserve causal order and parent-child relationships inside the Run
Resource identity and applicable managed-version identifiers	Identify the Agent/environment/key/Run authority and any Mission-Control-managed release selected for execution
Principal and environment identifiers	Bind execution to the acting human or workload and its security scope
Idempotency key	Gives a stable business-operation identity for duplicate suppression and safe resumption
Business correlation identifier	Links execution to a customer business object without copying its unrestricted payload

Identifiers propagate across process and network boundaries. A component may add local attempt or task identifiers, but it cannot replace the shared Run, Trace, principal, environment, resource-version, or idempotency identity.

Timeouts, retries, and circuit breakers

Every remote or asynchronous operation declares an explicit timeout and typed failure outcome. Retries are bounded by attempt count and elapsed time, use backoff with jitter, and occur only when the operation's idempotency contract makes them safe.

• Reads and side-effect-free evaluations may retry documented transient failures.
• Action Connector retries require a stable idempotency key and server or compensation behavior that prevents duplicate effects.
• Authentication, authorization, validation, policy denial, expired approval, unapproved version, and permanent schema failures are not retried as transient errors.
• Circuit breakers stop repeated calls to an unhealthy provider or MCP server and expose the affected targets and consumers.
• Fallback applies only to pre-approved model routes inside the Model Gateway. It never bypasses a gateway or silently substitutes an MCP tool.

Fail-closed behavior

An Action Connector does not execute when any required guarantee is unavailable or indeterminate, including:

• Principal or workload identity.
• Resource, deployment, server, or Connector version.
• Capability grant or environment scope.
• Policy evaluation, valid approval, separation of duties, or current operating window.
• Typed argument validation or stable idempotency identity.
• Required evidence publication or recoverable evidence-outbox capability.

Data and Decision operations return a typed degraded or unavailable response when their required controls cannot be established. They do not convert missing authority into an allow decision. No runtime uses direct provider or MCP access as a recovery path.

Durable state

Workflow state and Governance Approval state are durable and independently identifiable. A worker crash, gateway restart, deployment, or long approval delay does not lose the current step, validated request reference, policy result, approval history, retry budget, or idempotency key.

Resumption uses compare-and-set or equivalent state-transition controls so only one worker can advance the durable state. The business operation remains distinct from worker attempts.

Version stability and quarantine

Executions pin the resolved model deployment and Connector version at their defined boundary. Model fallback can select only a deployment already approved by the active routing policy. MCP tool additions, removals, or schema changes create candidate Connector versions.

A breaking or unreviewed MCP version is quarantined until ownership, classification, schema fixtures, policy behavior, idempotency expectations, representative responses, failure behavior, and environment promotion are certified. Existing certified versions remain available only while the server can still honor them safely.

Approval and delayed-work re-evaluation

Approval records authority at a point in time; it does not reserve future permission indefinitely. Before delayed work or an approved Action resumes, Mission Control re-evaluates:

• Current principal and delegation validity.
• Resource lifecycle, immutable version, and environment binding.
• Capability grant, current policy bundle, and separation of duties.
• Approval status, scope, rationale requirements, and expiry.
• Connector certification, pinned version availability, server health, and operating window.
• Time-sensitive risk, value, data-class, and business-context references.

A changed condition may continue, deny, expire, cancel, or create a new approval according to policy. Resumption remains idempotent.

Exception handling and compensation

Failed asynchronous work enters a visible exception queue with the owning resource, Run and Trace, failure class, attempt history, affected business reference, policy and approval context, next permitted actions, and responsible team.

A Workflow step declares whether it can retry, pause, compensate, route to a Human Task, or terminate with a structured failure outcome. Compensation is a new governed Action with its own policy, idempotency, evidence, and possible approval; it does not erase the original effect.

Evidence durability and duplicate suppression

Evidence publication uses a transactional outbox or a recoverable equivalent. An executed Action and its durable evidence intent are committed together, or recovery can prove and publish the missing Evidence Event before further dependent work continues.

Consumers deduplicate Evidence Events by event identifier and schema version. Action execution deduplicates by the stable idempotency key within the declared business-operation scope. Replayed messages can add delivery attempts, but they cannot create duplicate business effects or divergent primary evidence.

If evidence delivery is delayed, the Run exposes an evidence_pending or equivalent explicit state. It is not presented as fully assured until publication succeeds or a controlled incident documents the unresolved gap.

Degraded service and incidents

Every service exposes health, dependency state, affected environments and resources, operating impact, and the time of the last successful control operation. The product distinguishes healthy, degraded, unavailable, and recovering states.

Degradation changes available actions explicitly:

Condition	Required behavior
Policy service unavailable	New Action work fails closed; already durable work waits for re-evaluation
Approval service unavailable	New approval-required work waits; no implicit approval is inferred
Evidence path unavailable without recoverable outbox	New Action work fails closed
Provider unhealthy	Model Gateway uses only an approved fallback or returns a typed failure
MCP server unhealthy	Connector circuit opens; affected Workflows wait, compensate, or enter the exception queue
Telemetry delayed	Execution follows control guarantees, records the gap, and marks operational visibility degraded

Material degradation automatically opens or links an incident to affected deployments, Connector or model versions, Runs, Traces, policy changes, exception-queue items, and evidence gaps. Recovery records the actions taken, restored guarantees, corrections, and outcome impact rather than erasing the degraded interval.

Current governance mapping

The current source release uses Organizations, Teams, real user/service-account virtual keys and separate human management roles. Agent is managed application content; deployments own secretless execution access and publisher funding. Observe uses Requests, Traces, Sessions and Usage with separate metadata/content/export permissions. Historical identity terms in this target proposal are not the operating contract. See Current release.