The product status manifest

/docs-data/status.json is the machine-readable answer to *can Connect do this*. It carries statuses, the five status words with their definitions, and capabilities, a map from capability name to {status, evidence}. It is the authority — ahead of a page's prose, and far ahead of a model's recollection of the product.

Status: Available What this means
Audience: developer
Last verified: 2026-09-10
Product version: 6.3.2

The document#

{
  "generated": "2026-09-10",
  "product": "Connect by JBRH",
  "version": "6.3.2",
  "statuses": {
    "available": "Available — running in production and reachable by both audiences.",
    "available_owner": "Available — running in production, deliberately for the platform operator only…",
    "foundation": "Foundation — the data model, service and tests exist; the customer-facing capability is deliberately narrower than the code.",
    "not_yet": "Not yet — designed and written down, not implemented…",
    "reference": "Reference — background on a standard or technology…"
  },
  "capabilities": {
    "call_recording": {"status": "foundation", "evidence": "telephony.CAPABILITIES; not enabled on the live carrier"},
    "sms_outbound":   {"status": "foundation", "evidence": "provider-dependent; the live carrier carries no SMS"},
    "mcp_server":     {"status": "available",  "evidence": "backend/app/mcp_server.py"}
  }
}

evidence is the unusual field. Each capability names what backs its status — a module, a condition, or the reason a capability is narrower than it sounds. A status word alone invites paraphrase; a status word with its evidence beside it is much harder to soften into something more encouraging.

Four routes to the same object#

Route	Shape
`GET /docs-data/status.json`	The document above, as a static file
`GET /api/public/docs/manifest/status`	The same document, with a guaranteed content type and the public cache header
`GET /api/public/docs/status`	The two maps plus `product`, `operator`, `version`, `generated` and corpus counts
MCP `get_product_status`	The same combined object as a tool result

The combined route is usually the one you want: it answers *what is this product, how current is this answer, and what can it do* in a single request, which is the shape of the question a client actually has.

How to depend on it#

Read the word, render the definition. Never map a status word onto your own vocabulary. foundation does not mean *beta* and not_yet does not mean *soon*; the definitions are in the same document, so quote them.
Do not hardcode the capability list. Names are added as capabilities are documented. Iterate the map you were given.
Treat an absent name as undocumented, not as unavailable. A capability with no entry has no published status, and saying 'Connect cannot do that' is as much an invention as saying it can.
Cache on generated and version. Both move on a rebuild; neither moves within one.
Check before claiming. The Arazzo workflow check-a-capability-before-claiming-it puts the status fetch before the search, because the order is the difference between a correct answer and a confident wrong one.

The inverse question, which is the more useful one#

Somebody deciding whether to buy or build cares less about the list of things that work than about the edge of it. Two calls give you that edge directly:

GET /api/public/docs/list?status=foundation&limit=100 HTTP/1.1
GET /api/public/docs/list?status=not_yet&limit=100 HTTP/1.1

Those are the two steps of the published Arazzo workflow enumerate-what-is-not-available. Each page they return states what is missing rather than implying it — a foundation capability has a service and tests behind it and a deliberately narrower usable feature, and the page says which part is which.

Some entries will surprise a reader who assumed otherwise: call recording and call transfer are foundation rather than available, and outbound SMS is foundation because the live carrier carries none. Those are in the manifest with their evidence, not buried in a caveat at the foot of a marketing page.

Questions#

Is the manifest the same source the documentation pages use?

Yes. Both are generated from one capability registry, so a page's status field and the manifest's entry cannot disagree — there is no second place to update and forget.

What does `available_owner` mean for me as a customer?

That the capability runs in production and is deliberately the platform operator's — running the business rather than using Connect. It is not a capability you are waiting for; it is one that is not addressed to you.

Can I alert on a capability changing status?

Yes, and it is a small job: fetch the manifest on a schedule, diff the capabilities map against your last copy, and alert on any changed status value. generated tells you whether a fetch is even worth diffing.