Decision page · 2026-09-08 · for Gera and Fede · research at propflowai@d0bed136d3

Settings placement: criteria, inventory and the five decisions

Update, 2026-09-17: Property.emailShadowMode, Property.smsShadowMode and scripts/set-property-sms-shadow-mode.ts, listed below as existing knobs, were deleted by PR #9162 — read every mention of them on this page as history, not current fields. Staff notices now always reach the real recipient and tour texts are always sent, with no per-property shadow gate.

The settings pages are "pretty vanilla" (Gera) and the product is about to grow policies, rules, prompts, flags and deciders. The open question with Fede is where each of those lives: one of the four settings levels, the property detail page, or inside a module. Two read-only sweeps of the codebase at d0bed136d3 (after the four-level split, #7324 and #7326) produced this page: an inventory of every knob that exists today and where it is, and a set of placement criteria applied to about 95 current and proposed knobs. The short version is that the codebase already contains most of the answer, and that a good part of what exists is stored at the wrong level.

What each page would look like

Wireframes of the recommendation, each with a dropdown for the choice underneath it. Field names are the real knobs from the inventory below; the values are illustrative sample data, not any account’s real configuration.

First, the gap: three places already hold building configuration

Before choosing where anything should go, this is where it is now. All three of these are live today.

1 · Account — you

2 · Organization — your company

3 · Property — one building

4 · Admin — PropFlow staff

The end state: every level, every card, every field

2026-09-08. Gera: “We want the end state of this product — everything exactly as it should look, even if the logic isn’t connected. Unbuilt features greyed out with an ⓘ saying coming soon.” Six domain passes (identity & channels · leasing & tours · maintenance, vendors & turnover · renewals & collections · people, team & notifications · autonomy, compliance & admin), each grounded in the codebase, merged by level. Every field is marked exists or coming soon. Hover a row for the one-line reason and the code it points at.

Where is it decided? The shared-resource binding model

Your calendar and phone-number questions are the same question. A shared resource is provisioned at one level, owned at another, bound at a third, and sometimes personal. Today the four resources landed at four different scopes by accident; this is the deliberate model.

Two corrections from the identity pass, both verified: the tour calendar is read from a per-building Outlook connection today (the person-level one is written but never read), and PMS credentials are keyed per user, not per company — the same misfile as company name. One bug the pass reported was already gone by the time this published: onboarding used to show every new customer the literal +1 (844) 510-1007 — one customer’s line — as “their” number; #7304 removed it the same morning and a test now forbids any phone number on that step. The other bug from this pass, the global text/email switches writable by any role, is closed by #7365 (staff-only on write).

The Autonomy ladder, row by row

One shared enum, the same four words on every row. The rung is a projection over fields that already exist — no new column per row. Customers stop at Act with approval; Autonomous is unlocked per building by PropFlow after a soak.

The ceiling model. Platform ceiling (PropFlow staff, per company × row) → company cap (org admin, also carries the default for new buildings) → building value (PM). Every row badges its source. Rungs above the cap render greyed with ⓘ “Capped at Act with approval by Camellia Admin”. Under the ladder sits the one spend line: Clara may approve up to $500 per job without asking, with turnovers as a sub-line. Shadow / live / test shows as a chip from Admin-owned state, never a control.

Ceilings versus defaults

The difference between a value a parent locks and one it merely pre-fills is the difference between a compliance posture and a suggestion.

The pages

The event catalogue — who is told what

Every event that can notify someone, across all modules. The default recipient is a role; the company sets the default, a building may override. This is the table the Notifications routing rows are built from.

Coming-soon governance: how the greyed rows stop lying

Three ad-hoc “coming soon” conventions exist in the product today — a select label, a pill, an accordion body — and no registry. The design and the product drift the moment they are two documents. So: one typed settings registry in code, from which the settings pages, the search index and this wireframe are all generated.

1. Declare. One row per field: id, level, card, label, control, inheritance chain, mode (ceiling / default / fixed), status (live / coming soon / staff only), which field stores it, which route writes it, since when, and the decision page that decided it. A row with no decision link fails lint.
2. Show. A coming-soon row renders through one component — greyed control, real label, ⓘ with the one-line why. A page cannot render a field the registry does not list.
3. Gate. Three drift tests: every rendered field has a row; a coming-soon row has no writer (the same fence that protects hand-off mode today); a staff-only row renders only under Admin.
4. Graduate. One PR flips the status, adds the writer and the reader; the tests refuse one without the other. Nobody un-greys at runtime — no flag, no env, no toggle. The wireframe re-renders from main, so the design cannot say one thing while the product says another.

The decision register

Status 2026-09-08 — CLOSED. All 22 decided. Ten by button, twelve in Gera’s own words (the decisions page). Two reversed the recommendation on this page: seats (row 8) and rental criteria (row 9), the second toward more caution than was proposed. Each row below keeps its original recommendation underneath the answer, so a reader can see what was rejected as well as what was chosen.

Every genuinely open choice the six passes surfaced, deduplicated, each with a recommendation. Answer by picking.

What onboarding must collect — and where it lands

Onboarding is the first write, not a separate store. Nothing should be enterable only at onboarding, and nothing required before Clara runs should be settable only by a script.

• Collected today: company name (lands on the user row), company type and size, PMS credentials (per user), imported buildings and exclusions, one inbox and one calendar bound to the first imported building, and a “your number” that is actually one customer’s line.
• Required before Clara runs but set only by scripts today: a phone number per building, the PMS account binding and Clara’s seat in it, the delivery path, timezone, text-consent model, sender identity, the escalation owner, demand party, eviction counsel, assistance programmes, the operational-sender lists.
• End state: the channels step becomes a per-building table — number auto-assigned from the pool, inbox connect, calendar pick — one consent for forty buildings, then a picker each. Every collected value then lives in the cards above with a Set here badge.

Verification note. Each domain pass cited file and line for its claims about current code; the integration re-read a sample from every pass (the settings resolver’s “no global fallback” header, the offer-only lead time, the absent screening criteria, the absent vendor insurance fields, the second vendor chain in turnover policy, the delinquency threshold saved to two fields, the collections review-gate ruling, the Colorado-only jurisdiction registry, the stuck-matter Slack surface, the silent no-owner paths, the nag constants, the user-gated settings route, the shadow-equals-off comment, the per-building calendar read, the per-user PMS credentials, the onboarding number literal, the timezone with no writer) and found every one verbatim. Where an agent inferred rather than read, the row says so.

The big picture: how not to become AppFolio

Written 2026-09-08, at the point where the surface is about to be filled in. Onboarding new companies is the driver, and the storage shape is the part that stops being changeable once real customers have values in it.

What the incumbents get wrong, and why it is one decision away

AppFolio, Yardi, Buildium, RealPage and Entrata all arrived at the same place by the same road: every module grew its own setup screen, owned by its own team, and nobody merged them. The result is a settings tree three or four levels deep where the same idea — who gets notified, office hours, late fees — is configured in two or three places under different names. That is an industry pattern rather than a claim about any one screen, and it is why each of these vendors sells implementation consulting and why “where do I turn that off?” is a top support category.

Three specific failures. PropFlow is one decision away from each:

• No inheritance. Property settings are copies. Set up forty buildings and you have forty independent copies; change company policy and you edit forty times. Nobody can answer “which buildings are different from the default, and why?”
• Config lives where the feature was built, not where a customer would look for it. This is exactly the renewal-versus-maintenance autonomy split above.
• Facts and decisions are mixed together. A fee schedule sits beside “auto-post late fees”, so changing one quietly changes what the other means.

What to steal, and whether it fits us

The one rule

“If it decides what Clara does it goes in Settings; if it describes the building it goes on the building page” is right in spirit but loses every argument at the edges, because Clara reads almost everything. Pricing decides what she quotes. Pool hours decide what she says. Sharpen it into a test you can run in your head:

That test picks the surface. A second one picks the level, and it is the one that answers “whose notification is this?”:

Worked: the word “notifications” means two different things

This is the case that trips everyone, because both things are called notifications and both are real.

The Property Settings page already knows these are two different things — its own subtitle says “Reminders for you” are emails about your to-dos and “Who else gets notified” are emails to other people. It splits them into two blocks on one card. The correction is small: the first block moves up to Account, the second stays.

A trap on the same test, worth naming. A company policy earns a place on your Account page only if it constrains you personally — two-factor, because you have to enrol; a cap on your own reminder cadence, because it bounds a setting of yours. It does not earn a place merely by being a rule you are subject to. Resident quiet hours are the clean counter-example: they are a real company policy, but changing them alters what residents receive, not what you do. Run the level test on them and the answer is “everyone at this company”, so they live at Organization with a per-building override for state law — and never on a personal page, where their presence would imply they are yours to bend. This corrects an earlier draft of the Account wireframe above, which listed them under “set by my company”.

Honest counter-argument: you might genuinely want more nagging on one difficult building. That is fine and needs no special case — Account holds the default, a property may override it, exactly like every other inherited value. What is wrong today is that there is no personal default to inherit from.

Applied to real knobs

Settings search: yes, at card level, and not until scope leaves the cookie

Removing the settings rows from ⌘K on 2026-09-07 was correct, and the code comment states the law to build to: a search result may only exist if its link fully determines what renders. A row that lands on a page which then consults a cookie to decide what to show is a lie, and a support ticket. Today only /settings/account is a real address; /settings resolves to Organization or Property from propflow-property-filter — and that is the global picker shared with Dashboard, Leasing and Maintenance, so this is not a settings-local problem.

1. Put scope in the URL. /settings/organization/<card> and /settings/property/<id>/<card>. Bare /settings keeps today's follow-the-picker behaviour so the sidebar link is unchanged. Landing on a property settings URL sets the picker rather than reading it — the same way opening a building page already tells you which building you are in. The building page is deep-linkable; settings is the odd one out.
2. One settings registry, in code. Every knob declared once: id, label, level, card, keywords, default. The cards render from it, the inheritance resolver reads it, and the search index is generated from it. The hand-written index (24 pages + 18 sections) is fine for pages and will rot the day it has to track ninety-seven knobs. The registry is also what makes the inheritance badge and the audit trail nearly free.
3. Index cards, not fields. A result reads Calls › After-hours and voicemail, with a chip naming the building or Organization. When no building is picked and the hit is property-level, the row says Property setting — choose a property and the second step is the building list. Never guess a building.
4. Field-level search later, and only with scroll-and-highlight. A field hit that dumps you at the top of a twenty-row card recreates the same broken promise one level down.

Cost: the route change and picker sync is a day or two; the registry is the real work, and you need it for inheritance regardless; generating search rows from it is an afternoon. Field-level search is a week not to spend yet.

Decide now, defer the rest

Before the surface fills in — these get expensive or impossible once companies are onboarded:

1. Apply the rule. Move renewal autonomy into the Autonomy card, demote module-page config to read-only mirrors, split the vendor roster from the vendor dispatch decision. Do it before customers learn the current homes.
2. The store inherits, it never copies. One table keyed by scope kind, scope id and key; absence means inherit; the resolver walks property → organization → platform. Do not write resolved values onto each property for speed. That is the incumbent mistake, and in practice it cannot be undone.
3. Stable string ids for every knob. They end up in URLs, audit rows, search entries, exports and support calls. Renaming one after launch is a migration.
4. Scope in the URL. Cheap now, painful once links are sitting in customer emails.
5. Ceilings at the platform level, not just defaults. One autonomy enum used by every module, with a platform row that caps it.
6. Audit from day one — who changed what, from what, to what, when. Trivial against one writer now, impossible to reconstruct later, and the first “why did Clara do that?” call will ask for it.
7. Convert the hard-coded early-customer behaviour into rows (the categories the customer-identifier fence already tracks, plus the name and timezone sweep in the section below). Every one of those is a knob that does not exist yet, so the inventory is not really ninety-seven until they are counted.
8. Decide whether a level will ever sit between company and building — region, portfolio, owner. Judging by how management companies are structured, it will. Do not build it; write the resolver as a walk up a list of scopes rather than two hard-coded lookups.

Safe to defer, because none of it touches the store or the ids: field-level search, bulk apply-to-these-twelve-buildings, property templates for onboarding, change-history UI, per-role card visibility, export/import, a settings API.

Never build: per-unit settings, and a second writer for anything.

The decisive pass: every knob adjudicated

2026-09-08. Gera: “I don't want to tell you to do individual things … go through each one, break it down, validate the current designs.” This is that pass. It applies the two tests and does not relitigate them. Claims marked verified were read in the codebase; claims marked inference are reasoning from the business.

The building page: what belongs there, and the three tells

Asked directly of a live building page (/properties/<id>) and its three configuration cards: turnover policy, vendor job reference, renewal policy. None of the three belongs where it is — and each is wrong for a different reason. That is what makes a single “move it to Settings” answer useless and a policy necessary.

The policy, in one line and three tells

In practice nobody adjudicates from the principle; they notice a smell. These are the three that catch essentially every misfiling in the inventory:

1. A rule filed in the knowledge store. PropertyKnowledge is what Clara says; a rule is what Clara does. Anything in that store which changes behaviour rather than an answer is in the wrong house. Catches: turnover policy, renewal rent rules, late fee and grace days.
2. A fact about something other than the building. The right kind of thing attached to the wrong subject. A fact about the PMS account belongs to the company; a fact about a person belongs on the person. Catches: vendor job reference, Clara's PMS display name, delivery path, handyman quiet hours.
3. An autonomy switch inside a policy editor. If one card holds both “max increase 8%” and “do it without asking”, the second one belongs on the ladder. A policy says what good looks like; a rung says how far Clara may go alone. Catches: renewal autonomy, and it is how the maintenance/renewal split happened in the first place.

A fourth tell, from the level test rather than the surface test: the label says “you” or “me” but the value is keyed to a building — which is how a personal reminder preference ended up stored once per property.

What survives on the building page after all three tells are applied: address, unit list and status, occupancy and the metric cards, pricing and fees, concessions, the knowledge sections Clara quotes, office hours and holidays, and the People card — who manages, who fixes, who owns. Every one of those reads as a sentence about the building. Nothing left on it instructs Clara.

1 — People are not settings

The question “where does the maintenance tech go?” has no satisfying answer because the thing being placed is not one kind of thing. Verified: a person responsible for something at a building is stored four different ways today.

The decision: a person attached to a building is a role, never a setting. Settings may hold a routing decision — when this happens, page whoever holds that role — but the person lives once on the identity spine and every notification resolves through it at send time. Three shapes cover every “who” in the inventory:

• Role — a human who owes an answer and may need permissions. Person + PersonRole (staff) or Person + VendorMembership (crew). PM, on-site manager, maintenance tech, handyman, escalation owner.
• Contact record — an outside party you deal with but do not manage, stored like vendors are (a company plus named contacts). Owner/landlord, eviction law firm.
• Genuine string — an inbox nobody owns. The property inbox, an accounting@ alias, an assistance-programme address.

The test for the third row: if this address stopped being read, would a specific person be at fault? If yes, it is a person wearing an email address. Most of today's strings fail it.

What the strings already cost, in code we have

• Clara cannot recognise her own tech. Verified: classify-origin-thread.ts:26 says “Deliberately NOT matched: the property-level maintenanceTechPhone”. A phone string is not an identity, so an inbound text from the tech cannot be tied to them. The cost is already paid, in a comment explaining why it must be.
• “Owner” means three different things. Verified: demand-context.ts:13 — “Property.ownerId is a Better Auth userId for PMS credentials, not a [landlord]”. The word covers the PMS-credential holder, the escalation owner (staff), and the actual landlord. Row 69 “owner escalation recipient” is the second of those, and is the same field as row 13.
• The code already asked for the fix. Verified: the doc comment on escalationOwnerEmail (types.ts:2999) says owner resolution “should CHAIN INTO resolvePmContactEmail as its default rather than growing a second address ladder of its own.” That resolver exists (pm-contact-email.ts:44). One resolver, role → that person's contact → the property inbox, is not a new idea here; it is the idea the field's own author wrote down and did not get to build.
• The spine is already ready. Verified: VendorMembership carries personId, role, propertyIds, isInHouse (ADR-0033 collapsed VendorCompany.isInHouse into this row, making it the single source of truth for in-house crew), quietHours, availability, startedAt and endedAt. Everything the handyman needs already exists as a row. The property simply does not point at it.

In plain terms, what strings cost you: the tech changes their number and you edit every building and miss one, which then pages a dead number silently. One person covering six buildings appears six times with nothing linking them. A phone string cannot be told “you may approve up to $500”, which is precisely what the Act with approval rung needs. The audit trail says an email address instead of a name and a role. And when someone leaves, nothing ends — the string keeps getting paged.

The model

The building page gets a People card — one row per role, each pointing at a real record. It is the canonical writer for who.

Settings holds routing rows, not addresses. Each row is event → recipient, where the recipient is a pointer: a role (whoever holds it at send time), a specific person, or an inbox. Escalations default to the PM role; lease-signed goes to accounting; the weekly owner report goes to the owner role. Every row badges its inheritance like any other setting. Migration is uneventful: backfill each string into a person and a role, let the resolver fall back to the legacy string until nothing reads it, then delete the field. No customer-visible change on day one.

2 — The five families you named

Follow-ups and chases: one control, five lanes

They are one knob wearing five hats. Every lane is the same shape — attempts × interval × channel × stop-when. What differs is who is on the other end and whether the lane is legally regulated. So: one Follow-ups card at Organization, one row per lane (prospect inquiry, re-engage, tour confirm, post-tour, vendor chase, renewal chase, collections chase), each expandable, each overridable per building. Above them, one contact ceiling at Organization only, with no property override — that is the company's compliance posture, and a per-building override is how a complaint starts. Post-tour follow-up is a lane of this, not its own knob. PM action reminders are not a chase; they nag your own staff, and they are handled below.

Money: one ceiling, and two things that are not ceilings

One autonomous-spend ceiling: Clara may commit up to $X without asking. The turnover cost cap is a sub-line of it, not a second ceiling. “Big-ticket items” needs no knob at all — it is simply anything above X, which is the approval rung doing its job. Two imposters: the delinquency threshold is measured in months and gates whether a renewal offer goes out, so it is a renewals policy rule, not a ceiling; and late fee and grace days are in the lease whether or not PropFlow exists, so they are a building fact.

Clara's identity: three things, not one

Brand (what she calls herself, sender name, tone) is Organization — every channel, every building. Lines (phone numbers, PMS display-name binding, from-address) are provisioned facts, shown read-only and never typed. The greeting line should not be a field at all: it is brand plus building name, derived. An editor there invites free text into a spoken prompt that is evaluated.

Delivery and routing: this is Integrations, and most of it is org-level

The delivery path and Clara's PMS display name are properties of the PMS account, and one database equals one organization. Both move up to Organization, inherited down, overridden only where a building is bound to a different account. The property inbox and the listings URL are facts about the building. What remains on Property Settings is bindings, all read-only.

Hours: two concepts, do not merge them

When the building is open (office hours, holidays) is a fact — building page. When Clara may contact people (resident quiet hours; handyman quiet hours, which belong to the person and follow them across every building) is a protection rule — Settings. Scheduling capacity (duration, lead time, buffers, weekday policy) is an instruction to the booking engine. Collapsing them would be wrong because they answer to three different people: the office manager, the compliance officer, and the leasing lead.

3 — What actually changes

Moves

Splits — one row that is secretly two

Right where they are, against instinct

These exist to stop the same argument being had twice.

• Tone and persona stay in code. Every prompt change is a replay-gated deploy, and free text from a customer would bypass every evaluation. At most a company-level enum later.
• Languages are not a knob. Language is per person on the spine, so a building-level toggle would answer a Spanish speaker in English at an “English” building.
• Handyman quiet hours belong to the handyman, not the building. His sleep follows him across every building he covers.
• The contact ceiling has no property override. A busy lease-up will want more touches. That is exactly the pressure the ceiling exists to resist.
• Tour duration is a company default. Most operators run one length; the per-building override is for exceptions, not the rule.
• PMS credentials are org-level. One database per company; two databases means two organizations.
• Assigned properties live on the Team page, not the building. It is a permission scope, so the company owns it and the building page mirrors it read-only.
• Hand-off mode stays visible even though only PropFlow can flip it. A customer who can see the rung understands why Clara is or is not answering.
• Vendor preferences by trade change nothing. Verified: of roughly twenty-six rows marked as inheriting from the company, this is the only one actually built. It is the reference implementation: build every other inherited row to look like it, and migrate it onto the generic resolver last, once that resolver can replay its tests.

Should not exist

The greeting-line editor (derived). Post-tour follow-up delay (a lane of the cadence card). Owner escalation recipient (the same field as escalation owner). The tech phone and the CC as customer fields. The leases-ending digest (its own doc says temporary). Free-text collections tone (enum or nothing). Vendor transfer-first and shadow mode (activation states, not switches). The workflow dispatch allowlist (a cutover flag). Tour buffers (not built — do not build until asked).

4 — Does the four-level design survive? Yes, with two amendments

Account is thin, and that is fine. A level is justified by who feels the change, not by row count, and “only me” is a distinct audience. It is also thin partly because rows were mis-filed onto Property: the reminders row alone justifies the level, and the giveaway is a card headed “Reminders for you” sitting on a per-building page. A useful rule falls out of it: if the label says “you” or “me” and the value is keyed to a building, it is mis-scoped. This is also the first place the chain runs company → account rather than company → property, which is the honest shape for a preference as opposed to a policy.

Organization earns its place, but read today's page as intent rather than state. Its job is to be the defaults level — every inherited row is authored here and merely overridden per building. The honest statement: roughly nineteen designed rows, zero writable, one working inherited chain. Until the organization writer exists, every “from company” badge in the wireframes above is fiction. That makes the sequence binding rather than advisory: organization writer, then the generic resolver, then the cards.

No fifth level. The two candidates are region and PMS account. Region is a permission scope, already handled by assigned properties; PMS account is an integrations binding. What operators actually want for “these six buildings” is a bulk-apply gesture on Property Settings, not a new level. Inference: revisit only if one customer runs several PMS databases or dozens of buildings under genuinely separate regional policies.

The building page and Settings stay two surfaces. Different readers (an agent opens the building page daily; property settings change a few times a year), different provenance badges (facts carry scraped / manual / PMS-synced; settings carry set here / from company, and mixing the two vocabularies is how a scraped fact gets mistaken for a company policy), and different blast radius (a settings change re-routes Clara; a fact change corrects the world). They need one seam, not one page: the People card is the canonical writer for who, and Settings routing rows point at those roles. Link both ways in the header.

Amendment 1 — the Autonomy card holds two things only: the ladder and the spend ceiling. Everything else that drifted onto it is either a rung behaviour or a module policy row. A card with fourteen switches is not a ladder.

Amendment 2 — Admin gets a named watch list for the per-property CCs, holds channel and shadow modes PropFlow staff use to observe a bake. Naming it is what stops those leaking into customer fields, as the escalation CC already did.

Verification note. Claims about classify-origin-thread.ts, demand-context.ts, VendorMembership, resolvePmContactEmail and the single built inheritance chain were read in the codebase today. Two claims from the drafting pass were corrected before publishing: a quoted comment on escalationOwnerEmail that does not exist in the code, and a CC address attributed to a customer's production configuration when it appears in a bench test fixture.

In one screen

• Four levels stay; the rule for which is "whose fact is it". Different per person → User. Same for every building the company runs → Organization. Another building could legitimately differ → Property. No customer may ever see or change it → Admin.
• Settings page vs. property detail vs. module: a knob that changes what a customer hears across channels is a setting; a fact about the building is on the property detail page (Clara cites it, it needs provenance); a policy a PM only changes with the queue in view gets an edit-in-context drawer on the module page and a browse row on the settings page — the same component and API, never two stores. That last shape is already how follow-up cadences work.
• Deciders get one Autonomy card per property, one row per module, a four-rung ladder, and a read-only mirror in the module. Customers set up to "Act with approval"; "Autonomous" is staff-set.
• Inheritance is platform default → Organization → Property, absence meaning inherit, with the source rendered as a badge. It needs an Organization writer first; today the Organization row cannot be edited at all.
• Prompts stay code; customers edit the facts that feed them. Flags and kill switches are Admin only; capabilities are Organization and only ever make Clara do less.
• Bottom-up, for onboarding: the hard-coded → configurable table maps every customer fact still living in code or env (phone routing, the prompt clock, listings sync, the AppFolio subdomain, the company address in a prompt, recipient lists, voice agent ids) to the field and card it becomes; the onboarding checklist is the resulting field list per level — the working spec for the settings pages.
• What is mis-scoped today: Company Name stored per user; "hide from sync" (which deletes data) keyed on a per-user list; three "customer" toggles on Admin Settings that are one global row for every org and writable by any signed-in user; setup-guide state shared by everyone; about 35 per-property behaviour switches — including the hand-off mode, the property time zone and the escalation owner — with no UI at all, each behind its own script.

The five decisions, as multiple choice

Each has a recommendation. The criteria in the next section are what the recommendation is derived from; the applied table further down is what each choice implies knob by knob.

Placement criteria — eight testable rules

From the taxonomy sweep; each rule names a PropFlow example, a counter-example, and what would falsify it.

Each rule is a question you can answer yes/no about a knob. Apply them in order; the first "yes" wins.

C1 — Whose fact is it? (level). If the value would be different for another person at the same company it is User; if it would be the same for every building the company runs it is Org; if another building of the same company could legitimately differ, it is Property; if no customer may ever see or change it, it is Admin. This is the Vercel account/team/project test and it is already CLAUDE.md's "whose fact is this?" (customer-facts-as-data).

• Example: displayZone (how times read to me) → User (UserPreferences.displayZone, AccountSettingsShell.tsx). Counter-example: Company Name → Org, yet today writes User.companyName (OrganizationSettings.tsx header) — a level bug the file itself names.
• Falsifier: find a knob where two users at one company need different values and it sits at Org.

**C2 — Does it change what a customer hears across channels? (settings page vs. elsewhere).** A knob that changes Clara's spoken/written behaviour on more than one channel (voice+SMS+email) is a setting and goes on the settings page for its level. A knob that only changes what an operator sees in a queue stays on the module page.

• Example: office phone / transfer destination (voice, and the missed-call email) → Property Settings "Calls" card (PropertySettingsShell.tsx:231). Counter-example: the collections review-queue filter default → module page (review/page.tsx), never settings.
• Falsifier: a settings-page knob that no outbound path reads (today: AppSettings.setupGuideState — a UI pref on the settings row).

C3 — Is it a fact about the building, or a rule about behaviour? (property detail vs. settings). Facts (address, hours, amenities, fees, phone the public dials, unit count) live on the property detail page under "Policies & Knowledge" because Clara cites them and they need provenance (scraped vs. manual). Rules (how long a tour is, when to auto-approve) are settings. AppFolio/Buildium put late-fee policy on the property record for this reason; the product already split "collections policy" into cadence (setting) and late fee (knowledge) with a scope line (MoneyRulesSection.tsx header).

• Example: PropertyKnowledge.officeHours → detail page (PropertyDetailClient.tsx:983). Counter-example: tourDayPolicy ("can a tour be booked Saturday" — a rule, distinct from "is the office open") → settings (types.ts:13072 says exactly this).
• Falsifier: a fact that must be edited from settings to be honoured, or a rule stored in PropertyKnowledge (today: renewalPolicy, turnoverPolicy — rules living in the knowledge blob; see Risk 5).

C4 — Is it only meaningful while looking at the work? (module page / drawer). If a PM would only ever change it with the queue in view (cadence while looking at 60-day-past-due accounts), it gets an edit-in-context drawer on the module page and a browse-and-compare row on the settings page — the same component, same API, never two stores. This is Intercom/Front's "rules live in the inbox" and Linear's team workflow settings; it is already the product's decided shape (PolicyDrawer.tsx header: "answered by construction rather than by picking one place").

• Example: collections chase cadence → drawer on /collections + Follow-ups card. Counter-example: the account-wide contact ceiling → settings only (FollowupPolicyEditor.tsx showGlobalLimit doc: showing it inside one module "would invite editing it as if it were that module's").
• Falsifier: a policy editable in a module drawer that is not visible on the settings browse page, or vice-versa.

C5 — Does it decide whether Clara acts or asks? (the Autonomy card). A knob whose only effect is who decides (Clara / Clara-then-approve / human) is a decider, not a policy, and every decider for a module sits together in one "Autonomy" card at Property level, read-only mirrored in the module. A threshold that feeds a decider (auto-approve $) is a decider parameter and sits in the same card.

• Example: aiAutoApproveThreshold (PropertySettingsShell.tsx:544), handoffMode, capabilityStage.maintenance. Counter-example: tourDurationMinutes — changes the offer, not the decision → Leasing card.
• Falsifier: an autonomy decision reachable from two cards, or one that has no property-level switch (Art. IV.3).

C6 — Is the default the company's and the exception the building's? (inherit). A Property knob inherits from Org when (a) most buildings of one operator share the value and (b) an org-wide change should propagate to un-overridden buildings. Then the property card shows the effective value with an "Inherited from Organization" badge and a "Reset to organization default" action; an override is a stored value, absence is inheritance. Vercel env-vars-per-environment and Linear team-overrides-workspace are the model; resolvePreferredVendors is the in-repo precedent.

• Example: tour duration, application link, PM-reminder cadence, auto-approve threshold, follow-up cadences. Counter-example: office phone, emergency phone, Twilio numbers, Outlook calendar — physically per building, no meaningful org default; and handoffMode — an activation Fede makes one property at a time (Art. IV.6), so an org default would violate "blast radius is per property" (VII.3).
• Falsifier: a property override that survives an org change it should have followed, or an org default that arms a real property Fede did not name.

C7 — Can a customer be trusted with it without a soak? (Admin vs. Org "capabilities"). If flipping it needs the bench, a replay, or Fede's go (Art. IV.1, IV.6), it is Admin (Access Inspector arms/kill switches), never on a customer page, even a per-property one. If it is a product capability the customer bought or opted into (module on/off, a channel enabled), it is an Org "capabilities" toggle — customer-facing, but it scopes, it does not arm.

• Example: kill.tourPipelineV2 (arms-registry.ts:509) → Admin. Counter-example: enabledModules['leasing.renewals'] — a customer-legible capability that today is platform-wide and admin-only (/api/admin/modules header: "the flags are platform-wide, not per-organization").
• Falsifier: a customer page that can arm a send, or an admin page holding a knob a customer must set to onboard.

C8 — Is it a one-off action or a per-record field? (never settings). Connect/disconnect an inbox, import contacts, re-sync, delete property, "mark this tenant do-not-contact" are actions or record fields; they live where the record lives. A settings page holds standing values only.

• Example: "Import contacts" → property detail (ContactImportModal). Counter-example that is borderline and stays: Outlook Connect/Disconnect on Property Settings — it is an action but it produces a standing connection whose status is the setting (PropertySettings.tsx calendar/email status).
• Falsifier: a settings card with a primary button that is not Save/Reset/Connect.

What the codebase already says

Most of the "open" question is already decided in data — this is the evidence table the criteria were derived from.

The upshot: the product already has the shape of the answer — org default → property override for vendors, org-scoped policy edited in module context, one autonomy switch on the property, prompts as code with data variables. What is missing is (a) a general inheritance resolver (only vendors have one), (b) an Organization writer, and (c) a consistent rule for which surface shows what.

Applied table — about 95 knobs, current and proposed

Level: U/O/P/A. Surface: SP = settings page for that level · PD = property detail (Policies & Knowledge) · MP = module page (read-only mirror) · DR = drawer inside a module (edit-in-context, also browsable on the settings page) · AI = Admin Access Inspector. Inherits: O→P = org default, property override with badge and reset.

Level: U=User, O=Org, P=Property, A=Admin. Surface: SP=settings page for that level, PD=property detail (Policies & Knowledge), MP=module page (read-only mirror or filter), DR=drawer inside module (edit-in-context, also browsable on SP), AI=Admin Access Inspector. Inherits: O→P means org default, property override with badge+reset.

Clara voice & messaging

Leasing

Maintenance

Renewals

Collections

Conversations

Notifications (who is told what)

Integrations

Security / team

Billing / plan

Admin / platform

Row count: ~95.

The recommended model in detail

(a) Inheritance chain and display

Chain: platform default (code constant) → Organization → Property. No unit or user tier for behaviour knobs — a unit-level exception is a fact on the unit record (C3), and a user-level one is a preference (C1), never a Clara behaviour. This matches today's vendors chain and settings-resolver.ts's "property → hardcoded default", with one new middle rung.

Mechanics, so the resolver stays one function:

• Storage stays per-row (OrganizationSettings gains the leasing/maintenance/notification fields marked O→P above; PropertyLeasingSettings etc. stay). Absence is inheritance; a stored value is an override. No inherit: true sentinel — undefined already means "use the default" everywhere in these types.
• One resolvePropertySetting(propertyId, key) in src/lib/domain/properties/ returning { value, source: 'property' | 'organization' | 'default' }. The source is what the UI renders as the badge, so the badge cannot lie about what the runtime used (the same reason resolvedLeasingSource is computed by the resolver, not the UI — leasing-settings/route.ts comment).
• Display: on the property card, field shows the effective value; helper text "Inherited from Organization" (or "PropFlow default"); editing stores an override and the helper becomes "Overrides organization (Reset)". On the org card, a count chip "3 of 12 properties override this".
• Only knobs whose row says O→P inherit. Things marked "—" (phones, calendars, Twilio, handoffMode) never read the org row, so an org edit can never arm a property (C6 falsifier).

(a2) The company decides WHICH keys a building may override — so the resolver must return permission, not only value

Added 2026-09-09, from the founders’ thread. Fede: “right now the policies are on the property level… I don’t know if you want to rip that out and make it its own thing on the nav or nested under Clara… where you could visualize the global settings and then be able to visualize property.” Gera’s answer to the second half: an overridable key at property level shows “a little green indicator that it’s allowed to override by property firm” and is editable; a non-overridable one renders greyed.

That is not a styling note. It changes the read path. { value, source } answers “what is in force and where did it come from”; it cannot answer “may I write this here?” — and the screen has to answer that before it can decide whether to render a control or a lock. The management firm is the rule book: it sets quiet hours, pet fees and policies, and which of those a building may depart from. So:

• The resolver returns permission, and it takes TWO fields, not one. My first draft said writableHere; the architecture side is landing the sharper split and it is the one to build against — resolveEffective(ctx, path, key, {writeTarget}) returns a writeDisposition carrying, among others, rungOverrideAllowed (does the FIRM permit this rung to override this key — derived independently of who is looking) and mayWrite (that AND the registered placement AND this actor’s own grants), plus permissionSource for provenance and reason for the refusal text. Render the green indicator off rungOverrideAllowed; enable or disable the control off mayWrite. Collapsing them into one field is a real bug, not a simplification: a key can be overridable in principle while this person still cannot write it, and a single field would have shown a padlock on an overridable key and told the reader the firm had locked it when it had not. Computed by the resolver either way, never inferred by the UI — a locked key that renders editable is a broken promise the moment someone hits save. (Names near-final, not final: the rows were uncommitted 2026-09-09.)
• Three display states, not two. Set here (this building authored it) · From company — you may override (the green indicator; inherited and editable) · From company — locked (inherited, greyed, no control). Today’s page has only the first two, so every inherited row on it is implicitly claiming to be overridable, which is now a claim the design must stop making by default.
• The lock list is itself a company setting — a per-key “buildings may override this” switch on the Organization card, defaulting to allowed. Otherwise the firm’s rule book is a code constant and no customer can be strict. It routes through the key slot’s existing writerPolicy rather than a parallel switch beside it: one source for permission, with the value constraint staying where it already lives.
• Ceilings are not locks. A ceiling clamps a value the building may still set (row 6: the company cap wins, the building clamps); a lock removes the control. Both exist and they read differently on screen — a clamped field shows its own value with a cap badge, a locked field shows the company’s value and no field at all.

(b) Deciders — argue for one Autonomy card per module at Property, with two amendments

The instinct is right and the constitution forces it: IV.3 wants exactly one per-property switch, visible on the property's admin page, and VII.4 wants test/shadow/live on the record. The codebase is already converging: handoffMode (one switch), capabilityStage (per-module off/shadow/live), aiAutoApproveThreshold + autoDispatchCostCap (one spend ceiling).

Recommended shape — one "Autonomy" card on Property Settings, one row per module (Leasing, Tours, Maintenance, Renewals, Collections, Conversations), each row = a 4-step ladder Off / Suggest / Act with approval / Autonomous plus that module's decider parameters (spend ceiling, delinquency threshold, voice-call-on-offer). Mirror: a read-only "Clara here is: Act with approval" pill in each module page header that links to the card (C4: read-only mirror, never a second writer — the two-place problem Gera named).

Amendments that matter:

1. Not every rung is customer-writable. "Autonomous" (and any rung that arms a send at a live property) is Fede's activation (IV.6). The card shows the current rung to the customer; the write for Off↔Suggest↔Act-with-approval is a customer action; Autonomous is staff-only and greyed with "Ask PropFlow to enable". That preserves the one-switch rule (one field, one card) without handing customers an arm.
2. Map the ladder onto what exists instead of inventing a new field. Off = capabilityStage: 'off'; Suggest = 'shadow'; Act with approval = 'live' + review-queue gating (ADR-0125 collections, vendor outreach first-dial); Autonomous = 'live' + handoffMode: 'autonomous' / the module's send arm. Today's scattered booleans (escalatedTourBookingEnabled, tourRequestSmsEnabled, autoSyncEnabled) become rows of this ladder or collapse into it.
3. Org default: only for the parameters, not the rung. Spend ceiling inherits; the rung does not (VII.3 "blast radius is per property").

Against a per-module page card as the writer: it would put an arm next to a queue where a PM toggles under pressure, and it re-creates the "two places" problem. Against a settings-only card with no mirror: the review queue's "why is this here?" already needed inline copy (review/page.tsx header) — the mirror answers that.

(c) Prompts

• Prompt text = Admin/platform code, as today (VII.7; elevenlabs-deploy-lane.ts hard block). No customer-editable prompt text, ever — it bypasses evals.
• Per-property prompt variables = data the prompt interpolates, and they already are: {{property_office_hours}}, {{pm_phone_number}}, {{property_policies}}, the hand-off directive (handoff-policy.ts header spells out why). The rule: a customer never edits a variable as a variable; they edit the fact or setting that feeds it (office hours on the detail page, transfer destination in Calls). The only new "prompt-shaped" customer fields worth adding are bounded, eval'd variants: greeting line (short text with a length cap and a fair-housing screen like fairHousingScreenFailedAt on knowledge sections) and a tone selector from a fixed set — both on a Property "Clara" card, O→P.
• Admin surface: a read-only "what Clara is told about this property" rendering (the resolved dynamic variables) on the property's admin view, so staff can see the effect without a replay. voice/personalization/route.ts already computes it.

(d) Feature flags vs. capabilities

• Feature flags / arms / kill switches = Admin only, in the Access Inspector, catalogued in arms-registry.ts (already enforced by arms-registry-coverage.test.ts). Never on a customer page, even labelled nicely. Today's /admin/settings SMS and vendor-email toggles are global kill switches wearing capability labels — move them to the arms tab and delete the page's toggles.
• Capabilities = Org, customer-facing, and scope rather than arm: modules enabled (today platform-wide enabledModules — migrate to Organization.settings.enabledModules, which already exists on the type), channels enabled (SMS/email as permission to use, with the per-property shadow state still staff-controlled), languages. Rule of thumb for the reviewer: a capability off makes Clara do less; it can never make her send more.

(e) What never belongs on a settings page

1. Facts about the building — hours, amenities, fees, utilities, neighbourhood, phone the public dials (detail page, with provenance).
2. Per-record fields — a tenant's language, do-not-contact, a vendor's quiet hours (VendorMembership.quietHours), a unit's availability.
3. One-off actions — import, re-sync, delete, backfill, "send now".
4. Arms and kill switches (Admin only).
5. UI state — setupGuideState, askClaraState, dashboard layout (per-user prefs, stored on the user, no page).
6. Anything with no reader: the "manual" leasing source is offered disabled for exactly this reason (leasing-settings/route.ts); the rule generalises — a setting ships only with its consumer (hot rule 13).

What is mis-scoped today — the inventory's observations

From the inventory sweep of the four settings pages, the property detail page, every module drawer, the arms registry, env-only knobs and the data model. File and line references are in the sweep and were read at ad990d3cb5.

Added 2026-09-08 — a personal preference stored per building. “Reminders for you” (whether to be reminded about pending approvals, how many, how often) is pmActionReminders on the property’s leasing settings. It is the one thing on the settings surface that is about a person but keyed to a building: twelve buildings means twelve copies of one manager’s preference, and no Account-level default for them to inherit from.

1. Company Name is an org fact stored per user (User.companyName, OrganizationSettingsShell.tsx:172; OrganizationSettings.tsx:15-18). Organization.settings and Organization.name have no writer in src/app.
2. "Hide from sync" is an org-wide destructive action keyed on a per-user denylist (User.ignoredPropertyIds, ignored-properties/route.ts:149) — another user still sees the property until sync re-imports it; deletion is real.
3. Admin Settings toggles are one global row for every org (CONFIG/SETTINGS; api/settings/route.ts:26-33), was writable by any requireUser caller (:183) — closed by #7365, staff-only on write; the page calls them "user-level" (admin/settings/page.tsx:15). OrganizationSettings type duplicates the same fields (types.ts:12484-12496) and is dead.
4. AppSettings.smsEnabled is not read by the SMS transport — the real per-property gate is Property.smsShadowMode (script-only) (types.ts:3082-3083). Global emailShadowMode defaults to true (dynamo/settings.ts:30) and per-property Property.emailShadowMode is PATCH-able but has no UI.
5. Follow-up cadences and contact limits are ORG-scoped but only editable from a property context (PK=FOLLOWUP#<orgId>; drawer + Settings card require propertyId; PolicyDrawer.tsx:60-75 explains the tension). Editing "Past-due balance" on Camellia rewrites it for every property in the org.
6. Late fee / grace days have two write paths — property page Pricing editor and the Collections policy drawer — both on PropertyKnowledge.pricingDetails, with a documented clobber hazard (MoneyRulesSection.tsx:16-22).
7. Two "office phone" fields with different meanings on two pages: Property.officePhone (transfer destination, Property Settings) vs PropertyKnowledge.phone (public line, property detail page); Property Settings seeds one from the other (PropertySettings.tsx:98).
8. Renewal autonomy switch lives in three places: RenewalPolicyEditor (autonomousRenewalEnabled), the Arms tab (same flag), and the global CONFIG/RENEWAL_ARMS row (script only). The "Open renewal N days" setting in Property Settings does nothing unless the global autoStart arm is on — not surfaced there.
9. ~35 per-property behaviour switches have no UI at all (§4b) — including the single most important one, handoffMode, plus timezone, smsConsentMode, escalation owner, shadow modes, tour day/lead rules, PM notification mode, holiday closures, lease policy. Each has its own scripts/set-*.ts or a hand DDB write.
10. Leasing-settings route accepts fields the page never shows (tourMinLeadMinutes, tourDayPolicy, postTourFollowUpChannel, deprecated renewalOutreach* — leasing-settings/route.ts:75-93,226-235); turnover-settings route has no UI caller.
11. Global UI prefs stored globally: setupGuideState and askClaraState are on the shared CONFIG/SETTINGS row, so one user's collapse affects everyone (types.ts:13377-13383).
12. Per-property kill-switch overrides (PropertyLeasingSettings.turnIntegrity*/tour*Enabled) exist but the Arms tab only writes the global half.
13. Env arms that need a deploy (leasing digest, vendor dispatch, tour chokepoint, preference capture, stated-name, tour window, voice callback, decider mode, NTV routing) are global across customers; the two-factor design means the per-property flag is the only per-customer control and it is Arms-tab/script only.
14. Customer facts still in source/env: Twilio numbers with hardcoded fallbacks (phone-lookup.ts), ElevenLabs agent ids, recipient allowlists (VENDOR_DISPATCH_RECIPIENT_ALLOWLIST, LEASING_REPORTING_DIGEST_REVIEW_RECIPIENT, BAKE_ALERT_EMAIL), TEST_PROPERTY_TRANSFER_TARGET.
15. Retired env names linger in tests only: MAINTENANCE_AUTONOMOUS_SENDING, PM_ACTION_REMINDERS_ALLOWLIST, MAINTENANCE_HANDYMAN_QUIET_HOURS_DISABLED, RENEWAL_AUTO_START_ENABLED (8 non-test reads remain for the last one).
16. Handyman quiet hours are per vendor-membership, default ON, script-only (set-handyman-quiet-hours.ts); tenant quiet hours are hardcoded TCPA on Property.timezone, which itself has no UI and silently defaults to Chicago.
17. Turnover policy editor edits 2 of 7 fields on PropertyKnowledge.turnoverPolicy (timing fields unreachable), while the Turnovers page drawer only carries follow-up cadence.
18. **Dashboard/user prefs sit under /api/settings/* (dashboard-layout, dashboard-card-windows) next to the global admin route — same URL family, three different scopes (user / global / user).

Per-property behaviour switches with no UI

Each of these is a customer-relevant behaviour today changed only by a script or a hand write to DynamoDB. The applied table above says where each belongs.

Open questions for the founders — each with a recommendation

1. Org level has no writer. Organization rows cannot be edited; Company Name writes User.companyName; follow-up cadences are org-scoped but need a propertyId to derive the org (cadences/route.ts), so the Org-level Follow-ups card is shaky when "All Properties" is picked (FollowUpsCard takes propertyId: string | null). Recommend: Fede's "add a customer" back-office flow lands the writer first; until then no O→P inheritance can ship, so sequence it before the Autonomy card.

1. Gera's org-level list is right for two of three. Tour duration and application link → O→P (C6). Transfer destination → Property-only; the "org" feeling comes from single-property customers, where the two levels collapse — handle with the "single-property org hides the property/org split" refinement ADR-0019 N2 already names, not by moving the field.

1. Should customers ever write "Autonomous"? Constitution says no (IV.6). Recommend: customer-writable rungs stop at "Act with approval"; Autonomous is staff-set, customer-visible. Revisit once a property has run a clean month.

1. enabledModules and the /admin/settings toggles are platform-wide but read like customer settings. One org flipping them flips every org. Recommend: migrate to Organization.settings (type already declares them) in the same PR that adds the org writer; delete the toggles from /admin/settings, leaving it as a pointer page to the Access Inspector.

1. Rules are stored inside PropertyKnowledge (renewalPolicy, turnoverPolicy, lateFee) — the knowledge route's sanitizer clobbers siblings on partial PATCH (MoneyRulesSection.tsx "CLOBBER NOTE"). Recommend: new rule fields go to PropertyLeasingSettings/PropertyMaintenanceSettings; move the three existing ones when their drawers ship, with the same single-home drift test used for lease policy (lease-policy-single-home.drift.test.ts).

1. Wrong-level state already in the tables: User.ignoredPropertyIds governs org sync; setupGuideState/askClaraState live on the global config row; subscription and legacy company fields on the shared row (the 2026-09-07 stopgap in api/settings/route.ts). Recommend: a one-time "level audit" ratchet test — every field on AppSettings must be declared platform-wide by a comment or fail — and move the three named fields.

1. Time zone: todayDenver() hardcodes America/Denver for every prompt (clara-personality.ts), while the user setting says "Times show on each property's clock". Not a settings-page question, but the first out-of-Colorado customer breaks on it. Recommend: property timezone becomes a required building fact on the detail page and the prompt helper reads it.

1. Inheritance vs. hot rule 13. An org default that is absent must never leave a property dark. Recommend: the resolver's third rung is always a code default (never "off"), and the falsifier for every inherited knob is a test that an empty org row reproduces today's per-property behaviour byte-for-byte — the same "UNSET = today's behavior" contract every recent property field already documents.

Bottom-up: what is hard-coded to one customer today, and where it becomes a setting

Gera, 2026-09-08: "a lot of things are kind of hard-coded to Camellia or even JPCO; now that we're onboarding new organizations and properties, all that stuff needs to be at the right settings page, configurable and clear." This section works from the code upward. Sources: the customer-identifier fence's own ledger of known violations (customer-identifier-fence.drift.test.ts, categories B and C are the live coupling), a sweep for customer names, subdomains and time zones across src/lib, src/app/api, agents and lambda, and the inventory's env-only knobs. Prompt examples that merely mention a customer ("tour confirmed at Camellia Apartments") are hygiene, not settings, and are listed last.

Onboarding-ready checklist: what a new organization and a new property must have before Clara runs

The same list read the other way: the fields a customer (or staff, at onboarding) sets, at which level, and whether the product can take the value today. "No UI" means the field exists and only a script writes it; "hard-coded" means the code does not read a field at all. This is the working spec for the settings pages: every row is a field or a card.

Organization — set once per customer

Property — set once per building

Admin — PropFlow staff only

Sequencing — what has to land first

1. An Organization writer. Nothing at the org level can be edited today: Company Name writes User.companyName, follow-up cadences are org-scoped but need a propertyId to find the org. Fede's "add a customer" back-office flow is that writer; until it exists no org→property inheritance can ship, so it goes before the Autonomy card. Team management (add/remove people with roles from Organization Settings) is the first customer-facing org-level write and can land alongside it.
2. The settings resolver — resolvePropertySetting(propertyId, key) returning value + source, replacing the "property → hardcoded default" resolver; its contract test is that an empty org row reproduces today's per-property behaviour byte for byte.
3. The Autonomy card on Property Settings with the read-only module mirrors, mapping the ladder onto capabilityStage / handoffMode / the send arms, and folding today's scattered booleans into rows.
4. Move the wrong-level state: the /admin/settings toggles to the arms tab; enabledModules to Organization.settings; setup-guide and Ask Clara state to the user; hidden-from-sync from the user denylist to the org. A ratchet test that every field on the global config row is declared platform-wide by a comment, or fails.
5. Give the 35 no-UI switches a home per the applied table — most become rows of the Autonomy card or the Notifications card; identity lists (trusted senders, correspondents, Twilio numbers) become read-only Integrations rows staff provision.

Method: two read-only research passes over the repository (an inventory pass and a placement pass), synthesised here. Product comparisons drawn on: Vercel account/team/project, Linear workspace/team/personal, Intercom and Front (inbox rules live in the inbox), Stripe, AppFolio and Buildium (company policy templates with property-record overrides). Related: the four-level split (#7324), one shell per level (#7326).