The canonical PURE rulebook for identity hats, organization scope, and scoped impersonation (act-as staff · act-for client). Every identity surface — the View-As dropdown, page gates, and the server-side act-as RPCs — must conform to these rules.
Owner: Lane A · Confirmed with Shattique 7/6/26 · Registry: pure_memory.standard.hats_actas · Full model + dropdown redesign + execution: pure-hats-plan.html
The eight rules
1
Dropdown is staff-only. The detailed View-As dropdown renders only for identities holding ≥1 staff hat (levels 0–4). Clients & vendors (level 5) and public (level 6) never see it — they get the plain account menu.
2
Two chip rows. Row 1 = your assigned hats (highest auto-selected on login). Row 2 = organizations. Levels 0–3 choose an org or All orgs; level 4 is locked to its single brokerage; an agent belongs to exactly one brokerage.
3
One unified funnel — no separate Clients tab. The ROLE column lists accessible staff hats and, at the bottom, the reachable level-5 rows (Client · Vendor). A staff role act as (borrow their hat); Client/Vendor act for (on-behalf). Distinguished only by the action verb and the acting banner.
4
Act-as is strictly downward. A target's rank must be strictly below your worn hat's rank — never sideways, never up, even through a temporarily-granted hat.
5
ROLE is optional. No role chosen = operate as your worn hat. Choosing an org alone (no role) = view that org through your own hat. Role + user = full act-as.
6
All orgs = filter only. It widens the search across the whole system; the moment you act as someone, scope snaps to that user's org — a global filter never becomes a global write.
7
Act-as re-scopes the whole session, including page gates. While acting, every gate reads the target's permission set; the "Exit act-as" pill stays visible everywhere.
8
Client reach is relationship-scoped. Level 5 has no parent org — clients/vendors attach via deals. Reach: agent own clients; broker brokerage's clients; site admin all. Same-level ties break on the is_primary org flag.
9
Poppy (level 0) is Super-Admin-only. Only a Super Admin may hold or wear a level-0 Poppy hat, or reach the Poppy orchestrator surface. No other hat can be granted, wear-into, or act-as level 0.
The 7-level ladder
MLS sits above Association. Levels 0–3 are cross-org; level 4 is bound to one brokerage; levels 5–6 have no hats and no dropdown.
L5End usersclients & vendors — no hats, no dropdownRelationship graph
L6Publicnon-logged-in / guestNo identity
Act as vs act for
One funnel, two verbs — the kind of role selected decides which.
Act as staff
Staff role selected borrow that member's hat / authority via the ROLE USER funnel. Downward-only, org-scoped, targets levels 0–4. Button Act as; pill Viewing as Agent X.
Act for a client
Client/Vendor row selected borrow a level-5 identity's context (search, favorites, portal) with the client's capabilities. Reach is relationship-scoped; audited as "Agent X acting for Client Y." Button Act for; also via the contextual "Act for this client" button on a client/deal record.
Data model
Table
Purpose
pure_orgsnew
Org tree for levels 0–4 (level, parent_id). Levels 5/6 are not rows here.
pure_hatsnew
Staff hat catalog (label, level, rank) driving "highest" + scope.
pure_identity_hatsexists
Who holds which hat in which org (is_primary breaks ties).
pure_hat_relationshipsnew
Delegation graph — which hat may wear which, per org_scope. The admin-editable "hats relationship management" surface.
deal / party junctions exists
client deal (agent · brokerage) — the source of Mode B relationship reach.
Action attribution while acting
Every action taken while acting is attributed to the effective identity, not your own account.
A
Effective identity. Resolve once via a shared helper: an active act-as/act-for session the target (act-as = the staff user; act-for = the client/vendor); otherwise the signed-in user.
B
Ownership. Writes (favorites, saved searches, notes, offers, showings, uploads, messages…) are owned by the effective identity — a favorite added while acting for Client Y saves to Client Y’s account.
C
Always audited. Every impersonated write also stamps acted_by (real actor), on_behalf_of (target), and act_mode (‘as’/‘for’). Reads re-scope to the target too (rule 7).
D
All lanes + Poppy. Any feature that writes user data must call the effective-identity resolver and set the audit fields. Client attribution is convention until the Auth Window makes it a server boundary (RLS + impersonation claim, ticket t-hats-rls-authwindow). A write that ignores act-as fails review.
Enforcement & change control. UI phases (dropdown, admin surface) are additive and safe now; the server-side Act-As / Act-For RPCs land with the Auth Window RLS so impersonation is a real, audited boundary — not a bypassable UI filter. This standard is the source of truth; changes require Operator sign-off and must update both this page and pure_memory.standard.hats_actas.