# 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
- **Audience:** developer
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/developers/status-manifest/

## The document

```json
{
  "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.

> **Note** `documentation.pages` and `documentation.by_kind` come back with it, so one call also tells you how large the corpus is and how it is distributed across kinds — useful for deciding whether to walk it.

## How to depend on it

1. **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.
2. **Do not hardcode the capability list.** Names are added as capabilities are documented. Iterate the map you were given.
3. **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.
4. **Cache on `generated` and `version`.** Both move on a rebuild; neither moves within one.
5. **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:

```http
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.

## Related

- [The machine-readable documentation](https://connectbyjbrh.com/developers/machine-manifests/)
- [Building an agent on Connect safely](https://connectbyjbrh.com/developers/agent-safety/)
- [The Arazzo workflows](https://connectbyjbrh.com/developers/arazzo-workflows/)
- [Searching the documentation programmatically](https://connectbyjbrh.com/developers/docs-search-api/)
- [A four-word vocabulary for capability status](https://connectbyjbrh.com/research/status-vocabulary/)

## What this page is based on

- `tools/docs_build.py` — the `status.json` manifest and its capability map
- `docs-source/facts.py` — STATUS and CAPABILITY_STATUS
- `backend/app/public_developer_api.py` — `/docs/status` and `/docs/manifest/{name}`
- `webapp/developers/workflows.arazzo.yaml` — the two capability workflows