Deployments

The nine states

State is derived from observations and owned by the backend. The dashboard renders it and never infers it, which is why a state can be relied on in an alert.

What validation actually does

OAuth returning 200 proves that OAuth returned 200. Validation is a set of real observations, each one a live call:

• authentication_valid: the stored credential authenticates against the destination right now.
• required_scopes_present: the scopes actually granted cover what the approved capabilities need.
• destination_api_reachable: a real API call to the destination succeeds with this credential.
• customer_configuration_valid: the installation identity the destination reported, a Slack team id or a Microsoft tenant id, is actually present on the environment.
• mcp_reachable: Meetext round trips its own hosted MCP endpoint with this environment's bearer token and completes initialize.
• capabilities_discoverable: tools/list advertises every capability in the deployment package, by name.
• test_operation_successful: a read only capability is executed end to end against your backend.
• webhook_reachable: the destination can deliver events back.

Each outcome carries a detail describing what was seen and, on failure, the remediation. Evidence is stored against the deployment, so the answer to "was this ever working" is a record rather than a memory.

How a state is decided

Checks are not equal. Each one declares why it exists, and that decides what its failure means.

Given the failures, the state follows four rules in order:

1. Any check reporting a revoked grant means disconnected. Nothing done server side fixes that.
2. A blocking authentication or scope failure that is not a dependency means authorization_required. Somebody in the customer's workspace has to grant something.
3. Any other blocking failure that is not a dependency means failed.
4. Everything left is a dependency failure, which means degraded.

The diagnostic distinction matters more than it looks. Collecting optional signal about a tenant produces permission denials that look exactly like real permission failures, and without the distinction they would eventually mask one.

The three health layers

Three different questions get called health. Meetext answers them separately and never merges them.

A tool call runs only when all three hold. The headline shown in a list view names the layer that is failing, and it never collapses to working unless every layer is, because the entire point is that they can disagree.

{
  "protocol":   { "status": "connected", "detail": "Endpoint reachable and advertising tools" },
  "deployment": { "status": "pending",   "detail": "Waiting: authorization required" },
  "capability": { "status": "unavailable", "detail": "No live deployment to execute against" },
  "usable": false,
  "headline": "Waiting: authorization required"
}

Degraded because of a dependency

When a check fails, the outcome records whether the cause belongs to somebody else. If it does, the dependency is named: the destination provider's API, the Meetext MCP runtime, your own backend.

A named dependency failure degrades rather than fails. That is a deliberate statement about fault. Your product is not broken because somebody else's API is returning 503, and a customer looking at a red deployment should be told which of the three parties is actually having a bad day.

Degraded deployments still serve. The hosted MCP endpoint attempts execution in both the healthy and degraded states, because a partially degraded deployment should still try rather than refuse preemptively.

Incidents

A repeated failure with the same signature becomes an incident against the environment. Incidents record how they were detected, and, when they end, how they actually ended.

The distinction between remediation and external change exists so a transient provider fault is never credited to advice Meetext gave. An operations product that takes credit for coincidences stops being usable as evidence.

While an incident is open against an environment, the capability health layer reports impaired and names the incident signature. It does not silently keep saying available.

Timeline and attribution

Every deployment carries a timeline: milestones, the phase it is in, and how much of the elapsed time is attributable to each party. When attribution cannot be established it stays unknown rather than being assigned to whoever is convenient.

That is what makes "this deployment took nine days" a usable sentence. Nine days of which six were waiting on the customer's admin is a different conversation from nine days of which six were Meetext.

The same record backs the security review your customer's team reads, where every statement is attributed to whether it was observed, inferred or asserted by the vendor. See the security model.