Why this exists, and the bar it has to clear

PropFlow already sells to one kind of customer well: a single building with its own phone number, its own mailbox, its own calendar. Camellia is that shape. But the customers arriving now are not that shape. Western Slope is a company that runs eighteen scattered single-family homes off one number and owns none of them. Situs is a centralized company with its own database. ConAm manages a building it does not own. There is a floating leasing assistant who covers two buildings and belongs to neither. The question this document tries to answer is whether all of those can be the same system with different rows — or whether each new shape means another migration.

Fede set the bar in plain words. Never have to migrate again. Cover single properties, multiple properties, centralized, decentralized, hybrid, people who rotate, people who are assigned, one calendar or many, one line or many. Scale from the setup that exists today. And, quote, “I want proof.” So this is not a whiteboard sketch. It is a recommendation with five tests attached, an adversarial review that tried to break it, and a harness that has to go green.

One thing to say up front, because it governs how you should listen to the rest: almost none of this is decided. Fede and Gera walked it together on the evening of September sixth and took no hard decisions. Exactly one thing is settled, and only for the voice agents: one shared set of agents for every client, never cloned per property, and when a line points at a company, Clara asks which building. Everything else is proposed. Gera is running his own investigation at the code level and owns the implementation — the “how.” This is the “what,” and it gets corrected wherever his investigation shows it is wrong.

The whole idea, in one picture

Here is the entire model. There is a company, which is the customer and the wall between customers — that part already exists and does not change. Underneath it, optionally, a group: a named handful of buildings, a region, a cluster that shares a line. Most customers have zero groups; it exists so that adding a level later is inserting a row, not changing the schema. And underneath that, the building: one property, or one scattered-site home. The building stays the storage partition for its knowledge, its settings, its tours and work orders, because that is the one coupling in the code you cannot relax without physically moving rows.

Now the important move. A phone line, a mailbox, a calendar, the PMS login, a policy value, a vendor roster, an escalation owner — every one of those becomes an attachment on a node in that chain. Same row type at every level. And here is the payoff: the only difference between a single building, a centralized company, and a hybrid operator is which box the phone line is attached to. Camellia has the line on the building. Western Slope has one line on the company above its eighteen homes. The hybrid operator has one line on a group and separate lines on two other buildings. Three customers, one model, three places the line sits.

That is why “centralized” and “single building” stop being modes. They were never really different systems; they were the same system with the line in a different spot. So the property record's operatingMode field — the flag that says what kind of customer this is — gets retired. There is no customer-type flag, no branch per shape, no agent cloned per mode.

Address claims and the one resolver

Two mechanisms make that safe. The first is the address claim. A phone number or a mailbox belongs to exactly one node, and the database enforces that when the row is written — not a convention, a constraint. When a customer leaves, the claim is released and can be taken again. Compare that to today, where two buildings can silently list the same number and the winner depends on load order. That is the kind of bug that texts one customer's resident from another customer's number, and the claim is what makes it impossible rather than unlikely.

The second is the resolver. One function walks building, then group, then company. The nearest explicit value wins. Every answer it returns says which node set the value, who set it, and when. And if it cannot name a company, it refuses — no company, no answer, no reads at all. It costs at most three queries per resolution, with the company's attachments cached for sixty seconds, and it has to fit inside the ring-time budget the voice webhook already lives under. The reason this matters: there are seven different ways settings get resolved in the code today. This replaces them with one, modeled on the one resolver that already works well — the preferred-vendor resolver. So it is not a new invention; it is generalizing the pattern that already earns its keep.

Who runs it, who owns it, who sees it

This is the part every earlier proposal missed, and it is worth slowing down on. The morning's proposals, and all five of the panel designs, put the owner inside the operator's records as a label. That answers “group my buildings by owner.” It does not answer Fede's actual question, which is: a company logged into its own account, seeing a granted slice of a building that a different company runs.

Take Yale 25 Station. JP and Co runs it and owns it. ConAm manages it under contract. Three logins should see three different things: JP and Co's owner sees Camellia and Yale, because it owns both. ConAm sees only Yale, the building it manages. Camellia's on-site team sees only Camellia. The way you get that cleanly is a dated relationship row per fact — “runs,” “owned by,” “managed by” — and then every login's view is derived from those relationships at read time, deny by default. A manager gets the operational view of what it manages and nothing more. An owner gets reports. Anything beyond that is explicit. And because the view is computed from the live relationship rather than stored, it ends the moment the relationship ends.

The honest dependency here, stated plainly: today the dashboard decides what a login sees from a list on the login record, not from staff roles, and a company admin can still see every building on the platform because a July decision to fix that has not shipped. That read-side permission work is a prerequisite, and the rule the plan sets is blunt — no customer's people get a login until it is done.

A call on a company line

This is the one piece that is actually decided, so it is the clearest to walk. Someone dials the shared 970 number. The number's claim names a node. If that node is a building — Camellia's case — the building is known at pickup, and nothing about the call changes; the “which home” question is never even asked. But if the node is a company or a group, the building is a modeled “unknown” state. The resolver walks up for the shared values — hours, policies, calendar — and the same Clara, the same single agent, is told to ask which home. Once the caller names one, it is validated to be inside that company before any tool runs.

Two corrections from the review are baked into that now. First, the voice platform will not accept a tool parameter that is both stamped by the server and typed by the model. So the building is not “demoted” to a proposal the model fills. Instead the bound tools gain an optional “which property” text field the model fills from the conversation, and the server resolves it inside the company or refuses. Second, the resolved company travels with the request as a required argument, so a tool that has no company refuses with zero reads. Email gets the same unknown-building state: a company mailbox message the roster can't narrow asks or escalates — it never scores every building on the platform. And the two dangerous shortcuts today go away: the voice tools trusting a model-filled property id outright, and an unmapped number quietly adopting the caller's own building.

