You run the platform. You're read-only on every brokerage's day-to-day data. Your write surface is brokerages, landlords, users, and rent guidelines.
Last updated: 2026-05-10
You're the platform operator — Dor today, eventually Anthropic-side support staff. Your job is to keep the platform running, onboard new brokerages, manage the global rent-guidelines table, and step into customer-support situations when a brokerage needs help.
Your home page is /admin. Not /dashboard — that route auto-redirects
you. The admin page shows the platform overview:
Below that, the admin tools tile grid links into:
/admin/audit — every audit row across the platform, filterable/admin/rent-guidelines — RGB orders and HCR caps/data-quality — the gap report (units missing rent, leases missing
end dates, etc.)/admin/brokerages — the brokerage directoryYou write on brokerages, brokerage members, users, landlords, landlord members, and rent guidelines. That's it.
You can't:
One narrow exception on the outbound side: you can send landlord-facing renewal pricing PDFs and comp reports. These are notification dispatches, not unit-data writes — they read the data the brokerage has already entered, render it, and email it. The audit log records the send under your actor id so attribution stays truthful.
This isn't "the access layer is being annoying." It's load-bearing. The audit log's value depends on actor attribution being trustworthy. If super-admin could write on a brokerage's data, then every audit question — "who set the rent on unit X?" — has the answer "could have been platform support" and the trail loses meaning.
If a brokerage hits a bug that only a write can fix, the workflow is: diagnose in support mode (below), tell the brokerage admin exactly what to do, and watch them do it. The fix is theirs.
In the sidebar footer (or the mobile drawer footer), you have a View as <brokerage> picker. Pick a brokerage:
This is chrome only. Reads narrow; writes still return false. You
can navigate /inventory, click into /units/[id], see exactly what
the brokerage admin sees. Try to click "Override rent" and you'll get
the same "not authorized" response as you would without scope.
The scope is a signed cookie with a 4-hour TTL. Tampering with it doesn't work — the signature won't match.
Two ways:
Either way, you snap back to the platform admin view and the picker shows nothing selected.
Brokerages self-serve through /onboard/new-brokerage — the first user
becomes the owner, signs in, and is off and running. You don't have to
do anything to provision them.
Where you come in:
/admin/brokerages/admin/audit for the invite
verb and the system-health card on the platform overviewOpen /admin/rent-guidelines. This is the global table of:
Each row has effective_from / effective_to. When a new RGB order
drops every June, add a row with the right effective range. The rent
cap check uses the row that's currently in effect for any unit it
prices.
This table is global because the regulations are global. Brokerages don't write here.
/admin/audit is your truth source. Filter by:
You can CSV-export up to 10,000 rows. The audit log is append-only, which means corrections are NEW audit rows pointing at the fix, not edits of the original. If something looks wrong in the log, look up the verb, the actor, and the timestamp — the action was real, and the log doesn't lie.
The 30-day compliance signal on /admin flags:
None of these are alarms — they're context. If you see a spike from one brokerage, that's a conversation to have, not an automated action the system takes.
/settings shows only the Personal section. You don't have a
brokerage to configure./admin/* — that's the whole platform layer.