Organization architecture
Architecture lesson · Decisions through September 10, 2026 · D-0910-1–5 folded in
Organization architecture · The Yale case

Who gets to set
the pet fee?

16 September. Organization Core: the shared ORG# contract. Portfolio: a property collection. Current defaults and explicit scope apply; ordinary roles carry no privileges. Earlier examples are historical. Current contract ↗

OwnerOperator’s spaceLock pet feeNo policy-write rightYale · y1Operator policy

The owner and manager are separate companies. Both may be customers.

The dangerous moment: the owner locks a pet fee, and the person actually managing Yale cannot change it.

The operator controls policy—even when someone else pays.

The operator may explicitly let its qualified property staff set a local fee.

The operator writes; the owner’s lock stops; reports publish into the owner’s space. D-0910-1 closes OR3’s authoring hole with PropFlow defaults. Which keys may default is open.

D-0910-1 · Yale fixture · ST-900 · D-0909-1, 2, 4, 5

Story: notes/stress-catalog.md, BENCH-Y (line 411) and ST-900 (line 953): one customer manages, a different payer/owner has report rights; the landlord lock is refused and the explicitly delegated PM write is accepted.

Rulings: notes/decided-2026-09-09.md, D-0909-1/2/4 select the operator. D-0909-5 moves the appointment beneath the property onto a management scope — the Fable review argues the storage mapping of that ruling (slide “The same ruling, two ways to store it”). The slide names roles rather than inventing customer names or amounts.

The honest limit, historically: notes/want.md §10.61 OR3 and §10.63 guaranteed attribution and audit while the operator held no login, without refusing invented answers. D-0910-1 closes that authoring path; it does not settle default eligibility. Slide “Yale before the operator signs”.

Words first

Eight words, and the one thing each of them is not.

16 September update. Current vocabulary: Operator is the company; Staff are people. The acting-operator third-role / handover ceremony below is historical. Current contract ↗

Separate companies, people, and credentials.

operatorCompanystaffPerson inside the companyPMS credentialSync login
TermMeaning and boundary
operatorCompany running the building; org-level role, not a person. Exactly one operator org per property.
acting operatorStand-in holding the login under a dated mandate. Missing values fall to PropFlow defaults where eligible; the operator overrides. Genuine transcription stays attributed.
staffHuman with a role inside a customer’s space.
agentClara, the AI; one shared set answers every line. Not a human real-estate agent.
org_adminTop administrator person, not operator or landlord; only rung delegating manage_roles.
property owner (landlord)Holds deed; may receive reports/financials, not policy control.
PMS credential holderSync login: Property.ownerId, never landlord identity.
owner-operatorSame company owns and operates; industry phrase, no third role.
At Yale, ConAm is the operator, JP&Co is the acting operator, Sean is staff, and Clara is the agent.
Examples, role levels, and relationship records
  • Operator examples: ConAm at Yale; Situs, Western Slope, and Camellia at their buildings. Camellia is an owner-operator.
  • Acting operator today: only JP&Co at Yale, until ConAm onboards.
  • Records: org_admin is level 1. The landlord is a separate party org with a dated owned_by relationship.
D-0910-1 (2026-09-10) · Vocabulary ruling, 2026-09-09 · AGENTS.md house vocabulary · WANT §1 (three senses of “owner”) · types.ts:3371

The final terms — operator and acting operator — are the founder’s ruling of 2026-09-09, relayed by the coordinator; the ruling also fixes that the operator is an org-level role (a property points at exactly one operator org; no property-level operator entity) and that “owner-operator” is not a third role. The ruling is not yet in a design file; the design set on fable/arch-review still uses its earlier identifiers (FIRM_GRANTS, managing_firm, …), which this deck keeps verbatim inside code so its citations stay findable.

