Standup vs. the Board
Every recommendation the 2026-09-10 standup made, graded against the portfolio-architecture record and the 177-row rollout board.
Fede · Gera · Sean · read 2026-09-10 · 13 recommendations graded
Verdict — B+
Sound model, wrong order. The room re-derived our model almost line for line — operator authority, property override, tiered roles and the three org shapes are all already decided or already merged.
What it wants by Monday is mostly Phase 4 and Phase 7, which are open, and two of its concrete moves run ahead of the machinery that would make them safe.
- 3 already there
- 2 partly there
- 5 needs work
- 2 conflicts
- 1 worth adopting
The model — what the room reasoned out
Policies live with the operator
✅ Already there
- Says
- Whoever runs day-to-day owns the rules.
- Stands
- Ruled in September as “authority follows the manager.”
- Do
- Nothing — but note the room just firmed up a ruling you logged at low confidence.
D-0909-1 · decided-2026-09-09.md:19 — flagged there as “DIRECTION, not specification,” founder “not very confident.” D-0909-4 (strictly one PM firm per property) is the confident one.
Org policy, property override
🔧 Needs work
- Says
- Set it at the org, override it per building.
- Stands
- Per-building settings exist; org-level settings do not. There is no rung to override.
- Do
- Land the org rung before promising the override — this is the launch blocker, not the roles.
src/lib/data/dynamo/settings.ts — per-property rows write PK=PROP#<id>; everything else is ONE global row, PK=CONFIG SK=SETTINGS, shared by every customer. Zero occurrences of ORG# or orgId in all 267 lines. The walk is p4-scope-path / p4-resolve — both open.
Override “regardless of org policy”
❌ Conflicts with a ruling
- Says
- Sean: a property can always make an exception.
- Stands
- Overridability is per-key, and some keys refuse it outright.
- Do
- Tell Sean the exception is real but not universal — fair-housing text and consent are org-only by design.
The ruling: decided-2026-09-09.md:65–74 — “the firm should be able to delegate those rules… a per-key may-write flag.” The design: design-final.md:435 writableAt · :463 POLICY keys refuse a write below the org · :537 the four write refusals. Gera’s version in the room (“a field the org operator allows”) is the design; Sean’s absolute version is not.
Roles in tiers
🟡 Partly there
- Says
- Global admin, regional, on-site, then leasing and maintenance.
- Stands
- That hierarchy exists in code — Dara’s rung included. Roles still only show and hide UI.
- Do
- Fine to defer, as the room agreed. Correct one detail: leasing and maintenance sit beside the PM, not below.
ROLE_HIERARCHY: platform_admin 0 · org_admin 1 · regional_manager 1.5 · pm 2 — understand-roles-isolation.md:158. Enforcement is p7-staff-job, p7-actor-view, p7-bypasses — all open. Permission contents deferred by D-0909-12.
Cover all three org shapes
✅ Already there
- Says
- Third-party manager, owner-operator, centralized and decentralized.
- Stands
- Twelve operating-model fixtures already merged, covering every shape the room named.
- Do
- Nothing. This is the part of your generalizing work that is banked.
p2-fixtures-7251 (merged) F01–F12 · #7251. Centralized S2/F03, third-party S6/F07, owner-operator F08 — design-final.md:765–778.
Ask the shape at onboarding
💡 Worth adopting
- Says
- Sean: two questions up front configure the system.
- Stands
- The shapes are modelled; no intake question exists or is priced.
- Do
- Adopt it, but not as a binary — your own record says hybrids are the norm, so ask when a gap is hit.
Not on the board. Fede proposed the same thing on Aug 19 (transcripts/A-aug19-20.md:289) alongside the counter-strategy “ask only when a gap is hit” (:293). D-0909 framing: “we’re going to have hybrids… we have to be dynamic.”
The moves — what the room wants done this week
Move Yale to ConAm, owners read-only
🔧 Needs work
- Says
- Fede moves it tonight; Jay and Kenya keep a view.
- Stands
- The move is right. The view they’d keep it for is entirely unbuilt.
- Do
- Move it — then tell Jay he loses sight of Yale until Phase 7, or hold the invite.
p7-relationships, p7-actor-view, p7-login, p6-rekey-run — all open. And it isn’t a viewer flag: getProperty returns null across houses (design-final.md:629); owners read a grant in their own house, people get a second membership (decided-2026-09-08.md:45).
The custodian state “won’t exist”
❌ Conflicts with a ruling
- Says
- Sean: don’t solve for PropFlow holding Yale.
- Stands
- You ruled the opposite in September — the custody row ships in P0/P1.
- Do
- Push back. What got retired was the name, never the state.
D-0909-8 shape C (design-final.md:3352) · D-0910-1 keeps FH1’s custody row · REL_KINDS gains operated_by, ORG#/PROFILE gains custody{} (design-final.md:3459) · D-0910-5 builds one handover mechanism for exactly this. Only the label “acting operator” was dropped, and by a model decision, not a founder ruling.
Monday’s minimum set
🔧 Needs work
- Says
- Org calendar, org email, org policies, property override.
- Stands
- Email already connects in Fede’s flow. The calendar write is mid-flight, and the org settings rung doesn’t exist.
- Do
- Spend Monday on the calendar read and the org settings rung — those are the two that aren’t there.
p0-calendar-row blocked — #7526 lands the write half, the org read rung is in neither PR · p4-* open (the override walk) · email works today in onboarding; what’s open is the lane that puts it on the org row — p3-envelope, p5-mail-lane.
Delete the test org tonight
🔧 Needs work
- Says
- Fede deletes both, then seeds the four real ones.
- Stands
- We already shipped the writer’s sibling, and it archives.
- Do
- Send Fede one line: archive, don’t delete. Cheapest fix on this page.
p1-archive-org (merged; resolves in both deployed prod Lambda bundles) · p0-client-seed context: “rollback being archive and not delete.”
The wall — data leaking between customers
🟡 Partly there
- Says
- Fede found leakage; you own the isolation work.
- Stands
- Write-side guards merged. Every read-side guard is still open.
- Do
- Nothing new — you already priced this gap and dated its end.
p1-org-guard, p1-properties-route merged · p0-isolation-observe, p1-roster-refuse, p7-admin-flip, p7-bypasses open · D-0910-6 authorises the broad logins until the closing phase lands, with the cross-company reads counted nightly.
The claims — things asserted in the room
“Every change has an edit log”
🔧 Needs work
- Says
- You told Sean we store who, what and when.
- Stands
- Designed in detail. Written nowhere. The settings writer takes no actor at all.
- Do
- Correct it with Sean before he repeats it to a client.
Design: setBy{userId, source}, HIST# rows, MAPLOG undo, a provenance fitness function — design-final.md:249, :370, :727, :945. Code: saveSettings(Partial<AppSettings>) takes no actor, no timestamp, no history; only the renewal arm row carries updatedBy. p3-attachment and p3-maplog are open.
Billing customer ≠ org
✅ Already there
- Says
- JP&Co and ConAm bill separately even when they share a building.
- Stands
- Shipped — one registered writer, modules as an attachment on the org.
- Do
- Your pushback on seeing one property was right about the wrong screen — that’s the billing view; the hierarchy view is Atlas, still open.
p0-add-customer (shipped) · createOrganization at src/lib/data/interfaces/organization.ts:24, a put guarded by attribute_not_exists(PK) · #7313. Hierarchy view: ui-atl-b, open.
Your three
-
The edit log doesn’t exist.
You described it in the present tense to a co-founder who will describe it to a client. The design is excellent; the code has no actor on a settings write.
-
“Property override” currently overrides nothing.
Settings are one global row plus per-building rows, with no org rung between them. The affordable-housing and security-deposit cases Fede named for Monday need that rung, not roles.
-
Moving Yale tonight strands JP&Co’s view of it.
Cross-house visibility is Phase 7, and it isn’t a read-only flag — it’s a second membership. Move it, but say so out loud first.
Graded against docs/planning/portfolio-architecture (design-final.md, decided-2026-09-08/09/10) and the 177-row tracker in portfolio-architecture-phases.html. “Shipped” and “merged” are the board’s own words and mean a merge link, not production proof. D-0910-7 does exist — “One calendar per operator org” (b89068414), at decided-2026-09-10.md:139 on origin/main. An earlier draft of this page said it did not; that read a local copy of the file saved before the decision was appended.