Eleven architecture questions only you two can settle

Gera and Fede each record their own answer. Each option shows who picked it, and the note box is for the reasoning.

2026-09-09 · nothing on this page is decided · answers save as you click

Two full adjudication rounds could not resolve these, because they are not engineering questions. 548 cases were re-adjudicated against the design. The reviser was handed everything it could close, and reported back that these it could not — each needs a person to pick. Both rounds then confirmed each one independently.

Ten of the eleven are that list. The eleventh — the pre-wall logins, first below — is not a stress case at all; it comes from the plan (notes/plan.md:786) and leads because Western Slope goes live on Sep 12.

Vocabulary, final: operator = the company whose rule book governs. Acting operator = the stand-in holding the login. Staff = the human using PropFlow. The words firm, custodian and portfolio are old words and are not used here; in any source quote, firm means operator and is quoted, not endorsed.

The timely one

0 of 11 answered by you.

01

In the weeks before the wall is enforced, may a staff member from an outside company log in at all?

Live between three real customersCustomer-visibleprewall_cohort_logins · notes/plan.md:780, :786

Three orgs sit inside the pre-wall cohort — org_jpco, org_western_slope, org_situs — and until the wall lands each can read across the other two. That is the Sep 7 leak shape, live between three real customers for 3–6 weeks and counted nightly by the tripwire. Nobody has accepted it. Western Slope goes live Sep 12.

In plain terms

For about a month, a leasing person at one customer could see another customer's rows. Turning that off means Western Slope's two leasing people start the job with no PropFlow at all — unless we ship them an emailed list of Clara's leads first.

Recommendation: refuse, and ship the lead digest in P0. The design recommends it too — D-0909-3's words are "from day one" — and ½–1 day buys back the only thing refusing costs.

The ten the adjudication held out

02

When two properties share one street address, what actually tells them apart?

Customer-visibleST-78 · D-0909-5 · verdicts-r2/ST-060-100.md:21

D-0909-5 ruled two co-located properties are two rows "distinguished by address" and named same-address mixed use as still open. The design supplies boundary-disjointness instead: an address matching two authorized properties returns ambiguous, labelled by name plus asset vocabulary and a verified discriminator, "never the shared street address alone". The record says outright the mechanism does not settle the identity ruling.

In plain terms

Somebody calls about "500 Main". If a shop and 40 apartments both live at 500 Main, the system has to ask which one — and the thing it asks about cannot be the address, because they share it. Pick what it asks about instead.

Recommendation: the named discriminator. Mixed use at one street address is a real shape in the book we are importing, and the mechanism is written already — it is waiting on the ruling, not on code.

03

A non-resident calls a claimed line and reports an emergency — who gets paged?

Life-safetyCustomer-visibleST-79 / O31 · triage/ST-101-160.md:13, :52 · verdicts-r2/ST-060-100.md:22

A third minter now intercepts life-safety on a claimed voice line before any routing. The destination is still a field with two values and no choice: the record adds nonResidentDestination and then says "O31/ST-112 selects channel_org versus platform_pager… production activation cannot infer that choice." Two answers sit on record against each other. The triage calls it a G1-level decision.

In plain terms

A neighbour, a delivery driver or a passer-by calls the building's number about a fire or a gas smell. They are not a resident, so nobody's lease says whose phone should ring. Say whose phone rings.

Recommendation: the channel org's on-call, with the platform pager as a timed fallback. The people nearest the building are the right first ring; we are the right second one.

04

What may each kind of occupant be told by default — a resident, a roommate, a guarantor?

Customer-visibleST-105 / ST-107 · verdicts-r2/ST-101-160.md:7, :9

The enforcement is built: every key carries a data class, the per-role grant table exists, an unpermitted read refuses role_not_permitted, and SMS never soft-verifies an identity from a name-and-unit statement. What is missing is the contents — the record says in terms that "default grant contents remain Fede/Gera's decision", so five probes are unasserted until you fill the table.

In plain terms

A guarantor — usually a parent — rings and asks the balance. A roommate who is on the lease asks the same. Right now nothing says whether either of them gets a number, so the machine has a lock with no list of who holds a key.

Recommendation: tight default now, then the grid. An over-tight default produces a call to a human; an over-loose one produces a disclosure we cannot take back.

05

Looking for a PMS login, does a building's own general one beat the company's job-specific one?

Customer-visible in the collision caseST-117 / ST-118 / O16 · verdicts-r2/ST-101-160.md:19, :20

The resolver is written and returns its fold order as a field — and the registry then says "O16 selects the order… absent decision refuses pms_fold_order_required". So today the lookup refuses rather than picks. The founders ruled which PMS account, and nearest-wins for settings — never a contest between a node and a role slot.

In plain terms

Two logins could answer one question: a general one saved on the building, and a leasing-specific one saved on the company. They usually agree. When they do not, the wrong rule sends that building's data to a different customer's database.

Recommendation: node-major. It is the same rule as settings, and its failure mode is a stale credential rather than a cross-customer read.

06

May a customer close their own company account, and is there a grace period before their phone numbers are released?

Both riders strongly customer-visibleST-132 / O37 · verdicts-r2/ST-101-160.md:34

