# Entitlements and runtime choice

Two separate gates decide whether Connect acts. Your entitlement is commercial: the plan recorded against the workspace, the daily counters it grants and the ceilings it sets. Runtime is operational: the mode somebody chose — Auto within rules, Review before send, or Draft only — and the master run switch behind it. An entitlement nobody has switched on does nothing at all, and a mode the plan does not cover is refused at the gate rather than half-performed.

- **Status:** Available
- **Audience:** both
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/account/entitlements/

## Two gates, not one

Nothing Connect does passes a single check. The entitlement decides whether this workspace is **allowed** the action; runtime decides whether the workspace has **asked** for it. The two fail in completely different ways, and telling them apart is most of the work when a screen does less than you expected.

|  | Entitlement | Runtime |
|---|---|---|
| What it is | The commercial grant recorded against the workspace | The operating mode a person chose |
| Who sets it | The plan; for a customer, JBRH as the operator of the platform | Anyone in the workspace with permission to change it |
| Changes when | It changes, a trial ends, or it stops being active | Somebody picks a different mode or presses the hard stop |
| A refusal reads as | A plan or allowance message naming the counter or the state | No refusal at all — Connect drafts instead of sending, or stands still |
| Where you fix it | The plan screen, or a conversation with JBRH | The power control in the app, in one click |

## What an entitlement holds

**Plan code** — Which one the workspace is on. Free and trial are treated alike in one respect that matters: a limit missing from them means zero, never unlimited.
**Status** — Only `active` and `trialing` are live for sending. Any other value stops outbound work at the gate, with a plan message rather than a technical error.
**Daily limits** — One number per counted dimension, reset at midnight UTC (05:30 IST). Absent on a paid plan means the dimension is not capped; absent on free or trial means zero.
**Resource ceilings** — How many of a thing may exist at once — connected mailboxes, personal Gmail slots, business-domain slots — rather than how many events may happen today.
**Trial end** — A trial whose end date has passed is reported as expired even while its stored status still says otherwise, so an expiry cannot be missed by reading the wrong field.
**Sending signature** — Whether the plan requires a particular signature on outbound mail, and what that text is.

> **Note** The Owner workspace carries no plan gate. It is marked unlimited, so every limit resolves to nothing to enforce — but it is still one workspace among many, scoped exactly like a customer's. Unlimited is a commercial fact, not an isolation exemption. See [Owner and customer](/docs/account/owner-vs-tenant/).

## Three kinds of allowance

Every limit a plan can grant is written down in one registry alongside the code that enforces it, and a test asserts the correspondence both ways round: a limit missing from the registry is as much a fault as a limit nothing enforces. Each entry carries one of three statuses, and the difference explains most of the surprises.

| Status | What happens on the event | Example |
|---|---|---|
| Enforced | Counted, and refused once the limit is reached | Outbound email, inbound mail ingested, model calls made for the workspace |
| Tracked | Counted for reporting; the event is never refused | Inbound WhatsApp messages |
| Not reachable | Declared by the plan, but nothing in the product can consume it yet | Automated follow-up sends, prospects researched, creating a knowledge source as a customer |

A not-reachable allowance is recorded rather than deleted, because the plan names it and the registry test demands real enforcement the moment something can consume it. Reading it as a live capability is the mistake to avoid: an allowance you cannot spend is not a feature you have.

## Runtime: one mode and two switches

- **Auto within rules** — Connect replies and sends on its own, inside the limits the workspace set.
- **Review before send** — Connect writes the reply and waits for a person to approve it.
- **Draft only** — Connect reads and drafts, and never sends. This is the mode a workspace uses to watch what Connect *would* say.

Behind the mode sit two coarser controls: a master run switch that stops the engine taking work at all, and a hard stop that halts sending and polling together. Neither is an autonomy setting — they are the equivalent of turning the employee off, and are described in [Turning Connect off](/docs/autonomy/connect-on-off/). Narrower rules per channel, per mailbox or per contact resolve on top of the mode; [Autonomy scopes](/docs/autonomy/scopes/) has the ordering.

## Where the two get mistaken for each other

**Drafts appear but nothing sends, and no allowance message is shown** — Runtime, not entitlement. The mode is Review before send or Draft only. The allowance is untouched, because nothing was sent.
**Sending stops mid-morning with a limit message** — Entitlement. A daily counter is spent; it resets at midnight UTC. Held work stays held rather than being dropped.
**A plan lists a limit for something that never happens** — The dimension is not reachable yet. Nothing is broken; nothing can consume that allowance.
**A screen offers a control that answers with a plan message** — The entitlement does not cover it. The refusal names the plan state rather than pretending the button was never there.
**Everything works for the Owner and refuses for a customer** — Neither gate. That pattern is the customer surface, not the plan — see [The customer facade](/docs/security/customer-facade/).

## Questions

### Does changing the runtime mode change my allowance?

No. The mode decides whether work is sent, approved or only drafted; the allowance counts what was actually sent or ingested. Sitting in Draft only for a week spends nothing, and switching back to Auto does not restore anything, because nothing was consumed.

### Why does my plan list an allowance I never seem to use?

Because a plan may name a dimension the product cannot yet consume. Those are recorded in the metering registry as not reachable, with the reason. They are kept rather than removed so that enforcement is demanded as soon as a real consumer exists, rather than shipped without a limit.

### Can a customer be entitled to something the Owner is not?

No, and not the other way round either. The feature set is one implementation for both audiences; only the commercial bound differs. Two capabilities are deliberately operator-only because they are about running the platform rather than using Connect.

## Related

- [Your plan](https://connectbyjbrh.com/docs/account/plan/)
- [Usage and allowances](https://connectbyjbrh.com/docs/account/usage/)
- [When a plan lapses](https://connectbyjbrh.com/docs/account/lapsed-plan/)
- [Entitlement and runtime choice, end to end](https://connectbyjbrh.com/docs/workflows/entitlement-vs-runtime/)
- [The four autonomy modes](https://connectbyjbrh.com/docs/autonomy/modes/)
- [Entitlement](https://connectbyjbrh.com/docs/glossary/entitlement/)

## What this page is based on

- `backend/app/tenant_entitlements.py` — the plan gate and the entitlement record
- `backend/app/metering.py` — the metering registry and its three statuses
- `webapp/src/layout/power-control.js` — the runtime mode control
- Connect capability registry (docs-source/facts.py)