PropFlow.ai PropFlow.ai Docs
Acceptedmarkdown source

0135 — Roles stay; privilege enforcement is off for launch; provenance is not

Context

The portfolio architecture (design-final §5.2, "Derived grants — deny by default; D8-A") derives every person's read and write authority from role rows, and eleven board rows (p7-*) build the enforcement: an actor view, org admins losing whole-org sight, the deletion of admin bypasses, owner reports pushed only where a row authorises them. Two things happened on 2026-09-14. First, the new company/building pickers showed the founders' own logins one test company, because staff hold no role rows inside any customer company — a deny-by-default rule renders as a nearly empty, normal-looking list (blocks b89373143, b89412009, PR #8437). Second, at standup, Fede's mental model was stated and agreed: "Keep it simple. They can see everything. And then only the people operating the property can actually go change." Gera went further the same evening: "anyone can see anything and edit anything except obviously system admins will be able to see the admin page and then maintenance specialists will have a little bit more fine tone … everyone can edit settings too for now … the roles aren't gonna be impacting … for now it's just one standard." Three customer companies onboard in the next four to seven weeks; the team's stated philosophy is to surface restrictions as customers ask for them rather than front-load them.

Decision

Within a company, every signed-in person can read everything and change everything, including settings and policies. Roles remain, as data, as labels, and as routing — they do not gate reads or writes for launch. Two carve-outs and one thing that does not change:

  1. Admin pages are gated by platform_admin (the system-admin role). Nothing else is.
  2. Maintenance specialists get scoped surfaces — their own tools and views — as a matter of product shape, not as a denial elsewhere. The exact shape is a later, separate decision.
  3. Tenant isolation is unchanged. "Anyone can see anything" is within their own company. The org fence, the roster gate (in observe mode since 2026-09-14), the cross-company wall and the expiring grants for outside parties (ADR-0134 lineage, decision b89408774) all stand exactly as they are. This ADR relaxes role enforcement, never tenant enforcement.

Provenance is not relaxed. Gera, same night: "we still want to store who changed what … we would have reference to their roles. So if in the future we want to know who did what, we could always check." Every write keeps its actor, its time, and the actor's role at the time of the write. Nothing about the audit infrastructure, the settings registry's write path, or the decision receipts changes. A future ruling may re-introduce role-conditional enforcement; the recorded role is what makes that possible without a migration. Nobody changes their own role; only an admin or the operating party can (invite flow, magic link + SSO, per the standup).

What a future reader should check code against

Effect on the board (portfolio-architecture-phases)

The driver re-scopes, citing this ADR: p7-admin-flip and the enforcement half of p7-actor-view, p7-bypasses (keep only the admin-page gate) and p7-reports (keep the push mechanics, drop the authorisation half) are superseded for launch. p7-login, p7-invite, p7-relationships, p7-staff-job, p7-plink, p7-groups, p7-domain-override are unchanged. design-final §5.2 carries a superseding note pointing here.

Consequences