People and their calendars

A calendar belongs to the person, never to the building. That is not an aesthetic choice — it is how Cal.com and Deputy model it in production, and how multi-site healthcare scheduling works. So a centralized company like Situs has three leasing people, each with their own work calendar, assigned at the company and covering all its buildings, and tours rotate across the three. The floating assistant at Yale has her own calendar, is assigned to two buildings, and availability checks her calendar first, then the building's, then the manager's. Assignment is just a row: at one building, at several, or at the company.

The review call sharpened one thing here. Scheduling is code, not the model. Tour assignment across rotating people is modeled like an on-call rotation — a schedule that lives at the company or the building, resolved deterministically — and the model only ever calls one “schedule a tour” interface. It never picks a calendar. That shrinks what has to be evaluated. And one safety rule the review added: a calendar reachable from more than one company — the floating assistant's, when she works at two customers — receives busy blocks only. Today PropFlow writes the prospect's name, phone, income and Clara's notes into the calendar event; the other company's connection would fetch those fields. So the detail stays in PropFlow and the event just links to it. One prerequisite this surfaced: production refuses Google calendars right now — the adapter is half-built and a guard blocks it — and Situs runs on Google Workspace. That is one of the open decisions.

What “proposed” means, and the honest limits

The document is careful about what it is not claiming, and this is the section to actually pay attention to. The single most important limit: knowledge isolation weakens from structural to resolver-enforced. Today, one building cannot read another building's learned answers even by mistake, because the building is the database key and a pinned test asserts against that key. Under inheritance, that guarantee becomes “a function does it correctly.” The company wall stays structural — the anchor carries the company — but sibling-building isolation becomes a rule a resolver enforces. That is the feature you want for a portfolio, and a genuine downgrade for a multi-building customer. It should not be smoothed over, and the plan rewrites the pinned test to assert the walk only ever visits the building's own ancestors.

A few more, quickly, because they are the kind of thing that bites in week one. Failing closed looks like a regression: a number or mailbox that used to guess a winner will now refuse, and the operator has to be warned before the flip or it reads as a break. Two operators on one building is simply refused — if both partners in a joint venture want their own Clara on one address, that is two building records. And the design rides on top of some live bugs it does not pretend to fix: two voice-tool routes with different gates, renewal tools skipping an ownership guard on one route, permission overrides that are platform-global with no company key. Those are named openly as separate fixes.

What the adversarial review changed

Before this went out, eight attackers each took one lens and tried to break the draft — under-built for the onboardings, leaks, migration realism, “is this five proposals stapled together,” voice-platform feasibility, and a lens that threw thirteen future customer shapes at the entity model. Seventy-nine findings. Each went to two independent verifiers told to refute it against the code and default to “not material” when unsure. A finding survived only if both agreed it was real. Twenty survived. And notably, the “customer 50” lens that tested thirteen future shapes produced zero survivors — the entity model itself held.

What the twenty changed is instructive. One false sentence about conversations got corrected: the draft assumed a company-line conversation could live in a special partition every per-building query would still see, and four lenses showed it would actually be invisible on every per-building screen. So conversation birth was pulled earlier in the plan — a conversation now knows its company before any line is bound to one, because that window is exactly where a cross-customer identity pool would form. The review also named a pile of surfaces the draft never mentioned — email building-selection, the calendar write payload, AppFolio credentials, the platform-wide send switches, the read-side permissions — each now its own step. And the estimate roughly doubled, from fifty-three-to-ninety-three engineer-days to a hundred-to-a-hundred-sixty-four, once the review priced what the draft had left out. That doubling is the review working, not the plan failing.

The decisions on the table

None of these are taken. They are laid out as multiple choice, recommendation first, and turning any of it on at a real customer stays Fede's call. What does “company” mean — the recommendation is the operator, the account holder whose Clara answers, with owner and manager as relationship rows. What happens to Yale 25 — leave it under JP and Co, add the “owned by” and “managed by” rows, and change who runs it only if ConAm ever becomes the account holder; nothing moves today. Whether to ship the group tier now — recommendation is yes, ship the support, create zero groups. How taught answers attribute, how default grants work, how scattered homes are modeled — each has a recommended option and two alternatives.

The one with a real external dependency is Situs's calendars, because production refuses Google today. The options are: ask Situs to connect a Microsoft calendar, or finish the half-built Google writer that is sitting behind a guard. The recommendation is to ask Situs first, but price the Google writer in the same week so the answer doesn't wait on us. All of these are mirrored on the onboarding plan as decisions X10 through X17.

Proof: the harness

Fede's line was “if you're gonna recommend one architecture, I want proof,” so the recommendation ends where it should — with a test rig, not a conclusion. There is already a portfolio harness merged to main: a seeded company of eight scattered homes on one line, a second company sharing phone digits, twenty-two cases that are red on today's code. This extends it — same seed writer, same verdict contract, same fixture manifest, so the hash lock and the no-real-names guard cover every new case. Ten seeded portfolios, each modeled on a real shape but with invented names and numbers: the single building, the centralized company, the scattered-site manager, the owner-with-a-third-party-manager, the hybrid, the same human on staff at two customers, four hundred scattered homes, an acquisition, a joint venture.

And every headline assertion has the same shape: it must fail on today's code and pass after the step that claims it. Re-bind a line from a building to its company — new rows plus one claim rewrite, zero rows change partition, zero schema fields added. Camellia replays byte-identical before and after every step, and the shared agent's prompt-and-tool-schema hash is unchanged. An owner's login reads exactly its granted projection and zero other rows, with the negative case as a red test. An unmapped number is refused with zero writes and nobody minted. That is what “never migrate again” looks like when you make it something a machine checks, instead of something a document promises.