# A four-word vocabulary for capability status

Every capability in this corpus is described by one of four words — available, foundation, not yet, reference — with a single qualifier on the first for things that are deliberately the operator's rather than a customer's. The distinction the vocabulary exists to protect is the one a manual is most tempted to blur: code existing is not a capability you can use.

- **Status:** Available
- **Audience:** both, developer
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/research/status-vocabulary/

## The four words, and what each one forbids

| Word | Means | What it forbids |
|---|---|---|
| Available | Running in production and reachable by both audiences | Nothing by itself — but a page describing only success is still half a page |
| Available (operator) | Running in production, deliberately for the platform operator: running the business rather than using Connect | Describing it as a customer capability, and equally describing its absence as a gap in the customer's feature set |
| Foundation | The model, the service and the tests exist; the usable capability is deliberately narrower than the code | Any sentence a reader could act on as though it were usable — and the page must state what is missing |
| Not yet | Designed and written down, not implemented | Everything. The opening paragraph itself has to say so, in the answer a reader stops at |
| Reference | Background on a standard or a technology | Leaving Connect's own use of it unstated — used, supported, foundation or educational only, said explicitly |

Four words plus one qualifier is a deliberately small vocabulary. A larger one — partial, beta, limited, early access, planned — sounds more precise and is less so, because each new word carries an implication the writer did not have to defend. Five choices force a decision that somebody can disagree with.

## The distinction the whole thing exists for

*Foundation* and *available* are the pair that matters. Foundation means the data model, the service and the tests are real — a reader looking at the code would find the capability there — and the customer-facing behaviour is narrower on purpose. Blurring the two is the single most natural mistake in product documentation, because the writer has usually just been reading the code.

**Call recording** — Foundation. The capability is asked of the provider rather than assumed, and it is not switched on for the carrier in production
**A completed handover of a live call to a person** — Foundation. An escalation phrase queues one and the supervisor panel can act on a live call; finishing the handover depends on a provider capability that is not enabled
**Outbound SMS** — Foundation. Inbound, STOP and suppression all work; sending depends entirely on the configured provider, and the carrier on the live account carries no SMS at all
**Password sign-in** — Not yet, and deliberately: Google OAuth is the only way in

Each of those is a *no* that a reader can plan around. The value is not modesty; it is that somebody choosing a product learns the shape of the boundary rather than discovering it after committing.

## The most expensive phrase in a manual

The two words a manual reaches for when something is unbuilt — the cheerful pair meaning *not now, but shortly* — are refused outright here, and the refusal is enforced rather than requested. They cost more than any other phrase for four reasons, and the reasons compound.

1. A reader plans around them. A date that was never given is still read as a date, and a decision gets made on it.
2. They never expire. Nothing about the phrase carries a timestamp, so it survives every review that a wrong fact would have failed.
3. Support inherits the promise. The person answering "when?" did not make the commitment and cannot withdraw it.
4. It converts an honest *no* into an implied commitment, which is separately forbidden: no page here promises a future capability at all.

> **Careful** "Not yet" costs a writer one uncomfortable sentence and costs a reader nothing. The alternative costs the writer nothing today and somebody else a great deal later, which is exactly why it keeps getting written.

## How the vocabulary is enforced

- The registry is the authority. If a page's subject appears there, the page takes that status; it does not get to choose a warmer word.
- A **not yet** page whose opening paragraph does not say so is refused by the build. The answer is where a reader stops, so that is where the honesty has to be.
- A **foundation** page that never says what is missing is refused too. Naming the status without naming the limit is the same overclaim in a quieter voice.
- A separate written list records claims that may never be made regardless of status — a certification, a customer count, a price, a named customer, a first-person claim to have tested something.
- A technology or protocol page must answer *does Connect use this?* explicitly. A page that explains a technology and leaves a reader believing Connect implements it has failed even if every sentence is true.

## What the discipline costs

It is not free, and pretending otherwise would be its own kind of overclaim. Four words are narrower than reality, so some subjects are described by the nearest honest value with a sentence in the prose saying that is what is happening. A capability that is available for one channel and foundation for another needs the page to carry both, which is more work than one label.

- A status is a claim with a date on it, not a permanent property. Every page carries the date its facts were read, and nothing re-reads them by itself.
- The registry has to be maintained by whoever changes the product, or it becomes a second thing that is out of date — with the added harm that it is trusted.
- Marketing prefers the warmer word, and the vocabulary is a standing argument against it. That argument is the point.

## Questions

### Why is foundation not simply the same as not yet?

Because they answer different questions for a reader deciding whether to wait. Foundation says the shape is settled and the constraint is usually a provider capability or a policy rather than unwritten code; not yet says the behaviour does not exist. Collapsing them would also be dishonest in the other direction — claiming nothing is built when something is.

### What happens when a page's subject is not in the registry?

Use the nearest honest value and say in the prose that is what you have done. A page is never allowed to invent a status, and a claim that cannot be sourced is written without the claim rather than softened with a hedge.

### Does a status ever change without the page changing?

No — the status is on the page, and the registry is the authority the page is checked against, so a change in the registry surfaces as a failure on every page that disagrees with it. That is deliberate: a silent status change is how a corpus starts lying without anybody deciding to.

## Related

- [Treating documentation as a build artefact](https://connectbyjbrh.com/research/documentation-as-a-build/)
- [Why uncertainty is a valid answer from a business agent](https://connectbyjbrh.com/research/uncertainty-is-an-answer/)
- [Technology reference](https://connectbyjbrh.com/docs/technology/)
- [SMS in Connect](https://connectbyjbrh.com/docs/sms/)
- [Phone and voice in Connect](https://connectbyjbrh.com/docs/phone/)

## What this page is based on

- `docs-source/facts.py` — `STATUS`, `STATUS_LABEL`, `CAPABILITY_STATUS` and `FORBIDDEN_CLAIMS`
- `docs-source/WORKER-BRIEF.md` §3 and §4 — what may never be written, and the status rule
- `tools/docs_check.py` — the status-honesty and technology-use checks
- `docs-source/sources/PHONE.md` §12 and `CHANNELS.md` §3 — recording, handover and outbound SMS as worked examples