# Autonomy for the Owner and for a customer

There is no reduced autonomy for customer workspaces. The four modes, the four scopes, the approval queue, Needs You and the decision log are one implementation reached through two doors. The only difference is commercial: a customer's volume is bounded by their plan's allowances, while the platform operator's own workspace has no plan and no such gates.

- **Status:** Available
- **Audience:** both
- **In the app:** #/autonomy, #/approvals, #/autonomy-audit
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/autonomy/autonomy-owner-tenant/

## Same feature, two paths to it

A customer session is not a restricted copy of the operator's. It is the same code, reached through a facade: `tenantAdapt` rewrites the path a screen asks for into the customer form of it, and `customer_safe` in the middleware is an allowlist deciding which requests a customer session may make at all. Anything the facade does not recognise is turned into a blocked path and answered 403 rather than guessed at.

The practical consequence for autonomy is that a difference in behaviour between the two audiences is almost never a difference in the feature. If the modes screen works for the operator and 403s for a customer, the fault is in the facade or the allowlist — one rewrite that was never added — not in a deliberately narrower product.

## What genuinely differs

|  | Platform operator | Customer workspace |
|---|---|---|
| Autonomy modes | All four | All four |
| Scopes and exceptions | All four levels | All four levels |
| Approval queue and Needs You | Yes, including voice line health | Yes, including voice line health, rendered by the same code |
| Decision log | Yes | Yes |
| A plan and daily allowances | None | Yes — the ceiling on volume |
| Verifying payments, the operator's own pricing, enquiries to the operator | Yes | No — these are running the platform, not using Connect |

The last row is the only category of capability that is properly one audience's, and it is not a Connect feature being withheld. Verifying a customer's payment and publishing the operator's own price list are the work of running the business that sells Connect; a customer workspace has no more use for them than for the deployment scripts.

## Parity is enumerated, not promised

The claim that both audiences have the same capabilities is checked mechanically rather than asserted in a document. A parity test reads the route table out of the running application and compares every operator capability against every customer one. It carries two lists: the renamings, where the customer surface calls something by a different name, and the known gaps, each recorded with a reason.

> **Note** The gap list may shrink and must never grow. A new capability reachable by one audience and not the other fails the suite, and so does a gap that has quietly been closed without the list being updated. That is what makes "the same feature set" a testable statement rather than a marketing one.

## Reading a report about one audience

1. When something is reported missing on one side, check the other before changing anything.
   - Result: An asymmetry is evidence about the facade; a symmetry is evidence about the feature.
2. If it is asymmetric, look at the rewrite and the allowlist first.
   - Result: A path with no rewrite becomes a blocked path answered 403, which reads exactly like a missing feature and is not one.
3. If it is symmetric, look at the autonomy configuration itself.
   - Result: Both audiences behave identically here, so the cause is a mode, a scope or a gate — the same three places as for anybody else.
4. Say which audience you checked when you report back.
   - Result: "Works for me" is not an answer to "it does not work for my customer", and the two sessions can be held at once for exactly this reason.

## Questions

### Do customers get a cut-down autonomy screen?

No. Every mode, every scope, the queue, Needs You and the decision log are the same implementation for both audiences. What a plan bounds is how much a workspace may do in a day, not what it is permitted to configure.

### Why would a screen work for the operator and fail for a customer?

Because the customer path is a facade over the same code. A path with no rewrite is turned into a blocked one and answered 403. That is a routing defect, and the parity suite exists to catch the class of it.

### Are there customer-only features?

No. There is no capability a customer workspace has that the operator's does not, and the only operator-only surfaces are the ones for running the platform — payments, the operator's own pricing, and enquiries addressed to the operator.

## Related

- [What Connect may do](https://connectbyjbrh.com/docs/autonomy/)
- [Autonomy and spend](https://connectbyjbrh.com/docs/autonomy/spend-context/)
- [Who may change what](https://connectbyjbrh.com/docs/autonomy/permissions/)
- [The operator's workspace and a customer's](https://connectbyjbrh.com/docs/account/owner-vs-tenant/)
- [The customer facade](https://connectbyjbrh.com/docs/security/customer-facade/)
- [One implementation, two audiences](https://connectbyjbrh.com/research/two-audiences-one-implementation/)

## What this page is based on

- Connect source pack §1 — one codebase, two audiences; the parity suite, its aliases and known gaps (`docs-source/sources/GENERAL.md`)
- Connect source pack §2 — the request path and the allowlist
- Connect source pack §5 — Needs You rendered for both audiences by the same code
- Connect capability registry (`docs-source/facts.py`) — `owner_tenant_routing`, `autonomy_modes`, `payment_verification`, `commercial_pricing`