01must proveConfirmed | Customer workspace access for staff requires an active staff-access grant and its ordinary role assignment. The database rejects a cross-customer staff assignment unless an active grant names it; standing grants may cover a whole customer. | invariant | service, database | test |
02must proveConfirmed | An access request names a workspace role, a reason and a duration of one to thirty days. It grants no access and notifies workspace administrators. An existing grant prevents another request for that workspace. | lifecycle | service | test |
03must proveConfirmed | Viewing and deciding staff access requires the workspace’s staff-access permission. The default Security Administrator policy supplies it; Power User and Read Only do not. | permission | api | test |
04must proveConfirmed | Approval activates access for no more than the requested duration. Decline retains the administrator’s reason, withdrawal identifies the requester as decision maker, and each decision notifies the staff requester. | lifecycle | service | test |
05must proveConfirmed | An authorized workspace administrator may grant access directly to an identified Rhythm staff member. Access starts immediately and notifications go to the member and administrators; an unknown staff address is rejected. | lifecycle | service | test |
06must proveConfirmed | A workspace administrator may revoke its staff grant. Fresh evaluation then refuses the access, although cached decisions can persist. Reconciliation preserves a deliberately revoked standing grant. | lifecycle | service | test |
07must proveConfirmed | Only Rhythm Administrator authority can open emergency access. It requires a workspace role, a reason of at least twenty characters, a ticket and a duration no greater than four hours, with no extension. Administrators and the staff security list are notified; delivery failure does not undo the grant. | validation | api, service, database | test |
08must proveConfirmed | The intended standing-access lifecycle gives Rhythm Administrators and founding super users customer-level Administrator grants outside Rhythm’s own customer. Role addition and customer creation establish them; role removal, suspension, revocation and deletion end them. Existing standing access prevents emergency access to that customer. The HQ customer-creation path currently omits the reconciliation hook, as recorded in the findings. | lifecycle | service | test |
09must proveConfirmed | Staff may end their own approved or emergency access and submit a cache-flush request. HQ does not permit ending standing grants. Another member’s grant is hidden unless a Rhythm Administrator manages it from staff detail. | lifecycle | service | test |
10must proveConfirmed | Fresh evaluation denies access after grant expiry; grant reads record its expired state. Explicit termination submits a flush request, but existing signed or cached authority may last approximately ninety seconds. | policy | service | test |
11must proveConfirmed | Staff-access events belong to the reached customer’s security history and do not appear in another customer’s history. The staff monthly report lists emergency grants opened during the requested month. | invariant | service | test |
12Confirmed | HQ workspace role choices include applicable built-ins and that customer’s roles. They exclude staff roles and other customers’ roles, and identify roles that currently grant nothing. | policy | api, service | test |
13Confirmed | The console identifies staff workspace access and its end in a banner. Entry without a grant offers emergency access; standing access enters without a dialog and cannot be ended from the banner. | policy | console | test |
14must proveConfirmed | Customer-level standing access permits customer security administration subject to the same widening and administrator-lockout checks as customer memberships. | permission | service | test |