# A plan lapsing, end to end

A lapse stops spending, not access. Sends and mail ingestion refuse with a plan reason; the work that was refused is held rather than discarded; and everything already stored stays readable and searchable. No feature is removed, no screen disappears and no record is deleted. Settling the plan releases the same queue that was waiting, so nothing has to be recreated by hand afterwards.

- **Status:** Available
- **Audience:** customer
- **In the app:** #/billing, #/account
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/workflows/plan-lapse/

## The distinction the whole flow rests on

A plan decides **how much** a workspace may do in a day and how many of certain things it may keep. It never decides **what** it may do. There is no plan tier that hides Needs You, removes the Assistant or takes away a channel, because the feature set is one implementation shared by both audiences — the operator's own workspace runs the same code with no plan and no allowances at all.

So a lapse is a spending event. `reserve_daily_usage` refuses with a coded reason (`plan_inactive` when the entitlement is not active or trialing, `trial_expired` when a dated plan has passed its end), and every path that spends goes through that one reservation. Reading, searching, exporting, changing settings and signing in are not reservations, which is why they keep working.

## What stops and what carries on

| Activity | During a lapse | Why |
|---|---|---|
| Sending an email or a message | Refused, with a plan reason on the attempt | Every send reserves against the daily counter first |
| Ingesting new mail | Stops after the refusal, and the read position is not moved | Ingestion is metered; advancing past refused mail would lose it |
| Inbound customer messages already delivered | Kept and counted, never refused | Discarding a real customer's message to enforce a quota protects nothing |
| Reading conversations, calls, files, the Data grid | Unchanged | None of it spends anything |
| Signing in | Unchanged | Sign-in resolves a workspace; it does not reserve |
| Approving a held draft | Recorded, and the send waits | The approval is a decision; the send is the spend |

> **Note** A lapse and a spent daily allowance produce the same visible symptom — prepared work that does not go out — and are different conditions with different fixes. [The allowance is spent](/docs/troubleshooting/allowance-reached/) clears by itself at the next daily reset; a lapse does not clear until the plan does.

## Stage by stage

1. Trigger — the entitlement stops being active: a dated plan reaches its end, or the workspace's plan status moves out of active and trialing.
2. User or external event — usually nothing a person did. The first sign is work that stops going out, not a screen that changes.
3. Authentication and workspace resolution — unaffected. A lapse changes the entitlement, not the workspace's status, so sessions still resolve and every screen still opens.
4. Ingest or request — the next metered request arrives: a send, or the mail sync's next batch.
5. Canonical record — the entitlement row is read for the plan facts; today's usage row is read for what has been spent. Neither is written by a refusal.
6. Reasoning — none is spent. The refusal happens before the model is asked, which is deliberate: paying to draft a reply that cannot be sent is the worst of both outcomes.
7. Knowledge, memory and rules — untouched. A lapse teaches Connect nothing and changes no standing instruction.
8. Autonomy and approval — unchanged. A workspace on `autonomous` is still on `autonomous`; it simply cannot spend, so its outbound work waits like a held draft.
9. Action through a provider — none. Nothing is handed to Gmail, a carrier or a messaging provider, so there is no half-sent state to reconcile later.
10. Result — a coded refusal (`plan_inactive` or `trial_expired`) attached to the attempt, and the item stays where it was.
11. Relationship, timeline and memory — the conversation is not marked as answered, because it was not. A refused send never becomes a sent one in the record.
12. Audit, usage and Needs You — the refusal is recorded as a decision with its reason, no allowance is consumed, and the blockage surfaces for a person rather than sitting in a log.

## Why the mail cursor stays put

Mail ingestion is metered, and a refusal in the middle of a sync is the one place where a plan limit can destroy data rather than delay it. The sync walks a provider's history from a stored position. If that position moved forward over a window whose messages were refused, the next sync would start after them and never look back — the messages would not be late, they would be gone.

So the position advances only over mail that was actually stored. When a reservation fails the sync stops, records that the quota was reached, and leaves the cursor behind the refused message. The next run — after a reset or after the plan is settled — picks up exactly there. The cost of that choice is a sync that returns fewer messages than the provider had; the benefit is that nothing silently disappears.

## Coming back

1. Settle the plan. The entitlement returns to an active status and its daily limits are restored.
   - Result: The next reservation succeeds instead of refusing, with no restart and no cache to clear.
2. Let the mail sync run.
   - Result: It resumes from the held position, so the messages refused during the lapse are ingested in order rather than skipped.
3. Work the queue of held outbound items.
   - Result: Approved-but-unsent replies go out through the same send boundary they would have used, and each one gets provider evidence before it is called sent.

> **Careful** Held work goes stale even though it is not lost. A reply written before a lapse answers the message as it stood then; if the thread moved on, regenerate rather than sending an answer that reads as though nobody was listening.

## Questions

### Does a lapse delete anything?

No. Conversations, calls, files, knowledge, memory and relationships are all still there and still readable, and nothing is pruned on a schedule tied to the plan. A lapse withdraws the ability to spend; it is not a retention event.

### Can I still sign in while a plan is lapsed?

Yes. Sign-in resolves a workspace from your membership and checks that the workspace itself is active — a different thing from the entitlement. A lapse leaves the workspace active, so every screen opens and shows real data.

### Does the Owner's workspace ever lapse?

No. The operator's workspace has no plan and no gates, which is why a limit that misbehaves is often invisible there and obvious to a customer. Any allowance question has to be checked as a customer session to mean anything.

## Related

- [When a plan lapses](https://connectbyjbrh.com/docs/account/lapsed-plan/)
- [Your plan](https://connectbyjbrh.com/docs/account/plan/)
- [A lapsed plan and its recovery, end to end](https://connectbyjbrh.com/docs/workflows/lapse-and-recovery/)
- [The plan has lapsed](https://connectbyjbrh.com/docs/troubleshooting/plan-lapsed/)
- [Enforcing an allowance, end to end](https://connectbyjbrh.com/docs/workflows/allowance-enforcement/)
- [How a mail cursor loses messages, and how to stop it](https://connectbyjbrh.com/research/cursor-loss/)

## What this page is based on

- `backend/app/tenant_entitlements.py` — reserve_daily_usage and the plan gate
- `backend/app/tenant_inbox.py` — the quota stop and the held cursor
- docs-source/sources/GENERAL.md §1 — one feature set, two audiences
- Connect capability registry (docs-source/facts.py)