The archive itself is written: an inventoried staged operation, addresses released, phone and mail attachments ended, other orgs' engagements untouched, unarchive as a fresh forward step. Its riders — who may call it, and whether there is a window — are inputs that refuse archive_policy_required when absent. Fede put org lifecycle on the super-admin surface ("PropFlow super admins are just us") but never barred a customer's own admin. The grace window has zero hits anywhere in the record.

In plain terms

A customer leaves. Someone clicks archive and their phone numbers go back in the pool. Say whether that someone can be them, and whether anything happens between the click and the numbers being gone.

Recommendation: staff only, with a suspension window. Releasing a phone number is the one irreversible act in the whole sequence, and it is the one a customer would do by accident.

07

When do we write the UI spec the org picker and its links are waiting on?

Owner and timing already ruled2 FAILsST-134 / ST-135 · triage/ST-101-160.md:24, :25, :54

These two are FAIL, not partial, for one reason: the file they test — ui/ui-spec.mdhas never existed on any branch, while five notes files cite it. Everything in it is unwritten: the guard that stops you unchecking the last row, the empty-vs-everything distinction, whether a link round-trips, push-versus-replace, the org token in the URL. You already ruled the owner (us) and the timing (end of the architecture phases) on 2026-09-09. The triage records the rest as "Gera to schedule". Only the date is owed.

In plain terms

Not who, not whether — just when. Anyone reading the record today sees two red cases and assumes the design has a hole in it, when what it has is an unscheduled document.

Recommendation: name a week at the end of the phases and stamp it on the record now. A dated placeholder stops the file reading as a gap in the design.

08

On a dashboard covering buildings you run and buildings you only hold reports on — one number or two?

Customer-visible2 FAILsST-175 / ST-182 · verdicts-r2/ST-161-220.md:17, :24

Both are FAIL. Nothing in the record states a combined headline, its arithmetic, or a provenance marker: basis appears once as an unenumerated field on a payload, and mixed appears nowhere. Sean put a held-not-run building inside the holder's roll-up, then two turns later explicitly deferred the rule: "as long as the property level shit is dialed, then you can figure out how it rolls up."

In plain terms

Half the buildings report to us monthly. Put them in one occupancy figure and a customer reads a number as today’s when part of it is six weeks old — and acts on it.

Recommendation: one blended number, marked mixed, with the reported as-of date on the tile. A number that says how fresh it is beats a number nobody is allowed to add up.

09

Is there a maximum number of companies a person can have selected at once?

Mostly cost, not customer harmFAILST-180 · verdicts-r2/ST-161-220.md:22

FAIL: no cap exists in either file. MAX_SELECTED_ORGS = 8 lives only in the stress rows and in the UI spec that was never written; the live selection rule has one refusal and it is about membership, not a bound. You own multi-org selection and have said numbers — "five orgs and five properties selected" — but as illustrations of the shape, never as a limit. You do set caps when asked one directly; nobody asked this one.

In plain terms

Every company you tick costs the machine another full set of lookups. Tick twenty and one page load does twenty times the work. Either we stop them at eight and say why, or we let them tick all of them and show the count on screen.

Recommendation: cap at 8 with a named refusal. It is the number already written down, and a limit you can read beats a page that gets slower the bigger the customer.

10

Can "watch but never reply" be set on a phone number itself, or only on a building or company?

Customer-visibleST-203 · notes/decided-2026-09-08.md:13 · verdicts-r2/ST-161-220.md:45

The behaviour is fully written — observe stores the draft it would have sent, the human reply, and a diff; nothing escapes; observe on a life-safety function is refused outright. Placement is deliberately reserved. decided-2026-09-08.md:13: "if someone genuinely wants 'everything on this number gets this policy', that is a NEW question for Gera, not an inference either session may make." Nothing since reopens it, and the design says it has not activated the line-level variant.

In plain terms

A new customer wants us to shadow their calls for two weeks before we answer anything. Do they switch that on for the phone line — one place, one switch — or building by building?

Recommendation: node only. Routing values and policy have been kept apart on purpose; a number that carries policy is the thing that quietly makes the ladder two ladders.

11

May two buildings that share one phone line use two different PMS logins?

Mostly storage-shapeST-38 · verdicts-r2/ST-001-059.md:57

The record contradicts itself and the conflict is annotated rather than settled. The case asserts the refusal across two buildings behind one shared line; the new rule legalises exactly that"a shared number may serve a1/account-A and a3/account-B when each target and function resolves exactly one" — and says in terms that the case's broader assertion is "retained with an explicit scope qualification, not silently claimed." The original founder rule is narrower: "two PMSs behind one number" refused as a client.

In plain terms

One number answers for two buildings whose records live in two different systems. Refuse it and a customer mid-migration cannot use one number. Allow it and one wrong row sends a caller's data to the wrong database.

Recommendation: allow the per-building subset, and correct the record. The unambiguous case is real and useful; what should stay refused is two credentials answering one question.

Where this comes from

Nothing on this page is decided. Answers are per person: yours is yours, and each option shows who picked it. Change your mind by clicking again — the trail keeps both.

PropFlow Docs