The three senses of “owner”: docs/planning/portfolio-architecture/how/AGENTS.md house rules and notes/want.md §1 — org_admin (src/lib/platform/auth/permissions.ts:52-57, level 1), property owner (landlord: ORG#{purpose:'owner_party'}, holds no rung), and the PMS credential holder (src/lib/data/types.ts:3371: “Property.ownerId is a Better Auth userId for PMS credentials rather than a landlord identity”). manage_roles and its ceiling: notes/decided-2026-09-08.md §6. The earlier acting-operator mechanism — per-value attribution, refusal of an unattributed write, confirm-or-re-author at handover — is design-final.md §20.82 FH1–FH5 and notes/want.md §10.63. D-0910-1 supersedes it as Yale’s answer: the dated mandate stays, but missing values use eligible PropFlow defaults until the operator overrides. Genuine transcription retains attribution; the stand-in may not invent an absent operator’s answer. Keep the honest limit from §10.61 OR3: the acting operator’s staff are the pen, so a rule the operator never stated can be typed and nothing refuses it. That hole produced the ruling: remove the authoring power rather than police it. Which keys may default remains open.

The company is the wall

A login never opens another company’s files.

Park West and Bellwether are separate customer spaces.

Park WestPrivate filesa1 · a2BellwetherRead a1“not found”Other-company reads stop before fetch
Knowing a building’s ID is not permission.
  • Stop before fetching.Check lists, searches, files, and saved results too. Return the same “not found” as a missing building.
  • Publish only the allowed report.The owner receives a narrow copy in its own space; the manager’s files stay closed.

Today’s store fetches everything, then filters: the opposite order.

Caller counts and source revisions: Sources & notes.

Inside the wall, a person still needs permission for the specific building and action.
ST-46 · ST-12b · ST-30 · design-final §20.5.1–3

notes/stress-catalog.md: BENCH-A/B; ST-46 isolates all row families; ST-12b and ST-30 distinguish recipient REPORT rows from foreign operational rows.

design-final.md §20.5.1 requires authorization before fetching private data and preserves action/resource pairs, including lists, counts, search, exports and caches. §20.5.3 supplies explicitly entitled projections. “Wall” means no direct access to another customer's private data; approved disclosures are limited publications into the recipient’s own custody.

Today’s counts: notes/have.md §1d — 159 bare getProperties() callers versus 6 scoped at 8941d763fa; re-measured at 4f49cde3e9 as 156 versus 9 (notes/plan.md §10.11). src/lib/data/dynamo/property.ts:154-165 is the scan-then-filter. The “404 shape byte-identical to missing” rule is notes/want.md §4.

The building is the hook

Start with the place the work is about.

Old managerNew managerShared calendarStays hereBuilding a2Own lineCalendarStaff rolesLocal fee

A calendar can serve the whole company. When a2 gets its own, an attachment connects that calendar to a2.

The local calendar can be selected for a2; a1 can keep using the shared one.

The verb a hook teaches, beyond the picture: what hangs on a2 travels with a2. Hand a2 to a new manager and its own calendar, its own line, its staff roles and its local fee go along; the company’s shared calendar hangs on the company and stays behind. That is also why the review argues a2 itself must stay the unit that moves (next chapters).

For work governed by an operator, first identify the building’s management scope. The newest ruling puts the operator’s appointment there; the Fable review argues that “scope” should be the building row itself. Both positions are on the “two ways to store it” slide.

BENCH-A-calB · ST-17 · D-0909-5

design-final.md §§2–3 and notes/stress-catalog.md BENCH-A-calB/ST-17 supply the a2 local calendar versus a1 company calendar example. Later calendar selection contracts govern actual endpoint choice, permissions and capacity.

notes/decided-2026-09-09.md D-0909-5 requires management scopes below a property and explicitly leaves re-siting of policy, chain and managing relationships unfinished. The diagram shows associations, not final attachment storage keys.

Nearest wins

A permitted local value beats the shared default.

Override activeOverride endedCompany · $50Company · $50a2 · $40 winsa2 · empty

The answer for a2 is $40. The $50 row stays in place for buildings that inherit it.

End a2’s override and its answer returns to $50.

One operator-authored rule, with an explicit exception.

These fees are operator values, not PropFlow defaults. Nearest-wins chooses among eligible values. A lock, a bound, or missing permission can make a local value ineligible.

D-0910-1 · ST-161 fee values · ST-451 inheritance · WANT §10.56

D-0910-1 (founder ruling, 2026-09-10): these fee defaults are the operator’s own values, not PropFlow defaults. Platform default eligibility for business/legal terms remains open.

notes/stress-catalog.md ST-161 supplies company 50 and a2 override 40. Its historic key spelling is knowledge.pets.fee; newer ST-900/902 use fees.pet. This deck uses “pet fee” in prose and the newer key where it shows shorthand.

The example is expressly qualified by notes/want.md §10.56 FG2–FG7: a current explicit operator grant is required for an active lower value. ST-451 states that ending an exception resumes the default. These are fixture amounts, not operating fee recommendations.

What a row actually is

A row is one stored record, with named fields.

Think of a line in a table: a place, a kind of fact, and the fact itself.

Where it appliesKind / keyValueWho allowed itHistory
Building a2’s
selected scope
setting
fees.pet
$40Current operator grant
for this key + target
Author, valid interval,
source revision

An attachment adds a value or capability.

A fee setting, a calendar connection, or a phone-line attachment is a record connected to a node.

A relationship records a role.

owned_by records an owner.
managed_by records the accepted managing appointment.

A stable slot selects the current revision. Older revisions remain evidence.
Readable row notation; scope storage keys remain proposed · design-final §20.3.2 · WANT §§10.55–56

design-final.md §§3.2/3.4 and §20.3.2 define attachments, relationships, stable SLOT guards and immutable revisions. notes/want.md §10.56 supplies exact grant/target eligibility and provenance.

This table is a teaching projection, not a literal proposed database schema. Under D-0909-5 the exact keys for management scopes and the placement of operator-governed policy slots still need design. The $40 value comes from ST-161, qualified by current grants.

Follow one lookup

Walk upward until an eligible value answers.

16 September reconciliation. These example amounts are customer-configured illustration, not platform-provided financial policy. A property override obeys the key’s location and lock rules. Ordinary staff role rank does not decide whether an in-scope edit is allowed.

Building → ordered chain group → operator. Then an eligible PropFlow default; which keys qualify is open.

Company · the operatorShared default$50Chain groupNo valueBuilding a2Explicit grant + valid value$40
$40 wins at a2.

Its granted local value is nearer than the operator’s $50 default.

Result shown; animation is optional.

The full resolver checks current grants, applicable constraints, and the key’s rules. “Nearest” is never permission to bypass them.

D-0910-1 · ST-161 + FG2–7; empty group shown to expose the walk · D-0909-5 scope placement unfinished

The numeric fixture is ST-161. The optional empty group is a teaching expansion of the permitted building → ordered chain groups → company walk, not an invented third fee. Source: design-final.md §20.4.1–3.

notes/want.md §10.56 requires explicit lower grants. D-0909-5 means split-property lookup must first identify the management scope; the drawing conveys intended authority routing, not settled SLOT/chain key placement. Ending a value resumes inheritance; typed suppression and an absent value are different (§20.4.2).

Why the walk behaves differently per key

Two questions govern conflicting answers.

16 September reconciliation. Current: a signed key class does not approve every default. Preserve each key’s source, missing behavior, placement and locks. Free-form knowledge composes matching normalized titles, with property precedence subject to locks; old blanket append-only wording is historical.

Does it inherit? If so, which end wins?

Inherited answersPOLICYPARAMETERCompany winsNearest wins
  • No inheritanceIDENTITY: building only; never borrow a sibling’s address.
    COMPLIANCE_FLOOR: nobody writes it; law clamps last.
  • InheritancePOLICY: company wins; lower writes refused.
    PARAMETER: nearest permitted value replaces the default.

Edges: knowledge appends; company locks mask local values; an unknown home uses company timezone/jurisdiction and stricter compliance.

Class controls resolution. Authority controls who may write.

The founder signs the class list before authorship: narrowing later requires sweeping every row.

Class examples, write rules, and authority domains
ClassWho may write itWhen two answers disagreeIn the founders’ world
POLICYThe company onlyThe company’s answer is the answer. A write anywhere below is refused at write time — it is always, in effect, locked.The fair-housing text. Who may send a text. How long conversations are kept.
PARAMETERCompany, group, or building — where the operator allows itNearest wins. The closer value replaces the one above (free-form knowledge is the one exception: it appends, shown at both levels). A company lock can still mask the nearer rows.The pet fee: $50 at the company, $40 at a2. Quiet hours across four Western Slope communities: three share one value, the fourth keeps its own.
IDENTITYThe building onlyNever inherited. Read at its own building or not at all — a known building never borrows a sibling’s answer. A wrong answer here reaches the wrong place or the wrong person.Timezone, address, the application link, what kind of asset it is. (A phone number goes one step further: it is not a key at all but a claim — one number, one holder, refused twice.)
COMPLIANCE_FLOORNobodyClamps last. Applied after the walk is over, to whatever won; stricter while the building’s state is not yet known.Legal contact hours clamp Clara’s texting window no matter what anyone set. Notice periods. Protected classes.

Compliance jurisdiction comes from the building, else the company. Authority domains: operator rule, property fact, a person’s own account, platform floor. D-0910-4 rejects the added landlord-written agreement-term domain.

D-0910-2, 4 · WANT §3 class table · design-final §4.2 key table, §15 (the irreversible decision) · FG1 authority domains · ST-161, ST-474

The two-question framing is the founder’s, relayed by the coordinator on 2026-09-09 (“Isn’t it really only like two directions, top down or bottom up? … all of it is defined from the top”); it is not in a design file. The slide agrees for POLICY/PARAMETER and shows where the premise breaks: IDENTITY does not walk (notes/want.md §3, “never inherited”), and COMPLIANCE_FLOOR is written by nobody and clamped last from the statute table (design-final.md §4.2, protected-classes.ts:54), with jurisdiction from the building else the org. The append wrinkle and the lock and home-unknown edges are the same §3 rows.

notes/want.md §3, the four class rows (lines 177–180 at the review’s HEAD): IDENTITY — property only, own node only, never inherited, “a known building never borrows a sibling’s identity (the real incident)”, with the one carve-out that while a caller’s home is unknown an org twin answers for timezone and jurisdiction; PARAMETER — org/group/property, nearest wins, replace, free-form knowledge append, the org lock masks nearer rows; POLICY — org only (plus an acquired chain group), a write below the root refused at write, always effectively locked; COMPLIANCE_FLOOR — nobody writes, clamp last, jurisdiction from the building else the org, stricter while unpinned.

design-final.md §4.2 key table: fees.* / pets.policy and knowledge.* as PARAMETER (structured inherits, free-form appends, “never merged”); fair_housing_text, consent_model, retention.days, clara.send_tiers as POLICY (“a building cannot widen who may send”); tcpa_contact_hours, state_notice_period, protected_classes as COMPLIANCE_FLOOR. §15: “The registry class list is the one irreversible decision (K12).” §17 #2: the founder signs the class list.

Examples: the $50/$40 pet fee is ST-161 (fixture amounts); the four Western Slope communities are Fede, Sep 8 02:12:51 (notes/transcripts/E-sep7-8-podcasts.md §2), historically modelled by notes/want.md §10.64 as the resident-facing community.quiet_hours key (PARAMETER, nearest-wins) beside contact.hours, which the TCPA floor clamps — the proposed two-key split (ST-474) is superseded by D-0910-2: ONE quiet-hours key means “may Clara speak FIRST”; agent-initiated messages are blocked during quiet hours, replies to a resident who wrote first are allowed. The phone number is the address claim of notes/want.md §2.2 (one head per physical number, attribute_not_exists), not a key class. The second axis is FG1 authorityDomain (notes/want.md §10.56) with the proposed agreement_term (§10.67) superseded by D-0910-4: the owner requests, the manager applies. No amounts or hours beyond the fixtures are invented.

Who may write

The operator writes the rule book—and the permissions.

16 September reconciliation. The role-privilege example below preserves the old proposal. Its result is historical, not current acceptance. Ordinary scoped staff have the same ordinary edit behavior; explicit entitlements, value locks, provider permission and the named-three Admin boundary remain.

Operator’s policy authorityNamed key, target, time, and limitsRegional manager’s bounded grantFurther delegation only if permittedOn-site staff’s exact write rightValue lookup goes up

Permission names which key, which scope, and which action.

Named buildings only: no future acquisitions. The all_managed wildcard is not adopted.

No local value: inherit.
No local grant: cannot write.

But someone inside the operator is the operator — the next slide says who, because the first drafts forgot to.

An override can be allowed within a range. In the fee fixture, $40 fits $25–$75; $500 does not. A lock can still forbid replacement.

D-0910-3 · WANT §10.56 FG2–6 · ST-903 · ST-161

16 September update. Historical delegation diagram. Launch uses role labels without ordinary privilege gates; explicit access scopes remain. Admin is Sean/Fede/Gera only. Current contract ↗

D-0910-3 (founder ruling, 2026-09-10): grants name buildings already acquired; no grant may cover future acquisitions. The proposed all_managed wildcard target is not adopted.

notes/want.md §10.56 FG2–FG6: exact parent grant lineage; bounded redelegation; no grant from staff title, missing lock, landlord projections, or an ordinary admin role. Active local policy requires the current operator grant and a valid value. Platform floors/property facts/account security retain independent authorities.

ST-903 supplies operator → regional PM → on-site staff delegation. ST-161 supplies the 25–75 bounds and 40/500 controls; this deck qualifies that historical case with the current FG contract.

Who inside the operator is the operator?

Regional reply: policy. Intern reply: suggestion.

16 September update. Current: ordinary in-scope staff edit without a privilege tier. Value locks, allowed setting locations and customer isolation still apply. Current contract ↗

“Do you allow co-signers?”Regional · 1.5Building valueName + dateProperty managerWaits for regional approvalInternCandidate · named and datedShown with property-level authorship not opened.

“Only the top administrator” had excluded the property team’s policy replies.

A reply is policy at the author’s altitude, and a candidate below it.
  • Level 1: authors anywhere.
  • Level 1.5: authors inside her region.
  • Property manager: authors where the operator opened the key.

Below that, retain the reply with author and date as a candidate, including an intern’s suggestion.

Open: should a property manager’s reply count at her building by default?

Transcript A §2 · WANT §10.65 AL1–AL4 · ST-477 · decision site_team_policy_authorship

notes/transcripts/A-aug19-20.md §2: Fede, 0820-0017 01:08:26 “all you have to do is Sean, Kenya, or the property team say, no, that’s not allowed. That’s it.” and 01:17:02–01:17:37 “it’s a staff reply… Sean decided this date, that’s the policy.” Gera’s intern hazard: E-sep7-8-podcasts.md §2, Sep 8 02:02:16.

notes/want.md §10.65 AUTHORSHIP_LADDER (AL1–AL4): role-derived operator authority by ROLE_HIERARCHY level inside scope (src/lib/platform/auth/permissions.ts:52-66: org_admin 1, regional 1.5, property_manager 2), a reply is policy at the author’s altitude, a candidate below it; the backfill attests today’s values; decision site_team_policy_authorship named with default 1.5. The names are the real Camellia site team from transcript A; the co-signer question is Fede’s own example (01:08). No amounts invented.

Why it is here: how/CHANGELOG-fable.md rounds 2–3 — the round-2 critic found the design had defaulted to “only the org_admin,” which would have turned Kenya’s reply into a queue behind Sean and left the migrated customer unable to activate.

What the person sees

Green means the operator allows a local value.

16 September update. Current: a green override indicator concerns a setting’s value rules, not a person’s role rank. All ordinary in-scope staff use the same rule. Current contract ↗

Your own permission is a separate check.

Illustrative property settings
Local override allowed
Operator default: $50

Your role may edit within $25–$75.

Quiet hours
Operator’s current value

One key: may Clara speak FIRST? Replies are allowed.

A key starts closed; the operator opens it per key, per building. A closed key is disabled with a route to ask — never a value held pending.

The green indicator stays visible even if this viewer cannot edit.

The save checks the operator’s grant, the person’s rights, and the value again. A green screen cannot authorize a stale write.

This is a local illustration; no real setting is changed.

D-0910-2 · Founder thread §9 · WANT FG5–6 / RQ5 · ST-448; fee values from ST-161

D-0910-2: quiet hours stay one key and gate direction, not all contact. Clara may reply to a resident who wrote first; the quiet-hours gate blocks Clara initiating.

notes/founders-custody-thread-2026-09-09.md §9 explicitly requires a per-key green indicator and, for a key the operator has NOT opened, a grayed-out disabled field carrying a route to message the operator — “if it doesn’t want to live there, it’s because the [operator] gave it permission to have an override.” A closed key never takes a value and never becomes a pending candidate.

notes/want.md §10.56 FG5 derives rungOverrideAllowed independently of the viewer and mayWrite from current grant, actor, placement and constraints. FG6 preserves locks/bounds. ST-448 exercises the distinction. §10.57 RQ5 makes the request action conditional on exact request authority and an available recipient. The UI is illustrative, not a claim of a shipped screen. Quiet hours deliberately has no invented interval.

A locked field still has a path

Asking for a change does not change the rule.

16 September update. Historical role-based request machinery is not a launch prerequisite. Configured value locks and outside-company boundaries still apply. Current contract ↗

Request · property + keyOperator’s qualified recipientDiscuss · decline · approveAuthorized commandCommitted receipt → applied

The request has a real destination.

The current operator chooses the recipient. Without a qualified recipient, the system cannot claim the request was sent.

A chat reply is only a reply.

“Applied” requires the actual policy or phone-allocation command to succeed. The request itself grants no edit rights.

Only the request’s permitted fields and deliberately shared reply cross to the requester.
WANT §10.57 RQ1–5 · ST-452–454

notes/want.md §10.57 FIRM_REQUEST specifies the existing matter/conversation/task/notification workflow, current recipient, separate submission and intake rights, exact target command and committed-result-derived applied status. A stale appointment/value requires a refreshed proposal. ST-452–454 cover delivery, denied authority, stale requests and recovery.

The newest ruling

One property can contain different management scopes.

16 September update. Current: authorized property scope and selected property scope are distinct; backend queries use their intersection. Tabs keep independent selections. Current contract ↗

Apartments and ground-floor retail can share a building while different operators run them.

One property · PROP100 Main StApartments scopeoperator: FIts appointment + rule bookRetail scopeoperator: GIts appointment + rule book
The appointment belongs below the building, on the management scope.

One operator per scope. An owner or payer is a separate relationship.

This replaces the earlier “one operator for the whole physical facility” constraint.

Decided shape; detailed storage changes still owed.

Storage remains open.The review keeps one operator per scope but maps each scope to a building row—the wall—with a shared place label above. Both shapes and their costs follow.

D-0909-5 · round-12 mixed-use counterexample

notes/decided-2026-09-09.md D-0909-5: one property split between operators stays one PROP with management scopes beneath it. The record explicitly states the operator no longer sits on the building. Apartments and retail at 100 Main St is its own example.

~/astra-review/rounds/round-12.md, lines 27–39, uses operators F/G with disjoint residential/retail mandates and exposes the erroneous facility-wide constraint. This is the historical counterexample answered by the later ruling.

The counter-argument: notes/want.md §10.60 FACILITY_SCOPE (FS1–FS5) and design-final.md §20.78 — PROP# is the custody unit (wall, partition, roster stamp, line, PMS credential, the thing that transfers), so a scope beneath it would be a filter applied after the read; the founder’s “one prop” maps to the platform-private facility identity (MC2) and his “scope” to one PROP# per operator-managed slice. Three cold critics rated this the strongest reasoning in the set (how/CHANGELOG-fable.md rounds 1–5). The decision is open; nothing here is decided by the deck.

Mixed-use, as rows

Keep the shared place. Separate the mandates.

RecordConnected toWhat it says
PROPThe mixed-use propertyThe shared place: 100 Main St
Management scopePROP → apartmentsAccepted managing appointment → operator F
Management scopePROP → retailAccepted managing appointment → operator G
Policy + grant recordsThe appropriate scope / operator pathEach operator governs only its own mandate
Ownership relationshipsThe property / relevant ownership boundaryOwnership does not merge the rule books

These are logical records, not final database keys. Policy-slot placement, chain placement, and custody around the shared parent still need the D-0909-5 specification. The Fable review’s reading of the same table: each “management scope” row is its own PROP# with its own wall, and “the mixed-use property” is a facility label with no settings — see the next slide.

Moving the apartments to a new manager must not retire the retail operator’s work.
D-0909-5 consequences · round-12 lines 27–39

notes/decided-2026-09-09.md D-0909-5 explicitly lists unfinished re-siting of managingFirmOrgId/appointmentId, setting SLOTs, chain SLOTs and managed_by relationships. The table shows the required logical distinction only; it does not claim the MC facility guard or PROP custody schema has already been rewritten.

round-12.md lines 27–39 gives the independent-transfer consequence. Separate genuine co-located properties may use separate PROP rows; creating fake property identities to evade one operator's mandate is not the chosen split-property model.

The same ruling, two ways to store it

Where does the wall go when one building has two operators?

The founder’s ruling, read literally (D-0909-5)

One property row; a management scope beneath it.

One propertyF rowsG rowsG reads both

One place, one row, scopes inside it.

Cost: the wall moves inside the partition. G fetches F’s rows before filtering—the Sep 7 leak pattern. Two PMS credentials, rosters, and Claras share one hook.

The review’s mapping (WANT §10.60) — the rule kept, the storage argued

One property row per scope; the shared place is a label above.

Facility labelNo settingsF property rowUntouchedG property rowG context

One operator per scope; people still see one property with scopes beneath.

Cost: a verified disjoint boundary must distinguish rows; mixed-use shares an address. The surface must group slices under the label.

Open decision: both shapes have costs.

Decided: operator is an org-level role, never a property-level entity. Exactly one operator org is referenced: by the scope in the literal shape, by the property row in the review’s mapping.

D-0909-5 · WANT §10.60 FS1–FS5 / DF §20.78 · ST-464–ST-467 · Transcript E §6 (the Sep 7 leak)

notes/decided-2026-09-09.md D-0909-5, including the founder’s own third consequence: mixed-use routinely shares one street address, so “separate rows have separate addresses stops discriminating exactly where it is needed most.”

notes/want.md §10.60 / design-final.md §20.78: the argument that PROP# is the custody unit; FS1 (one slice per operator, facility_slice_overlap), FS2 (boundary, not address, is the discriminator), FS3 (the facility carries nothing resolvable), FS4 (never one line across two operators), FS5 (contact hours follow the resident’s slice). The “filter after the read” pattern is notes/want.md §4 and the Sep 7 leak in notes/transcripts/E-sep7-8-podcasts.md §6 (Fede, Sep 7 00:06:22: “I was able to see all the properties, all the units”).

Nothing on this slide is decided. Both columns are drawn from the sources named; the costs are the ones each side states, not the deck’s.

Owner-operator

The same company can wear both hats.

OWNEROPERATORSamecompanyorg_st_hold
RecordTarget
PROP#h1Property h1
owned_byorg_st_hold
Scope’s managed_byorg_st_hold
Operator default / granted overrideSame lookup rules

Scope notation reflects the newest ruling; exact storage keys remain to be specified.

No special owner-operator mode is needed. The relationship targets happen to match — “owner-operator” is an industry phrase, not one of our roles: the owner org and the operator org are the same company.
BENCH-Y h1 · ST-146 L4 · D-0909-5

notes/stress-catalog.md BENCH-Y (line 411) and ST-146 L4 (line 416) explicitly define h1 as both run and held by org_st_hold, with the same resolution behavior as the ordinary managing case. WANT §10.55 preserves independent owned_by and managed_by roles. Placement of the appointment is updated conceptually to D-0909-5.

Joint ownership

A share of the property is not a share of policy control.

Owner½Co-owner½Property a1Scope · one appointed operator
RecordMeaning
owned_by {share: 0.5}First owner’s share
owned_by {share: 0.5}Other owner’s share
Accepted managed_byOne operator for this scope
Recipient REPORTOnly granted fields
Scoped spend-limit requestOwner requests; managing company applies

No owner ranking enters the lookup. An empty operator value does not send the resolver into another owner’s company. D-0910-4 supersedes the proposed exception: the owner requests a ceiling; the managing company applies it — next slide.

D-0910-4 · ST-12b · ST-30 · WANT §10.55 · D-0909-5

D-0910-4 supersedes the landlord-written agreement-term proposal below. A spending ceiling is a scoped request to the managing company, not a binding owner write.

notes/stress-catalog.md ST-12b (line 137) has two owned_by rows with share 0.5 on a1. ST-30 says the recipient reads only its own published REPORT rows. notes/want.md §10.55 states there is no observer precedence or fall-through to another party's org. The accepted appointment is shown on a management scope under D-0909-5, not on PROP META.

The superseded row: notes/want.md §10.67 AGREEMENT_TERMS (AT1–AT3) / design-final.md §20.86 — a fourth authority domain held on the accepted managed_by agreement, written by the party the agreement names (the landlord for money terms), clamping the operator’s value like a floor. This is the review’s argued exception to D-0909-1; decision agreement_terms_domain is named and open.

Owner spending requests · superseded in place

The owner requests the ceiling. The manager applies it.

Ceiling · after manager appliesManager-applied ceilingOperator’s spendingAsk above the ceiling

Gera’s spend-limit question first received “the operator, delegable downward.”

D-0910-4: a scoped request, routed to the managing company.
  • The owner asks; the manager applies.The request itself writes no binding limit.
  • Other rules stay with the operator.Pet fees, quiet hours, office hours.
  • Owner-operator holds both roles.Nothing changes for Camellia.

Not adopted: the fourth, landlord-written authority domain.

D-0910-4 (2026-09-10) · Transcript E §2 (Sep 8 01:54:08) · WANT §10.67 AT1–AT3 / DF §20.86 · ST-481

D-0910-4 supersedes the AGREEMENT_TERMS proposal and ST-481 described below. The owner requests a spending ceiling for a named scope; the managing company applies it through the authorized request workflow. This is no longer an open choice of authority domain.

notes/transcripts/E-sep7-8-podcasts.md §2, Gera, Sep 8 01:54:08: “when we’re doing a maintenance request, we have, like, a threshold, like, oh, you’re only allowed to spend $300… Does the property define it? The org? The property manager?” The $300 is his own example figure, not a recommended default; the gauge deliberately shows “under” and “over” rather than inventing amounts.

notes/want.md §10.67 AGREEMENT_TERMS: authorityDomain:'agreement_term' on the accepted managed_by agreement’s authorityTermsRef; the clamp uses the existing LOCK operator; an approval above it escalates to the landlord’s named approver through the request workflow. ST-481 asserts it. Two cold critics judged the argument correct (how/CHANGELOG-fable.md round 4; round-5 critique). This was the argued exception to D-0909-1; D-0910-4 rejects it.

Scattered single-family homes

A separate house gets its own property row.

Company · shared phone linePROPPROPPROPPROPTown tagTown tag
400 homes

The catalog’s BENCH-400 fixture

ORG#org_bigscatterThe company
PROP per homeSeparate place anchor
Company line attachmentShared contact route
GROUP {kind: area}Town label
A town label helps find a home. It becomes a policy rung only through an explicit chain-group design.
BENCH-400 · ST-44 / ST-85 · design-final §20.2

notes/stress-catalog.md BENCH-400 (line 74) supplies org_bigscatter, 400 PROP rows, one org line and town area tags. ST-44/ST-85 turn scattered street-address-as-UNIT records into property anchors while preserving actual unit records. Home icons are a schematic sample, not a literal count.

design-final.md §20.2 and OP1 distinguish setting-bearing chain groups from labels. Under D-0909-5 every managing appointment must be placed on the home's management scope; the table emphasizes the unchanged place/phone/town pattern without inventing scope keys.

Different phone layouts, the same row vocabulary

The operator chooses where the phone line points.

16 September update. Current: resource attachment and served coverage are separate. Shared lines can serve arbitrary authorized property subsets within one org. Current contract ↗

Park West shape · one portfolio number
Shared number → companyAsk which buildinga1a2a3
HEAD(phone, line → ORG)
Phone attachment on the company
Explicit send selection for each target
Bellwether ×3 shape · one number per building
Own lineOwn lineOwn line
HEAD(phone, line → PROP) per building
Phone attachment on each building
Original direct route identifies the building
The address HEAD is the current allocation record. Owning a share of a building does not authorize changing it. And one number never spans two operators (proposed FS4 / FA1).
BENCH-A · BENCH-B ×3 · WANT §10.58 FA1–3 / §10.48 OS

notes/stress-catalog.md BENCH-A (line 62) and BENCH-B ×3 (line 71) provide shared versus per-building phone layouts. The notation is readable rather than literal; actual physical phone allocations are channel-qualified beneath the current address contract.

notes/want.md §10.58 FIRM_ADDRESS requires operator allocation authority, channel control and current appointments. §10.48 OUTBOUND_SELECTION / ST-413–416 require explicit cold-sender selectors. FA3/IS require original property evidence; a company/group route remains unbound even when only one building is currently reachable. These are within-operator layouts; cross-operator sharing for a split property remains open under D-0909-5.

A hybrid portfolio

Some buildings share a number. Another has its own.

16 September update. Current: number A serves 1+2, number B serves 3+4, number C serves 5. Hybrid operation is relationships, not an org-wide mode. Current contract ↗

Shared line+10004000101Own line+10004000103g_ab · kind: line_seta1a2a3
Readable rowsJob
HEAD(shared → g_ab)Receive for the pair
tag(a1, a2 → g_ab)Phone reach only
HEAD(own → a3)Direct property route
sender(a1, a2) → alloc_abNew outbound messages
sender(a3) → alloc_a3New outbound messages

The sender rows above abbreviate explicit selectors. They are not extra policy settings.

Phone reach and policy inheritance are separate. A line_set tag is never a rule-book rung.
BENCH-A-set · ST-413 · FIRM_ADDRESS

notes/stress-catalog.md BENCH-A-set (line 64) gives g_ab as kind line_set, a1/a2 on +10004000101, and a3 on +10004000103. These are fixture numbers, not live contacts.

ST-413 (line 931) uses alloc_ab for a1/a2 and alloc_a3 for a3 via explicit cold selectors. WANT §10.58 retains operator-controlled native address commands. A policy delegation does not authorize a phone rebind; ST-455 requires a request followed by a qualified operator allocation command.

Yale before the operator signs

Before ConAm signs, who holds the keys?

16 September update. Historical handover narrative. Later rulings retire the acting-operator ceremony; preserve ownership/management links and authorized outside-arrangement expiry. Current contract ↗

ConAm’s houseYale stays in placeActing operatorConAm administratorOne handover · name open

ConAm manages Yale; JP&Co owns, pays, and is the temporary acting operator.

Shape C over A/B; now a fourth shape: ConAm’s house is minted now, Yale lives in it, JP&Co holds the login under a dated mandate.
  • D-0910-1 replaces C’s authoring half: eligible PropFlow defaults answer until ConAm overrides. JP&Co cannot invent ConAm’s answer; genuine transcription stays attributed.
  • OR3’s hole: the acting operator’s staff are the pen, so a rule the operator never stated can be typed and nothing refuses it. That authoring power is removed.
  • D-0910-5: one handover for ConAm taking over and a change of managers. The name is open.

Open: which settings may default? Business/legal terms are not settled.

D-0910-1, 5 (2026-09-10) · Transcript E §5 (Sep 8 01:32:27, 01:42:09) · WANT §10.63 FH1–FH8 / DF §20.82 · ST-473, ST-482, ST-488

Founder rulings supplied for this revision, 2026-09-10: D-0910-1 retains shape C’s house and dated mandate, selected over A and B, but replaces its authoring half — a FOURTH shape. The founder: “Make a ConAm account and then set the items in there. But while we don’t have one, just let’s leave them blank — or maybe we can make a default that’s just like PropFlow defaults for all settings that we can configure somewhere. But anything will always just be a PropFlow default until the operator overrides it.” Transcription remains machinery for a value genuinely transcribed, not the mechanism making Yale answerable. D-0910-5 unifies onboarding and ordinary manager change; neither surviving name nor reconciled stress cases is claimed here.

notes/transcripts/E-sep7-8-podcasts.md: Sean, Sep 8 01:53:47 “in Yale, we’re just the owner, not the property manager. ConAm is”; Sean 01:32:27 “ConAm’s gonna be a little slow… Yale is a guaranteed sale”; Fede 01:42:09 “that’s gonna take over a month.” Yale’s prod state: docs/planning/yale-integration/research/09-db-yale-jpco-state.md:39-44, :80 — a first-class row under org_jpco, 112 units, zero tenants.

notes/want.md §10.63 FIRM_HOUSE_BEFORE_SIGNING: three shapes argued (A: owner’s house then TRANSFER; B: operator’s house with PropFlow holding the keys; C, chosen: the operator’s house with the acting operator holding the login under a dated mandate), FH6 the pre-tenant shell re-home exception, FH8 the interval routing (the operator’s own staff author and route; the provisional admin transcribes and confirms only when no operator staff is present). Historical shape C was chosen over A and B on 2026-09-09; D-0910-1 retains its first half and supersedes its second; design-final.md §20.82 still carries firm_house_before_signing as a decision owed under its old identifier. The honest limit is §10.61 OR3 — the acting operator’s staff are the pen, so what the design guarantees is attribution, refusal of an unattributed write, and re-authoring at handover, not refusal of the write itself. That superseded authoring gap is the round-5 critique’s first finding (~/fable-review/scores.md, round 5) and led to D-0910-1; the older design contracts remain to be reconciled.

One person, two companies

One dashboard, two walls, zero crossings.

16 September reconciliation. Current: authorize each selected org/property query on the backend before combining results. Client-side union of already authorized results is a display operation, not permission to fetch broad data and hide it. Selection remains independent per tab.

Hugo’s dashboardDenver listGrand Junction list

Fede: “Hugo… can see all the Denver properties, but Grand Junction is a separate login… one dashboard has the entire thing he owns.” Gera: “multiple orgs and multiple properties… in the same dashboard at the same time.”

Two memberships mint two contexts. The screen puts the lists side by side. No row ever crosses.

A count, a chart or an export is per-company and then shown together; a single query that takes two company IDs is refused by a drift test before it ships. Where Hugo owns homes another operator manages, his second view is the owner’s published report, not a second membership.

The same drawing is Sean’s during the Yale interval: Camellia in JP&Co’s house, Yale in ConAm’s.

Transcript E §1 (02:21:22) · §3 (00:31:48, 02:20:17) · WANT §10.69 MV1–MV2 / DF §20.88 · ST-487

notes/transcripts/E-sep7-8-podcasts.md §1, Fede, Sep 8 02:21:22 (Hugo across two logins); §3, Gera, Sep 7 00:31:48 and Sep 8 02:20:17 (multi-org, multi-property dashboard).

notes/want.md §10.69 MULTI_ORG_VIEW: N memberships → N TenantContexts per request, union rendered client-side, cross_org_read_forbidden on any server-side join, membership_required drops an unheld org. The round-5 critique notes Hugo’s Grand Junction homes are Situs-owned and Western-Slope-managed, so that half of his view is ReportsContext over published rows (DEC §5), not a membership — stated on the slide. ST-487.

The answer needs an explanation

Return the value with the reason it won.

16 September reconciliation. Current: an explanation separates source, value constraints, access scope, provider capability and operational activation. Staff role labels are descriptive; old personal privilege ceilings are historical. Atlas exposes IDs and missing/broken connections without credentials.

Value$40
Selected sourcea2’s granted local revision
Displaced sourceOperator’s $50 default
PermissionExact current operator grant
ConstraintWithin the permitted range
EvidenceAuthor, time, source and grant revisions

A useful answer says what, where, and why.

Ending a grant makes its local value ineligible immediately—even if a cached screen still looks green.

Save and send check today’s authority again.

Private background discussions are not part of the public explanation. The viewer gets only the provenance they may see.

ST-902 · ST-448–450 · design-final §20.4.4–6 · WANT FG4–5

design-final.md §20.4.4/6 requires exact immutable evidence and current final authorization fences. OP2 and ST-902 require source displacement evidence even for an ordinary valid override.

notes/want.md §10.56 FG4–5 makes expired/revoked lower grants immediately inapplicable, separates current save authority from the indicator, and projects private grant/source evidence opaquely. Amounts are ST-161's teaching fixture.

Twelve rounds of adversarial review

The score stayed flat while the questions got deeper.

Each round closed findings; the critic then examined the next layer of machinery.

9.0 quality barR1 · 6.1R2 · 7.8R6 · 8.4R10 · 8.6R12 · 8.4

The opening ideas held.

The company wall, building hook, and nearest-wins stayed useful.

The implementation burden grew.

The criticism moved into permissions, old messages, delayed events, and recovery.

These are scores of a written design. They are not a production pass rate.
round-1.md through round-12.md, opening verdicts · Founder thread §11

~/astra-review/rounds/round-1.md through round-12.md, line 1 of each, supply the exact twelve scores and the 9.0 bar. The plot uses a linear vertical score scale; its baseline is not zero.

The review-loop explanation is the supplied brief's history; the reports directly support the deeper-follow-on pattern. R2 credits deterministic resolution and authorization fences; R7 credits constraint composition and effect settlement; R11 explicitly credits deterministic group/calendar/outbound selection. The reports alone do not independently certify every prior finding closed. Founder thread §11 puts correct direction ahead of score optimization.

What the early scores were telling us

A company boundary needs more precise doors.

Person+ allowed buildingReceiving event+ original companyEach saved message+ original property scope
Round 1 · 6.1

Too broad a staff gate.

Access to Yale could pass the company gate for Camellia too.

Check action + specific building.

Round 2 · 7.8

Current phone holder ≠ original recipient.

A delayed message can arrive after the number changes hands.

Keep original receiving evidence.

Round 3 · 8.2

A thread can change focus.

Switching P → Q cannot give Q’s staff the old P messages.

Give each message immutable scope.

round-1:24–35 · round-2:11–31 · round-3:9–21

Historical counterexamples from ~/astra-review/rounds/round-1.md lines 24–35; round-2.md lines 11–31; round-3.md lines 9–21. Scores from opening lines. The repair captions paraphrase the reports' proposed fixes; they do not assert deployed behavior or claim these historical gaps remain open today.

The flat middle

A more precise scope still isn’t the whole permission.

Internal discussionStaff may readMessage to a residentOnly content that resident may receive
Round 4 · 8.2

Reading is not redistributing.

Permission to read an internal dispute and contact a resident cannot combine into permission to leak it.

Carry the source’s audience limits.

Round 5 · 8.2

Old consent can come back.

After STOP, a fresh START at A must not revive B’s old permission.

Remember which revocation era issued the grant.

Round 6 · 8.4

The number changes owners.

Even that repair misses a phone number handed to a new person without a STOP.

Bind consent to person + verified contact.

round-4:8–20 · round-5:25–45 · round-6:10–22

round-4.md lines 8–20 describes actor-authorized source reading plus recipient-bound output leaking internal material; lines 40–52 separately reject treating a legitimate pet-fee override as a same-position conflict.

round-5.md lines 25–45 shows STOP/START reviving prior grants; round-6.md lines 10–22 extends the flaw to a recycled phone number and the correct subject/contact binding. These are historical review findings, not legal advice or live incident claims.

Another descent: recovery

A consistent backup can still restore the wrong authority.

Round 7 · 8.2Backup restores a revoked grant.Round 9 · 8.3One shared change log causes contention.Round 11 · 8.6Reopening gets ahead of a delayed STOP.

First, recovery needed a current authority record outside the restored customer data.

Then that safeguard needed to avoid making unrelated customers wait on each other.

Then it needed to account for restrictive messages arriving during recovery itself.

The previous repair becomes the next round’s starting point.
round-7:9–19 · round-9:46–58 · round-11:8–26

round-7.md lines 9–19 describes restoring revoked authority/consumed effects. round-9.md lines 46–58 describes global recovery-journal contention between unrelated customers. round-11.md lines 8–26 describes rejected restrictive input while sealing, followed by reopening before retry. This progression directly illustrates deeper criticism of successive repairs.

round-12.md lines 10–18 goes deeper again: the newer pending guard can be spoofed before authentication. This deck does not label the recovery protocol fully proved.

Honest scores also require ordinary work to succeed

Safe refusal is only half the job.

Round 8 · 8.4

The tours don’t overlap.
The host still can’t get there.

Travel timeTourNext tour

Availability needs a feasible trip between bookings, with evidence of the locations and travel time.

Round 10 · 8.6

A web booking has no number to reply from.

Web formConfirmationWhich sender?Explicit target → sending allocation

Being in a shared line’s reach does not select a sender. A new outbound message needs a declared sending allocation.

round-8:29–35 · round-10:36–48 · round-11:4 credits selector repairs

round-8.md lines 29–35 requires complete travel-feasible itineraries despite non-overlapping bookings; the diagram intentionally invents no times or distances.

round-10.md lines 36–48 uses a web-form booking without an inbound address and a line-set tag outside policy inheritance. round-11.md line 4 credits the subsequent deterministic group/calendar/outbound selection rules.

Round 12 · 8.4

The latest objection changed where the rule belongs.

Earlier constraint
Whole physical facilityApartmentsRetailOne appointment controls both

Changing the apartment manager could require retiring retail’s operational slice too.

D-0909-5 correction
One propertyApartments scopeOperator FRetail scopeOperator G

Move the appointment below the property. The disjoint scopes can have different operators.

A quality score helps only if the design is heading in the right direction.
round-12:27–39 · D-0909-5 · Founder thread §11

round-12.md lines 27–39 gives the facility-level cardinality failure. notes/decided-2026-09-09.md D-0909-5 is newer and answers with scope-under-property. No later passing review is asserted.

notes/founders-custody-thread-2026-09-09.md §11 says direction matters more than getting a high score on the wrong plan. The deck paraphrases the instruction rather than inventing a quote.

A second reviewer, five rounds, a fresh critic each time

The score moved when the review argued with the rulings, not when it added contracts.

9.0 quality barR1 · 7.7R2 · 7.7R3 · 7.6R4 · 8.3R5 · 8.4
RoundScoreTop finding
17.7Operator’s own region needed a grant per building.
27.7Operator authorship meant only the top administrator.
37.6Yale contradicted transfer rules; acting operator could grant operator-wide.
48.3Yale still routed through owner; Hugo’s two-company view lacked a row.
58.4PMS credential on wrong hook; replacement without signing unpriced.

Flat: misplaced protection.

Rounds 1–3 treated the operator’s own region, staff, and future building as foreign.

Jump: argue the direction.

Round 4 named decisions and costs for the split-building wall, Yale’s house, and owner’s money.

Same scale; different model, fresh cold critics. Still below the bar; residuals follow.
~/fable-review/scores.md · how/CHANGELOG-fable.md rounds 1–5 · Founder thread §11

~/fable-review/scores.md, one line per round: 7.7, 7.7, 7.6, 8.3, 8.4, each with the critic’s top finding — reproduced on the axis labels. The plot reuses the earlier slide’s linear vertical scale (9.0 at the dashed line; baseline not zero) so the two series can be read together.

Per-round changes: docs/planning/portfolio-architecture/how/CHANGELOG-fable.md rounds 1–5 on branch fable/arch-review. The critics were fresh subagents each round, told no prior score, reading the same design set cold. These are scores of a written design, not a production pass rate; notes/founders-custody-thread-2026-09-09.md §11 puts direction ahead of the number.

A reviewer correcting itself

One misread sentence nearly cost a customer its login for six weeks.

Reading “PropFlow as the CRM”Staff work outside PropFlowRefuse logins · withdrawnStaff work in PropFlowAllow property-scoped roles

The review proposed refusing external-org logins until October’s wall, at ≈0 engineer-days. It misread “PropFlow as the CRM” as “staff work in the PMS meanwhile.”

That would hide Clara’s leads from Western Slope’s two leasing people for three to six weeks.
  • Correction: the final critic caught it; the reviewer verified the transcript and withdrew the recommendation.
  • Still recorded: both options and the lead digest that makes either survivable. The design still says “refuse” pending revision.

Protection that removes the customer points the rule in the wrong direction.

Transcript E §3 (01:37:53, 01:40:57) · WANT MC7 cohort sentence · PLAN §10.11 · ST-475, ST-480, ST-483

notes/transcripts/E-sep7-8-podcasts.md §3, Fede, Sep 7 01:37:53: “the fastest path would be, like, is PropFlow the CMS [CRM], and then… We just send emails from their email box. And, like, use the number that we created to text people.” and 01:40:57: nobody types phone leads into the PMS.

The recommendation and its price: notes/plan.md §10.11 round 3/4 additions and notes/want.md §10.55 MC7’s cohort sentence (decision prewall_cohort_logins, both twins ST-475/ST-480, the digest row LD1/ST-483). The misread and its withdrawal: the round-5 critique’s third finding and the reviewer’s final report (~/fable-review/scores.md round 5). The design files were not edited after round 5, so the recommendation still reads “refuse” there; this slide is the correction of record until the next revision lands.

The honest trade

Flexible shapes require stricter machinery.

What this buys

  • One vocabulary for many portfolios.Change relationships and attachments as operations change.
  • Defaults without mass copying.Keep shared values and granted local exceptions.
  • Explainable decisions.Show the selected source, displaced value, and permission.
  • Separation that survives change.Owners get allowed views; handoffs do not silently transfer private history.

What this costs

  • More than a single-company system needs.Appointments, grants, revisions, and current checks add work.
  • More careful reads and writes.Snapshots, publication gates, and audit records need real implementation.
  • Some legitimate work must wait.Missing evidence or uncertain outside results can force a visible refusal.
  • Handoffs and new shapes are not free.Scope placement, delivery effort, and some product decisions remain open.
design-final §§20.3–7, 20.15–17, 20.77 · D-0909-3 / 5

design-final.md §20.15: stronger reads, conditional writes, revisions, immutable pages and evidence, publication control, external service probes, and safe refusal/uncertainty are real costs. Earlier fixed read budgets and delivery dates are superseded. §20.77 moves the read boundary early and displaces UI/calendar convenience work; fresh delivery commitments require repricing.

The single-company comparison is an explicit tradeoff inference from those requirements, also requested in the brief. No new duration or cost estimate is invented. D-0909-5 leaves scope-related implementation changes owed.

Settled 9–10 September

Earlier founder rulings, with dated revisions.

16 September update. These dated rulings are evidence, with later supersessions: plural calendars, roles without ordinary privileges, and the named-three-person Admin boundary. Current contract ↗

  • Order of work.Isolation comes before the new customer’s renewals.
  • The vocabulary switch.One hard cutover in a maintenance window — not a gradual bake.
  • One street address, two properties.Allowed. They are told apart by proving their scopes do not overlap.
  • A non-resident emergency.Pages the company whose line it is, never PropFlow.
  • Two logins for one building.The building’s own property-system login beats the company’s job-specific one.
  • Archiving.PropFlow staff only, and it keeps the data. Whether phone numbers are released is still open.
  • Dashboards.Two separate numbers. Buildings you run are never blended with buildings you only report on.
  • Company selection.Caps at eight.
  • Observe mode.Belongs on a building or a company. Never on a phone number.
D-0910-1–5 are folded into the relevant slides. Their remaining open questions follow.
D-0910-1–5 · Founders’ decisions, 2026-09-09/10 · notes/decided-2026-09-09.md

Recorded from the founders’ decisions of 2026-09-09 and 2026-09-10. The work-order ruling is D-0909-3 in notes/decided-2026-09-09.md — the read-side isolation work “should be baked into the strategy from day one so we should probably put it in the early phases.” The other eight are D-0909-6 (order of work), 7 (hard cutover), 10 (verified disjoint boundary, “a shared street address is fine”), 11 (the channel org’s own on-call), 13 (the building’s own login wins), 14 (archiving — PropFlow staff only and retaining, with the address-release grace window explicitly left open), and 16(a)/(b)/(c) (two dashboard numbers, cap at eight, observe never on a phone number). Where the wording here is not the founder’s own, it is the relay’s, not a quotation.

The address ruling refines D-0909-5: two co-located properties stay separate rows, but the discriminator is the non-overlapping management scope, not the address label — the same correction the slide “The same ruling, two ways to store it” records as FS2.

Open: what a deposit value looks like

Sometimes the value is a rule, not one number.

One-bedroom200Two-bedroom300Other document shapesFirst month or two months of rentA percentage of the contractSource amounts; currency not specified

The source also says deposits can be higher for single-family homes than apartments.

How should one policy vary by asset type and by unit type?

A formula needs a known basis. A per-unit schedule needs unambiguous matching rules.

The proposal favors a typed schedule with fixed or formula values. The founders have not selected the contract; the deposit key stays unavailable until they do.

Founder thread §10 · WANT §10.59 DP1–6 · ST-458–461

notes/founders-custody-thread-2026-09-09.md §10 (lines 203–206) supplies higher single-family deposits, a contract percentage, first month/two months of rent, and 200 for one-bedroom / 300 for two-bedroom. These examples are not selected policy defaults.

notes/want.md §10.59 DEPOSIT_TERMS: proposed fixed, rent_multiple, contract_fraction formulas; per_scope cannot express within-building bedroom differences; target_schedule is a contingent recommendation. No approved representation, basis, rounding or jurisdiction contract is invented. ST-458–461 keep activation gated. Asset type is metadata, not an automatic policy rung.

Open: the split building’s shared edges

A management boundary does not stop sound.

Apartments · operator FRetail · operator GSound crosses the management boundary
  • Do the operators share the building’s phone number?

    Operator control of allocation is decided. The cross-operator split-building arrangement is not.

    Review proposal: never share. One operator claims the lobby number; direct the other scope’s callers elsewhere. No shared-line row.

  • Ruled: may Clara speak FIRST?

    D-0910-2 keeps ONE quiet-hours key. It gates direction, not contact.

    During quiet hours, an agent-INITIATED message is blocked. A reply to a resident who wrote first is allowed.

Superseded: the review’s two-key split. The shared-noise issue does not create a second quiet-hours key.

D-0910-2 · D-0909-5 open consequences · WANT FG6 and four-community example

D-0910-2 (2026-09-10) supersedes QUIET_HOURS_TWO_KEYS and its proposed monotonicity decision below. One key means “may Clara speak FIRST.” It does not block a reply to a resident who initiated. The shared-phone question remains open.

notes/decided-2026-09-09.md D-0909-5 consequences 1–3 explicitly leave phone sharing and the resident who can hear both scopes open. It also flags that address labels cannot reliably distinguish independent property identities; the discriminator needs design.

notes/want.md §10.56 FG6 and its four-community example distinguish permitted contact instants from forbidden quiet intervals. The founder's interval examples cannot be used as an unambiguous narrowing calculation until the semantics are specified.

Historical proposals (quiet-hours split superseded): notes/want.md §10.60 FS4 (a HEAD names one org; sharing across two customers refuses firm_address_authority_required, ST-466) and FS5 with §10.64 QUIET_HOURS_TWO_KEYS (contact.hours with DEC §2’s monotone; community.quiet_hours nearest-wins, no monotone; decision community_quiet_hours_monotone; ST-467, ST-474). Western Slope’s 3-of-4 communities (Fede, Sep 8 02:12:51) is the case that motivated the split.

Open after the 10 September rulings

Earlier open questions, with later resolutions.

16 September update. Historical question list: D-0914 retires the handover ceremony. Defaults follow the recorded per-key ruling: product behavior may default; business/legal terms must remain unset without an authorized value. Check the linked phase item rather than reopening an answered question. Current contract ↗

Which settings may default? · D-0910-1

  • Product behaviour is safe.A default agent contact window governs Clara’s behaviour.
  • A default pet fee is a business term.Clara could quote a fee ConAm never agreed to, unattributed and indistinguishable on screen from ConAm’s answer — worse than named, dated transcription.
  • Proposed, NOT decided.Business/legal terms: no default; “I don’t have that — finding out.” Product behaviour may default.

One handover · D-0910-5

  • Mechanism unified; name open.Operator takeover from a stand-in and plain manager change use the same mechanism. Neither name is selected.
  • Stress cases still need reconciliation.Eight still name TRANSFER; ST-900 still asserts “post-TRANSFER,” a mechanism shape C removed.
  • Earlier review debt remains.PMS hook, pre-wall access, split-function custody, Hugo’s report row, re-home wording and citations: Sources & notes.
Do not turn a proposed default boundary or a surviving handover name into a decision.
D-0910-1, 5 (2026-09-10) · Round-5 critique findings F1–F9 · ~/fable-review/scores.md · WANT §10.9, §10.61 OR5, §10.63 FH5, §10.69

The supplied founder rulings leave default eligibility and the surviving handover name explicitly open. D-0910-1’s product-versus-business/legal boundary is proposed, not selected. D-0910-5 requires one mechanism for both handover cases; eight stress cases still name TRANSFER, and ST-900’s “post-TRANSFER” precondition is stale after shape C removed that mechanism. The older round-5 findings below remain review debt, including ConAm never signing and then being replaced with tenants present.

The round-5 critique (recorded in ~/fable-review/scores.md and relayed in the reviewer’s final report): F1 notes/want.md §10.61 OR5 versus §10.63 FH1; F2 §10.63 FH5’s missing leg; F3 notes/plan.md §10.11 paraphrase; F4 design-final.md §1 #9, §7 #5, §15 and notes/want.md §10.9 versus FH6; F5 FG2 versus FT4 and two enum/attribute lists; F6 three cites (permissions.ts:66, :207; src/lib/platform/auth/helpers.ts:312-354); F7 custody split by function; F8 Hugo’s owned homes as ReportsContext; F9 the P0/P1 box sums to 19–29 working days.

The Yale PMS fact: docs/planning/yale-integration/research/09-db-yale-jpco-state.md:80 (rentRollSource=yardi, descriptive only) — Yale has no PMS write path in 2026 either way, which is the honest sentence the next reviser should add beside the fix.

Return to Yale

Now follow the pet fee all the way through.

16 September update. Use the current defaults and scope rules. Do not rebuild the retired acting-operator ceremony from this historical example. Current contract ↗

YalePlace anchorManagement scopeWhich work?Accepted operator+ exact grantWho may decide?Eligible local valueBeats the default

What is a row?

A stored record of a value, connection, relationship, or permission.

What is the wall?

The customer boundary checked before private data is read.

Why nearest-wins?

A granted local exception can coexist with the shared default.

Who may write?

The operator’s authorized policy writers, and people holding its exact delegated rights.

Owners receive reports and request changes; managers apply them. Missing settings use eligible PropFlow defaults until the operator overrides. Default eligibility and the unified handover’s name remain open.
D-0910-1–5 · ST-900 · D-0909-1–5 · WANT §§10.55–59 · Sources & notes available on every slide · now also WANT §§10.60–69 / §11

Latest authority: founder rulings D-0910-1–5, supplied for this deck revision on 2026-09-10, supersede incompatible design passages below. Defaults replace stand-in authorship; quiet hours gate speaking first; grants name acquired buildings; owners request and managers apply; one handover mechanism has an undecided name. Default eligibility remains open.

Reading order for this lesson:

  1. design-final.md: the record; later §20 contracts supersede incompatible older recipes.
  2. notes/decided-2026-09-09.md: earlier founder rulings, especially D-0909-5; now qualified by D-0910-1–5.
  3. notes/founders-custody-thread-2026-09-09.md §§6–11: operator rule book, green indicator, requests, deposits, direction over score.
  4. notes/want.md §§10.55–10.59: proposed MANAGING_CUSTODY, FIRM_GRANTS, FIRM_REQUEST, FIRM_ADDRESS, DEPOSIT_TERMS; placement must now be revised for D-0909-5.
  5. notes/want.md §11 (“the model after Sep 9, in nineteen lines”) then §§10.60–10.69: the Fable review’s rows — FACILITY_SCOPE, OPERATOR_OF_RECORD, FIRM_TOGGLE, FIRM_HOUSE_BEFORE_SIGNING, QUIET_HOURS_TWO_KEYS (superseded by D-0910-2), AUTHORSHIP_LADDER, the maintenance keys, AGREEMENT_TERMS (superseded by D-0910-4), the month-one rows, MULTI_ORG_VIEW — mirrored at design-final.md §21 and §§20.78–20.88 on branch fable/arch-review.
  6. notes/stress-catalog.md: fixture stories and proposed acceptance cases.
  7. ~/astra-review/rounds/round-1.md through round-12.md: historical adversarial findings.

The first five files are in the supplied portfolio-architecture/how/ design directory. All illustrations are inline SVG, all interactions run locally, and no external asset is required.

The deck teaches decided direction and proposed contracts; it does not claim implementation, completed scope re-siting, or a later passing review.

Slide sources and interpretation

Sources

Illustration only · Nothing is sent

Ask the current operator

The real request would contain the property, the key, the proposed change, and only the current value this person is allowed to see.

The recipient must hold the operator’s current request role. Request rights do not grant policy-write rights.

A reply can discuss or decline. An applied change needs a successful authorized command, linked to this request.

PropFlow Docs