Situs Onboarding Atlas

How to read this page: four marks, one witness, one home per fact

Nearly everything below comes from one long conversation with one person on Sep 1, filtered through a transcription tool that lost the speaker labels. A little of it comes from a database we measured ourselves. Those two kinds of sentence must not read alike, so every load-bearing claim on this page carries a mark saying where it came from, lives in exactly one section, and has a name and a date attached to it.

The four marks, plus one

The test of whether the marks are working: these two sentences must not land with the same weight.

One witness

Nobody at PropFlow has spoken to Hugo, to the second principal, to Davey, to any of the three leasing staff, to any of the three offshore VAs, to any maintenance tech, or to any tenant. Every claim on this page about who will resist, why prior systems died, and who really does each job is one person's account of colleagues she says she does not manage. The leasing team's own version — that the dashboards and templates were bad, unsupported, or imposed without training — does not exist anywhere in our record. That is not a footnote; it is the largest single hole in the evidence base, and the completeness critic opened its review with it. The commercial critic's eighteen findings never raise it — so the hole is named once in our record, not twice, which is itself a reason not to treat it as settled background.

Scale of the corpus behind this page, for calibration: 674 findings drawn from 14 sources (8 transcript chunks, 6 Slack-thread sources), self-graded 555 certain / 110 probable / 9 speculative — but that grade measures how confidently the finding reads its source, not how good the source is. A "certain" finding on top of a single [T] remark is still a single [T] remark, and at least one "certain" finding carries an evidence quote that covers only half its own claim. The marks exist because that confidence field lies.

One home per fact

Each fact is stated in full in exactly one section — its HOME — and referenced everywhere else by section id, never restated. Restating is how the last atlas ended up with three unit counts and no way to tell which one had been retired. If you want the number, follow the id.

The extract's own inventory — the 209 MB and the five row counts in the [X] row above — is homed here, because it defines the mark. Every figure derived from it is homed in the section that uses it.

Every section closes with three lines, and a section without them is not finished:

Status vocabulary and resolver glyphs

Five words, used identically in every section and in register. A ruling never deletes a row; it dates it, so a reversal has something to point at.

Every row in register also carries a glyph naming the kind of thing that would settle it, because the cost of resolution differs by two orders of magnitude and the cheap rows should be closed this week.

A row with no glyph is not allowed on this page. A question with no named resolver type is a worry, and worries do not belong in an atlas.

The decision: sign, reshape, or walk — and the line where this is a bad account

Marks used throughout: [X] measured in our own AppFolio extract · [T] said on the whiteboard tape · [E] the client’s own figure · [F] something PropFlow asserted to the client · [?] no source in this record. What each one licenses you to do is in How to read this page.

sequenceDiagram
    participant D as Data
    participant S as System
    participant P as One person

    S->>D: watch the threshold
    S->>P: Budget at 75%.
Want me to act?
    P-->>S: yes — in the reply
    S->>D: acts on the answer
    Note over S,P: no screen anywhere in the loop

One in-person day produced a buying signal, a dollar figure, an NDA and five commitments. It did not produce a decision. Three shapes are on the table, none of them chosen, and the fastest way to lose this account is to send a proposal that names a price without naming a counterparty, a success metric or a walk-away line.

What is on the table

The build order was never reconciled in the room. That is contradiction #17 and it is the whole decision: PropFlow's first workload is the phone, the buyer's first workload is renewals.

What she asked us to build — the alerting and approval layer

Three pointers on this page route here for this one object — gate's blocks-to-scale row, register D4 ("a read/alert layer that owns no records"), and the term the quarterback layer as it is used elsewhere without ever being defined — so it is stated in full here and referenced everywhere else. Quarterback is the buyer's own word for the single person who has to take the next action; she is that person today for the whole portfolio, "the centre of the bow tie" through which all news funnels [T]. The ask is explicitly not a dashboard, and she made that argument herself: "I don't need another CRM. I'm already paying for one. I need you to pull the data out and identify markers beforehand" [T]. The dashboard graveyard in clock is the second half of the same argument.

Acceptance criterion, written to be tested. An alert fires on a threshold its recipient defined, lands with exactly one named person over email or SMS, is authored by the system rather than by a colleague, arrives days before the event rather than the day of it, and is answered in the reply. Anything that requires the recipient to open a screen fails the test. The lead-time figure is hers — "a few days early or a week" — and no tighter number has been agreed [?].

Two adjacent pieces are deliberately not restated here: the staleness detection that feeds these alerts is homed in trust-ledger, and the argument that alerts belong in a meeting cadence rather than a screen — plus the inference that they land in an EOS L10 slot — is homed in gate. What this layer is worth, and on what basis it could be priced, is not established anywhere: see Money, stated once.

The facts that add up — each stated in full elsewhere

Money, stated once

The room produced one number: the cancelable AppFolio maintenance call centre runs about $800/month, and the client side framed it as the minimum — "at least we can pay you that", "I'd rather give it to you guys" [T, hallway] attribution unverified. Read the provenance before you use the figure. It was a hallway exchange on the way out, not a negotiation; it reaches us second-hand and hedged in the retelling — "I think he said it was like 800 a month or something" — reported in the day's standup rather than captured on the session tape; and it has never been checked against an invoice. Do not quote it externally until one exists (register). Everything else on price is ours, not theirs.

The atlas's "$4.50/unit/mo, 30% off for three months, ~$10k setup, locked Aug 31" is an internal position. No PropFlow pricing was discussed on site. Do not repeat it as a client fact (retractions).

DECIDED 2026-09-02 — the price basis is deliberately open. Gera, asked to choose among the bases above: "let's just put it's to be dated and just make it known. We don't want to make any sort of decisions right now until the contract is finalized." So this table is evidence, not a shortlist being narrowed. Nobody is mid-deliberation and nobody is about to pick — the basis is TBD until the contract is finalized, and the GP conversation in decision is what unblocks it. Quote no basis externally in the meantime, including the retracted $4.50 above.

Cost to serve. Our own delivery estimate is months of forward-deployed work against a one-week internal guess that was then withdrawn as too ambitious [T]. Against an $800/mo anchor that is negative margin, and it would consume most of a two-founder delivery capacity in a week when a second prospect is live — a question nobody has actually asked. That is the fixed cost. The variable cost is unmeasured [?]: nothing on record states a cost per voice minute, per work-order intake, per browser-automation session or per email re-index, and no maximum seconds-to-first-word has ever been set for a phone turn. It matters here rather than somewhere else, because the wedge is priced against an intake volume that is climbing month over month rather than sitting flat (work-order-path) — cost to serve grows with the same metric we would sell on. The numerator is ours, not the client's: nobody outside PropFlow can answer it, and nobody inside PropFlow has computed it. Until someone does, neither the price basis below nor the walk-away threshold that follows can actually be evaluated. Rule: no scope is signed without a Situs-only vs reusable tag on every gap (gate) and a price basis that is not the call centre's.

The success metric — proposed, not agreed

Nobody agreed one. At an account with a three-month adoption half-life, an unmeasured pilot dies silently at day 90 — by which time the champion has relocated, and on the shorter two of the three versions of her end date has already gone. Baseline, from our own extract, never from her dashboards and never from anything measured while staff knew they were watched:

Target: after-hours guest cards with a transcript written back under the Clara identity, counted at day 90 from the first live call, compared against the same months of the prior year pulled raw from AppFolio. Note the size honestly before proposing it: ~14 cards a month is a thin number to hang a contract on, which is an argument for pairing the pilot with a second measurable workload, not for inflating the baseline.

The walk-away line

This is a bad account if any two of these hold on the day we sign:

What was actually agreed, and who owes whom what

The day produced no decision, but it did produce commitments, and none of them survived into the last atlas. They belong here because two of them are the agreed mechanism for settling contradiction #17 above, and one of them is the meeting the walk-away line tests against. Only one carries any stated timing; the rest have no date on record, and the column says so rather than inventing one. The section's attribution unverified caveat applies throughout — the transcript's speaker labels were AI-reconstructed, so read "she" and "he" as the client side and the PropFlow side.

None of these has an owner-and-date written down anywhere outside this table, and four of the five have no date at all. That is the same unowned-dependency failure this document diagnoses at the client, arriving in our own file — and the one with a date depends on a drive by a person who is relocating.

OWNER: Sean (commercial) with Fede (client facts) · EXPIRES: 2026-09-15, or the day any walk-away condition is tested · SIGNAL: a proposal goes out without a success metric or a counterparty named — or with a price basis asserted, which as of 2026-09-02 is the thing that is deliberately not decided (see the money section). The absence of a basis is no longer the alarm; printing one is.

What the last atlas got wrong — was → is

Twenty claims from the previous edition are dead. Most of them are still in your head, and several are in slides and Slack posts. Read this before you quote anything you remember. Each row gives the replacement, the provenance mark the record actually supports for that replacement (see key), and the one section that now owns the fact — no fact is restated anywhere else.

If a number below appears in a new PropFlow document, that document is wrong. That is this section's failure signal.

The unit count is the worst of them, because the old atlas turned it into a house rule — "quote Hugo's number, always". Three counts are on record and none is a rule: ~550 units E, the figure the client side quotes when it opens a vendor negotiation, sitting beside ~21 buildings E, which is the team's working description and has never been checked against a rent roll; ~500, which is what Tenant Turner bills against; and, in our own extract, 932 tenants X alongside 36 properties carrying 2026 work orders X — a set that includes sold assets, single houses and commercial. They do not reconcile, nobody has reconciled them, and every old sizing line that multiplied by 1,000 is out by roughly 2×.

The twenty rows

The method is retracted too, not just the numbers

Every row above has the same shape. A single-source statement — one person's figure, one transcription artefact, one internal pricing position, one pitch that had been rejected in the room — was promoted into a house rule, and the rule then got a verb that made it unfalsifiable: always, locked, decided. Once a claim reads as decided, nobody re-checks it and everybody quotes it, which is how "~1,000 units" survived long enough to size a build. The same mechanism invents job titles and dates: a role or a year that appears in no transcript acquires authority purely by being restated downstream.

Practical consequence for anyone writing the next PropFlow document about this account: the sentence "I read it in the atlas" is no longer an argument. Either the claim carries a mark and a home, or it is a memory.

Cut, not just corrected — things a reader might still cite

These were in the old edition and are gone from this one on purpose. If someone asks for them, this table is the answer.

Known gaps in this section: the evidence files record no publication date for the predecessor edition, so "the last atlas" is identified by content, not by date — fixing that is one ask of whoever holds the old file. Three replacements above also outrun the primary record and are marked ? rather than dropped: the MCC's property scope — one line in the day's standup thread, homed in work-order-path — the year Situs's estate entered AppFolio, and any job title for the owner who named the MCC floor. Two of those are one question to the client. The MCC's scope is not: it, and whether the "all day" coverage the record describes means round-the-clock, are one look at the AppFolio billing screen, and they belong in register beside the ask for the MCC intake script.

OWNER: Gera · EXPIRES: on the next atlas edition — this section is a diff against a fixed predecessor and has no meaning against a moving one · SIGNAL: a retracted number appears in any new PropFlow document or Slack post.

The clock and the veto: who decides, who adopts, who is leaving, and when

The person who wants to buy this cannot order the people who meet every prospect. The people who can kill it on sight report to someone else. And the champion's own end date exists in three incompatible versions, only one of which we can act on.

flowchart TD
  GP["GPs — Hugo + cousin"]
  VP["VP Ops — the buyer"]
  ON["On-site leasing ×3"]
  PF["PropFlow rollout"]
  SUC["No successor"]

  GP -->|"only they can direct"| ON
  VP --x|"cannot order"| ON
  ON --x|"can kill it"| PF
  VP -.->|"none named"| SUC

  classDef veto stroke:var(--bad),stroke-width:2px
  classDef ghost stroke:var(--muted),stroke-width:1px,stroke-dasharray:4 4,fill:none

  class ON veto
  class SUC ghost

Almost everything below rests on one interview with one interested party attribution unverified — the exceptions are the extract figures in rule 5, which are ours. Nobody at PropFlow has interviewed either GP, the leasing manager, any leasing agent, any VA, any tech, or any tenant; the only GP contact anywhere on record is a hallway exchange about price on the way out and an unminuted conversation with an owner noted in a standup. Treat the motives as one person's reading; treat the dates and counts as facts about what was said, not about what will happen.

Authority, not the org chart

The two GPs are an owner-operator pair; the record names them Hugo and "Noel," and describes the second as Hugo's cousin. The titles we have been carrying — president for one, CFO for the other — come from our own planning notes and appear in no primary source [?]; the same goes for the identification of the cousin with "Noel," which our notes themselves rate only as "almost certainly." What is on record is that the cousin set the price floor, and set it in a hallway on the way out, reported secondhand in the day's standup — "at least we can pay you that," meaning the ~$800/mo AppFolio maintenance call-centre line (MCC) [T, hallway]. Neither GP will open AppFolio [T]; the day's summary records a daily work-order dashboard email going to them instead [E]. The buyer is the VP Operations, and her reach stops exactly where the legacy on-site staff begin.

Unknown and material: whether the VAs are direct hires or through an agency, their contracted hours, their cost, and whether the VA program survives the champion's departure at all — she is the one who hired them after the on-site team refused her process. The "HireSmart" agency name appears only in our own internal planning notes, in no primary source [?] — as do the titles in the row above. Also unknown: what anyone at Situs was told about the day on site.

Three end dates, and which one we can act on

Do not average them. The three statements are: "this is my last week" [T]; "it'd be the next four months when I'm leaving" [T]; and a correction from the PropFlow side afterwards that she is not leaving the company at all — relocating East Coast, staying with Situs through roughly year-end, so it is "last week in the Denver office" [E]. Only the first is unambiguous, and only about presence: she drives cross-country the following week. Everything after that is disputed, and everything past December is unknown.

The rule that follows is a scheduling rule, not a forecast: ask for the physical and in-room artifacts now, in the days that are certain — the availability whiteboard photographed with its colour legend and its writer named, the after-hours on-call rota, the maintenance call centre's actual script and contract term, and the EOS Accountability Chart, quarterly Rocks and L10 scorecard, which probably already exist and which nobody has ever requested. Documents she can send from anywhere (rate card, annual operating calendar, turn buffers, pest adjacency rules) can wait for the disputed window. No successor sponsor is named. No successor for any single duty is named.

Bus factor by function

The method is the client's own, discovered by accident: one VA's maternity leave revealed that move-out charge-backs had run for five years with no documented process at all [T] — one person eyeballing inspection photos and improvising charges [E]. Nobody ran that test against anyone else. Run it on every row below before scoping anything that depends on one.

The graveyard, sorted by cause

The client side's summary of its own history is a three-month adoption half-life: "Soon as I create a system, it gets adapted for about three months. And then they just stop using it and go back to whatever way that they want while I'm not checking them" [T] — "adapted" is the ASR's rendering of "adopted." That is one narrative laid over three distinct failure modes, and only one of them is a design problem.

"Complete whole jobs end-to-end" is a real fix for the first two rows only. Rows three and four are a pay-and-consequence problem that nobody in the room named as such: the leasing agents are salaried with no incentive comp, the client side's own fix for the banned Facebook channel is to pay an individual a commission so they are self-incentivised, and her stated fantasy is hourly split shifts with incentives she does not have [T]. Row five says the cheapest adoption lever on record was hiring a different person.

Rules that follow

1. Rollout enters through the VAs. They accept process and scoring, and they are the only group the buyer can actually direct.
2. The leasing-team demo is a one-shot gate. It does not happen without GP sponsorship and an agreed communication plan, and it does not happen as a side effect of a site visit. The day's own action-item note says the "team demo/introduction to the leasing staff must be handled carefully — they are the de-facto decision makers."
3. Staff objections are not requirements. The client side reads them as professionally-worded defences of discretion over specific tenants [E]. Give discretion a sanctioned override with a reason code rather than a path around the system (schema-doors) — discretion with no legal exit becomes work outside the record, which is exactly what the personal cells already are.
4. Measure past month three. Anything measured before day 90 is measuring the honeymoon that every system in the graveyard above already lived through.
5. Rule on whether a per-person number may be attributed at all, before any analysis is shown to anyone at Situs. Our extract already scores named individuals: of 883 guest cards YTD, 154 (17%) have no human reply logged in AppFolio — a count of the one channel we can read, while prospects are also answered by a VA inside the Zillow portal [T], in the AffordableHousing.com in-platform chat box unverified [T], and on Facebook Marketplace, where a single listing draws ~100 responses in the first two hours [T] (cannot-promise) — and first human reply is median 5.1h, p90 71h on that same AppFolio-only denominator; of 87 cancelled showings, 46 were cancelled by staff [X]. Guest cards carry an assignee, so the figure reads as a person's work when it is a fact about logging: nobody has measured what share of prospect replies reach AppFolio, no such coverage measurement exists anywhere in the record, and until one does the number cannot honestly be attached to a named individual. That is a validity question, and it comes before the disclosure question. At an account where recording on-site staff is off the table because "the whole system would collapse," we are holding the same performance data by another door. Decide in that order: whether attribution is valid at all, then who sees it, attributed or aggregate, and who rules on that.

OWNER: Fede · EXPIRES: the day the end date is ruled in writing, or 2026-09-15, whichever comes first · SIGNAL: a week passes with no reply from the champion, or any duty in the bus-factor table is discovered to have stopped. First tell: the weekly 168-source sweep.

What we cannot promise — and the sentences banned at this account

About half of the current-tenant relationship at Situs happens somewhere no integration reaches today. That figure is the client's own estimate, not a measurement — and it is still the first bound on the contract, because every coverage, SLA and sentiment number PropFlow produces at this account is computed on the visible half, and any artifact that quotes one without saying so is wrong on its face.

The invisible half — this is its home

Roughly 50% of communication with current tenants runs on two employees' personal cell phones [E — "I would say 50 of the communications that are done with our current tenants are done through two people's personal cell phones"; her estimate, never measured], against a $50/month phone allowance [T]. The client-side reading is that the company therefore has no ability to look at them — "I pay them a 50 allotment towards their cell phone bills… but I don't have, like, the ability to go and look at them" [T]. one person's reading — unverified

That reading is one person's, not a lawyer's, and we have promoted it too far. No BYOD policy was ever asserted at Situs; nobody asked whether one could be asserted going forward for company business, whether a company-issued line costs less than the $50 stipend, or what Colorado requires. Until counsel rules, treat the invisible half as an open counsel question with an architectural consequence, not as a permanent boundary. If a policy can be asserted, a large share of the invisible half is recoverable and the shape of the whole engagement changes.

Two causes we can name, both fixable, both data-acquisition projects rather than efficiency projects: the sequential hunt group — calls roll person to person and callers gave up and dialled cells directly [T], at 3–5 rings each and roughly 20 seconds before a human is reached [F — those two figures come from the session summary, not from a verbatim line]; and in-person lease signings, which is how a tenant gets a staffer's mobile number in the first place and why they text that number forever after [T].

Channel by channel: read, write, or neither

Facebook is the account's self-reported best-returning source — "my best returns are Facebook", read off the client's own lease-attribution model and never checked against our extract [E]. Her fix is explicitly not software: pay a commission so an individual poster is self-incentivised to post on their own account [T]. We do not automate it, we do not log in, and we do not carry it in a pitch.

Recording: a matrix, never a switch

Nothing at Situs is recorded today — the matrix above is the agreed target, not the current state. The VA queue is the one leg the client volunteered: she was open to recording plus a quality score and expects the VAs to score well, because they are ex-call-centre and "used to working at a call center that just scores them anyway" [T]. On-site staff are off by decision, on her own prediction — "the moment that they find out that they're being recorded, I think the whole system would collapse" [T]. Note the hedge and the reason attached to it on tape ("I don't know if you want to do that right now because I'm leaving"): this was recorded as a firm phase-one constraint in the session summary [F], and it is worth re-confirming rather than inheriting. A new phone system with a recording toggle already exists at Situs and the staff do not know it can be turned on [T]. PropFlow's own deployed architecture records the full call including the human leg after transfer, plus voicemail [F] — which is exactly why the matrix, not a global default, has to be the configuration surface.

Banned copy at this account

Tenant-side trust — unexamined, and listed as such

An unfamiliar AI voice or an unknown number, at a population described as largely without social security numbers and afraid of immigration enforcement, may suppress reporting further rather than increase it. The line on tape is "I'd rather have the cockroaches than the possibility of you being an ice agent" [T], and tenants already withhold maintenance reports because "they're worried that if they flag themselves… you may not renew them" [T]. Every word of this is one person's account of her own tenants [E]. No tenant was interviewed. Nobody asked whether AI disclosure is required, advisable, or itself a trust event. This is the highest-consequence thing in the section that nobody has looked at.

OWNER: Fede · EXPIRES: 2026-10-01, or a counsel ruling on BYOD, whichever comes first · SIGNAL: any PropFlow artifact quotes an SLA or sentiment number without a coverage label.

AppFolio: the write target we cannot read, and the browser that leaks

AppFolio is the client's system of record, and writing back into it is the stated price of admission — the PropFlow side named it the first gap it must build no matter what [F]. It is also a system we have no sanctioned way into. Situs asked AppFolio for API access and was refused; on tape the client side says they were told a developer could get it, they could not [T]. So there is no client-grantable key and no plan-tier question to answer (that question is retired in retractions). What is left is two unsanctioned pipes — and one of them currently reaches into another client's books.

flowchart TD
  PF["PropFlow"]
  L["One shared browser login"]
  A[("Situs books")]
  J[("Camellia — another customer")]

  PF --> L
  L ==>|"read + write"| A
  L ==>|"same login, same code"| J

The three pipes, and the freshness nobody has written down

Three cadences are on the record and they cannot all be true: the PropFlow side told the client "every, every five, ten minutes, we're, like, pulling" [F]; the same session establishes the mechanism is a daily emailed report [T]; the client side's stated ideal is "in an ideal world, I would, like, get to, like, refresh, like, every hour" [T]. Nothing about a daily-grain, human-editable saved report can back a phone agent answering "is that unit available right now." Nobody says "applied units drop off automatically" again until a per-pipe freshness contract is written — which pipe, what grain, what the agent says when the data is older than the contract allows.

The leak: one code path, one login, two clients' books

In the PropFlow side's own words: it is "hard coded jp and co everywhere… an agent can never cross the boundary of a property — that's a leak we have currently that I discovered" [F]. Our so-called sandbox is not a sandbox: it is a real property inside Camellia's production AppFolio. The 2026-08-21 incident — a recon action that re-submitted a live Camellia resident's move-in — is the same leak seen from the other side, and the scope guard added afterwards is scoped to jpco only. Adding a second client to that code path multiplies the blast radius; it does not dilute it.

Blocking prerequisite. No Situs-scoped action runs in production until a Situs-scoped action attempting a jpco property id is refused by a test that exists. Written as a test first, then as a refactor. Owner and deadline in gate.

Two instances, one human, three namespaces

Situs and Western Slope run separate AppFolio databases; Situs owns 25% of Western Slope, a genuine third-party manager [T]. It is a second buyer, and the read on the record is that its priorities would run to maintenance and advertising rather than the quarterback layer — but that is one person's prediction about someone nobody in the room has asked [?]. No integration path to that instance is described anywhere in the corpus. The same client-side principal spans both instances, plus a house they manage privately (446 Galapago) that lives in the same phone-number namespace as Situs properties — which is exactly how the AppFolio-supplied call centre filed a live test work order against that house on caller ID alone, while the caller said the correct property aloud twice [T]. Credentials, sync jobs and property-id namespaces therefore have to be per instance. A database selector is not a boundary.

What we write today, and what write-back actually has to cover

Today PropFlow creates guest cards in AppFolio when a lead comes in. That is the whole write surface [F]. The client's price of admission is much wider, and the PropFlow side has already committed to it out loud.

One-way doors

Some things written into AppFolio cannot be taken back, and PropFlow cannot promise to remediate them afterwards.

Standing rule for this seam: every write path we ship names, in code and in the ledger, whether it can be undone. Anything that cannot is confirmed by a human first.

Adversary, not vendor

We are building a dependency on a company whose interests run against ours in three separate directions, and nobody has examined any of them.

• They clone partners. AppFolio was historically hostile to integrations and built in-house imitations of partner products — the client side's example is an inspection tool copied from HappyCo that they say is unusable [T]. The record has it opening up somewhat in the last two years [T].
• They already sell the thing our price is anchored to. The maintenance call centre is sold and billed through AppFolio, and the only anchor anyone has put on PropFlow's own fee is that call centre's monthly cost — a figure from a hallway exchange, never checked against an invoice. It lives in decision.
• Automating a shared human login may breach their terms and expose Situs's own tenancy to restriction [?]. Nobody has read AppFolio's customer terms or its partner/API program terms; they appear nowhere in the evidence base. The client cannot lose their PMS because of us — their investor portal is the switching cost that keeps them there [T]. This is a survival question for the account, not a legal footnote: scales glyph in the register.

OWNER: Gera · EXPIRES: the day the isolation test passes, or 2026-09-30, whichever comes first · SIGNAL: any Situs-scoped browser action appearing in a log without a client_id and a property_id on it.

Field by field: who writes it, which way it lies, and what Clara may assert

Cleanliness at Situs is a property of a surface, never of the company. Work orders are among the cleanest things in their AppFolio — the client side says so plainly, because that team is checked and policed on a regular basis [T] — while leasing, vacancy, lease execution and notices are the swamp. That is the industry prior exactly inverted, and it is the single most useful fact on this page: it means "is Situs's data clean?" is an unanswerable question and the only answerable one is "is this field clean, and which way does it lie?"

flowchart TD
  SRC["Photos, docs, scrapes"] -.->|inputs, not answers| H{"Human verifies"}
  H --> INV[("Answerable inventory (verified)")]
  INV ==>|the only read| C(["Clara"])
  RR[("Rent roll")] --x|never an answer| C

Write religiously, read defensively. Every field we write into AppFolio we write completely and on time, because write-back is the client's stated price of admission. Every field we read carries a corruption hypothesis with a direction and a magnitude, and terminates in a permission: Clara may assert it yes, may assert something derived from it, or never. A read path merged without a direction is a bug, not a shortcut.

The ledger

Outside AppFolio: where the truth actually is, and how fresh

The load-bearing facts are off-system, and every off-system source has a failure mode that is silence rather than error.

So freshness is a schema field, not a footnote. Every source we mirror carries a last-updated stamp, every surface that renders it carries a stale banner, and a feed that stops gets its own DARK state — because a dead feed at Situs looks exactly like a quiet one. This is the client side's own most concrete ask: a layer that says "hey, FYI, this hasn't been updated since this time. Don't use this… so I can find the black hole part" [T].

The answerable inventory is an object, not a policy

"Only answer on verified units" is not a rule you write in a prompt and hope holds. It is a table with a state machine, sitting between the PMS mirror and every prospect-facing agent. The predicate is the client side's own tightening — "it's not just available. It's like you turn ready and show it right now" [T] — so turn_ready ∧ showable, with sold and disposed property explicitly excluded, scoped by cluster and asset type, and carrying {verified_by, verified_at, expires_at, excluded_reason}.

The three things people keep proposing as the availability answer are inputs to verification, never answers. The whiteboard is the real source of truth and is un-photographed. The website scrape is a PropFlow MVP proposed partly to force the client to keep the website current, while the same PropFlow-side account concedes the website is already out of date [F]. The maintained Google Doc was the client team's proposal and was rejected on the PropFlow side [T]. The forbidden edge is the red one: the voice agent never queries the synced rent roll, at any point, for any reason.

The fair-housing check on the object

An allowlist is a list of buildings Clara is permitted to mention — which makes it, mechanically, a list of buildings she steers people toward. If the verified set systematically under-covers voucher-heavy properties, the agent is steering, whatever anyone intended. Voucher demand is real and already partly invisible here: 15 applications sit stranded in AffordableHousing.com, unconnected to AppFolio, and we have not checked which buildings they are for [T]. The client side also already tracks a live compliance line: advertised rent on affordable-housing channels must match market-rate advertised rent or it is source-of-income discrimination [T].

The audit is one chart, run every time the allowlist is rebuilt: voucher share per property, overlaid with allowlist coverage. A voucher-heavy building with no allowlist entry is a building Clara cannot mention. Gap We do not have voucher share per property anywhere in the corpus or the extract — the chart above is shape only, and the data has to be pulled before this audit can run even once.

And the steering question the client side asked directly, which nobody in the room answered: within a cluster, whose availability wins? Cross-selling within a cluster is already how they work, and one building is refinancing — pre-leasing it is worth basis points on the loan [T]. That is a legitimate business priority and an ordering rule inside a prospect-facing agent at the same time. It needs an answer that is written down before it is coded.

OWNER: Gera (the ledger), with Fede on the whiteboard facts · EXPIRES: 2026-09-30 — and the whiteboard rows expire the day a photograph and a legend arrive · SIGNAL: any Clara utterance about availability whose source is not a verified(ts) row; any read path merged without a direction.

Four rulings that cannot be unwound: identity, language, money, entities

A one-way door is a decision whose reversal costs a migration, a contract renegotiation, a voided legal case, or the account. Urgency is a different axis and lives in the register — a door can be irreversible and not due for a month. Four decisions qualify. Everything else is sequencing, and sequencing can be got wrong twice.

flowchart TD
  S{"Tenant's own signal?"}
  W["write preferred_language"]
  EN["Leave empty → English"]
  INF["surname · property · demographics"]

  S -- yes --> W
  S -- no --> EN
  INF --x|"never — forbidden"| W

  classDef forbidden stroke-width:2px,stroke-dasharray:4 3;
  class INF forbidden;

Identity: the client bought impersonation risk to get routing accuracy

People at Situs are phone-keyed and many-to-many. Four or five share an apartment; the caller is often a relative of the leaseholder; tenants transfer between buildings; numbers change and some callers are on landlines [T]. The same human shows up in AppFolio as a current tenant and, twice, as a prospect under two names — denied applicants re-apply under a middle name, caught by searching the cell number, not the name [T].

So the client side ruled trust the caller over the phone match, explicitly and after debate — "that's something we debated a lot… it just breaks in real life" [T]. That inverts PropFlow's safety default — it buys routing accuracy with impersonation risk — and it is the client's risk to accept, so we take the ruling and write it down. The observed failure of the opposite rule is already on record: on a live test call the incumbent answering service — AppFolio's paid maintenance call centre, which takes intake all day — on all but two properties [?], a scope this record does not evidence (see work orders) — not an after-hours line — heard "1965 South High" twice and filed the work order against 446 Galapago, a house the caller manages privately, because that was the property matching her caller ID [T].

So we never collapse the two readings: store the asserted unit, the inferred unit and a confidence, and let policy decide what each level permits. Identity is portfolio-level — scope it to an organization and one human becomes two people across the Situs and Western Slope instances, and a disposition orphans a sold building's history.

Language: a legal fact PropFlow owns, because AppFolio has no field for it

Colorado requires communicating with a tenant in their desired language, and failing to can blow up a collections or eviction case [T] — the client side's reading of the statute, to confirm with counsel before we repeat it, though the operational consequence holds either way. AppFolio has no preferred-language field [T]. In our extract, 735 of 932 tenants carry no language tag, 11,382 texts went out in both languages and 3,905 in Spanish only [X]. Bilingual by habit, not by system. The previous atlas's "~70% of tenants are Spanish-speaking" is retracted: the share is unknown, and a percentage invites the exact inference this door forbids.

The forbidden inputs are forbidden as code, not as a norm. The client side supplied the counter-example: a Spanish surname does not mean a Spanish speaker, and tenants who got bulk Spanish sends wrote back to say stop, finding it offensive rather than helpful [T].

Two proposals competed in the room. The PropFlow side's baseline was tagging language into AppFolio custom fields so it could be pulled in a custom report; the client side asked for the opposite — a system that "doesn't really need to tag everything and custom fill it perfectly… it just knows the domain so well that it can infer things" [T]. Neither wins. The resolution is passive capture: the tenant speaks or types Spanish, or sets it themselves, and nothing else ever writes the field. Manual tagging is unenforceable here — every system introduced at this client is adopted for about three months, then abandoned once nobody checks [T] — and inference is the thing that voids the case.

The corollary nobody expects: the field is Spanish SMS too. Several maintenance workers are 1099, text-only, and invoice by texting a photo; one appliance vendor speaks no English and works through an intermediary [T]. Language is not a tenant-outbound setting. It belongs on the person, whoever they are.

Money: the override is a stage in the pipeline, not an escape hatch bolted on later

Every automated decision that touches money — renewal price, concession, waiver, chargeback — ships with a sanctioned override object, drawn inside the pipeline. The reason is behavioural: staff sabotage what they cannot legitimately override. Three incidents from one session make the case.

The wider hole: there is no delegation-of-authority matrix at Situs at all — who may waive what, up to what amount, without whose sign-off is nowhere written down, and the only governing artefact on record is one manually updated sheet [T]. Authoring the matrix with the client is a deliverable, not a precondition we wait on; until it exists, approver has no domain to draw from.

One real pricing bug will be cited at this account forever. The political cost of being wrong sits far above the engineering cost of being right — which is why this door is ruled before the renewal build, not during it (renewals).

Entities are axes, not a tree

No parent-pointer hierarchy survives this portfolio. Management is an edge with an ownership percentage, not a containment relation: Western Slope in Grand Junction is a separate legal entity, 25% Situs-owned, a genuine third-party manager with its own operator, its own AppFolio instance and its own billing rules — a one-hour minimum at roughly $75/hour where Situs bills actual time [T]. That reopens the previous atlas's "one PMS connection" ruling: PMS instance is its own id namespace, not an attribute of an organization.

Behind all of it sit roughly 500 investors writing mostly $25k–$100k checks [T], and AppFolio's investor portal is why none of this can be replaced — the client side names it AppFolio's decisive advantage for a smaller syndicator, because property-management data flows straight through to the investment side [T]. That is the switching cost, and it settles our position: PropFlow is never a PMS replacement.

Whether Western Slope is in scope is open and belongs in the register. It cuts both ways: its operator is the warmest referral out of the session, and on our own reasoning a true third-party manager could bill our fee back to owners at management-fee economics — a better shape than our stated ICP logic predicts, since that logic says third-party managers are precisely the ones who read AI as headcount loss [T].

The axes are a migration, and we have already ruled where it may not run. Not from the session — from an internal PropFlow thread: the whole spine migration does not run inside a live real property before the founders are aligned on strategy, the reason given being irreversible decisions. "I would not want to migrate, like, do the whole spine migration while we're in a real property" internal thread, not the session. The posture recorded alongside it is cheap, reversible modelling — read-only ingestion, shadow tables — rather than committing to a normalised hierarchy that will have to be migrated again internal thread, not the session.

That leaves a fork nobody has chosen. Either the axes land and are proven ahead of the Situs cutover, or Situs onboards on today's per-property shape and the axes arrive later as a migration inside a live paying account — the one place the constraint forbids. It is also a contradiction sitting live on this page: the gate files "Entity axes" under what blocks scale rather than the first call, which cannot both hold and "land and prove the hierarchy change ahead of the cutover". Until someone rules it, read the sequencing as unruled [?] rather than as the gate's filing.

The resolver is an ADR, owner Gera, and it owes a register row it does not have. No due date is set [?] — none is derivable from this evidence base, and minting one here is the habit the retractions exist to break. What that ADR must answer, and this page deliberately will not: which axes are additive and which destructive to the current spine, whether an expand/contract dual-write is available at all, and how Camellia and jpco data — a history in which transfers were never recorded and the same human exists twice under two names — is backfilled onto time-bounded membership and portfolio-level identity. Nothing in this corpus describes PropFlow's own spine mechanics, so every one of those answers would be invented here. They belong in the ADR, checked against the tree.

What our code does today

Five lines, carried from the previous atlas's hierarchy archaeology. None were re-verified against the current tree in this session — verify before citing them in an ADR.

The default that is a door on its own: capabilityStage absent means live today. Every Situs row must be created with it explicitly off — that flip is a row in the gate, not an item here.

OWNER Gera · EXPIRES on the ADR that rules each door — four ADR numbers to be minted, none exist today · SIGNAL a schema migration touching person, language, override or membership lands without an ADR reference.

How a call and a lead actually move — and the after-hours slice we would take

Two paths carry a stranger into Situs: the phone, and the guest card. Both are mapped here, both are measured where our extract reaches them, and both die in named places. Phase one is one branch of one path — deliberately small, and one unanswered question can dissolve it before we write any code.

flowchart TD
  IVR["Caller → IVR menu"]
  MAINT["Maintenance — unchanged"]
  BIZ["Business hours — no AI"]
  AH["After hours + weekends"]
  VM["Today: voicemail → Monday"]
  CL["Phase one: Clara logs it"]

  IVR --> MAINT
  IVR --> BIZ
  IVR --> AH
  AH --> VM
  AH ==> CL

  classDef grey fill:var(--panel),color:var(--muted),stroke:var(--border)
  classDef accent fill:var(--accent-soft),stroke:var(--accent)
  class IVR,MAINT,BIZ,VM grey
  class CL accent

The phone today: one line, four named functions, two branches that matter

Inbound splits into roughly four functions, not two. The tape names them as leasing, office buildings (commercial), property management, and miscellaneous [T] — it does not name maintenance, which is unmistakably a fifth thing the phone does. That is the whole problem with the sentence: it is garbled, the count and the list do not reconcile, and it is probable, not certain. Office buildings and PM-misc are unmeasured, unowned, and out of scope for everything below. The two branches that carry volume are drawn here.

Two notes the picture cannot carry. Leasing is option 1 on tape; the digit that reaches maintenance is not in the record — what we have is the maintenance line's own menu, which opens with a recording disclosure, a language pick, and "if you're calling regarding a new maintenance request, please press one" [T]. Do not draw a two-key tree from that. And the MCC's own footprint: it is reportedly enabled on all but two Situs properties [?] — a standup parenthetical, never checked against a bill (home) — and its fingerprint in the work-order data is the creator role Customer Service — 155 of the 1,124 detail records captured so far, which is 43% of a 2,588-work-order index still being pulled, so treat the ratio as directional [X].

Its scope is narrow in practice: the agents record the work order, they do not diagnose or resolve it [T]. Whether that narrowness is contractual is not in the record — nobody has read the contract or the script (below). That narrow scope is nonetheless the bar Clara has to clear before anyone talks about replacing it.

The MCC test call is the behaviour spec, not an anecdote

The three failures drawn above came from one live call placed during the session, on tape [T]. Treat them as the specification rather than as colour: two of the three are promoted to permanent regression cases in the gate — 446 Galapago (caller ID must never be the verdict on which property a request belongs to; the number matched a house the caller manages privately, not the property she named twice) and yellow jackets / bees (a semantic duplicate must be caught before a second work order is created). The duplicate matters most: the MCC script does ask whether an open work order exists, and the agent asked the question and still could not answer it. Fuzzy intent matching against open work orders is therefore a phase-one requirement wherever Clara takes maintenance intake. Fede's ask, still unfilled: the MCC intake script itself (person glyph) — we are proposing to displace a scripted process we have never read.

Phase one: after-hours and weekend leasing, and nothing else

The slice agreed in the room: an AI phone system for after-hours and weekend leasing calls, chosen because it displaces nobody, needs no staff behaviour change, and is measurable in one number — incremental guest cards [T]. Separately on tape, the client side rejected AI on the business-hours line. The verbatim rendering is "during the business hours, like, will not happen", spoken inside a passage about recording and vendor pushback — reading it as AI answering during business hours will not happen is the room's interpretation and the one we are building to, but it is an interpretation of an ambiguous sentence, not a clean quote, and the speaker label on that line is machine-reconstructed, so even the who is soft. attribution unverified

The acceptance bar is the client's own and unusually low: "take a shot at it, create a work order, and then we can have somebody follow up" [T] — stated explicitly to avoid a staffer spending twenty minutes on a call. Two fences we set, not the client: callers cannot negotiate anything with the agent (the concessions record shows a verbal ~$1,000 offer later renegotiated to ~$500 with no documentation [T]), and escalation boundaries are explicit and enumerated before the first call.

The lead path, measured for the first time

Everything in this table is [X] — computed from our own AppFolio extract for 2026 to date, not from any client dashboard and not from anything measured while staff knew they were watched.

Two denominators, easy to conflate: 331 is cards that got a showing, 378 is showings booked. Booking is not the bottleneck — the median inquiry-to-booked is zero hours. The leakage is between booked and held, and staff cancel more often than prospects do.

Under those numbers sits hand work. Every non-syndicated lead is keyed into AppFolio by hand, mostly by one VA who also owns listing creation, listing inquiries and showing booking [T]. Slots are negotiated over Google Chat before anything is entered and clustered by an undocumented geographic heuristic; there is no queryable availability calendar for leasing agents anywhere — only maintenance has on-call calendars, and AppFolio's showing feed is one-way into Google Calendar [T]. Showings get traded mid-day without reassignment, so the covering agent arrives late — and AppFolio's automatic reminder text, which goes out about two hours ahead under the originally assigned agent's name probable, then names whoever is no longer coming.

Where a lead dies, by mechanism

The pre-leasing contradiction, unresolved. The client side wants to pre-lease far earlier than the on-site team will — Barcelona is refinancing and pre-leasing those units is said to move the rate by a few hundred basis points, and big operators list 60–90 days out on generic finish photos — while "ready for showings" dates are set so conservatively that one unit marked ready on the 15th was 70 days out, and the leasing staff refuse to pre-lease anything they cannot show [T]. Both positions sit on the same side of the table, and the blocker named is internal pushback, not tenants and not technology. Any Clara answer about future availability sits directly on top of this contradiction, and it is not ours to resolve.

OWNER: Fede (path facts) with Gera (slice spec) · EXPIRES: the day the VA rota is known, or 2026-09-15 · SIGNAL: a week of after-hours calls with zero guest cards written back, or a business-hours call answered by Clara.

How a work order actually moves — ten hops, four systems, three dead ends

Maintenance is the client side's best-run surface — and it still drops money at three specific joints, none of which is the part we would touch. This section is the home for work-order volume, lifecycle timing and the bill-back gap. The after-hours share of this traffic lives in prospect-path; the 2am emergency ladder lives in gate.

flowchart TD
  T(("Tenant"))
  IN["Phone intake — our one hop"]

  subgraph U["unchanged by phase one"]
    WO[("AppFolio work order")]
    D["Dispatch — VP Ops"]
    TECH["Tech — SMS"]
    ORCA["Orca — time · cost · GPS"]
    AP["Friday AP batch"]
  end

  T --> IN
  IN --> WO
  WO --> D
  D --> TECH
  TECH --> ORCA
  ORCA --> AP

  classDef accent fill:var(--accent-soft),stroke:var(--accent),stroke-width:2px
  class IN accent
  style U fill:var(--panel),stroke:var(--border),color:var(--muted)

attribution unverified Person names in this section come from an AI-reconstructed transcript and are unreliable. Read them as roles — dispatcher, tech, VA, AP reviewer — not as identifications.

What the extract measures, and the two numbers the room got wrong

Correction one. The room's figure was “about 20 work orders per day, roughly half portal and half phone, so about 10 a day on the phone” [T]. The measured year-to-date total is 10.6/day [X] — the whole portfolio produces about what the room attributed to the phone alone. But the series is rising, so the correction has to be stated against the right denominator: August's 483 is 15.6/day [X], which puts the room's 20 closer to 1.3× high at the current run-rate than to 2× high. Any sizing that multiplies 20/day across the whole year is roughly 2× high; any sizing that assumes today's volume is 10.6/day is low. Size against the ramp, not the average — and note that this is the same intake volume the phone wedge is priced against.

Correction two, softer. If half of intake really arrived by phone through the maintenance call centre, we would expect roughly half of records to carry the “Customer Service” creator. They carry 14% [X]. The scope figure usually quoted next to that — that the call centre is enabled on all but two Situs properties — is [?], and this page has carried it as [T] in error: it is not on the tape and not in our extract. Its only source is a parenthetical in Fede's 1 Sep Slack standup, unverified against any AppFolio configuration screen or invoice — so it cannot be used to rule coverage out. Four readings are live and none is settled: the detail capture is 43% of the index and may not be representative; phone calls that reach the office rather than the call centre are keyed by staff and so carry a staff creator; the call centre's actual property coverage is unmeasured, so coverage remains a live explanation rather than an eliminated one; or the 50/50 split is simply wrong. Reconciling the first three is a query, not a meeting; the fourth needs one look at the MCC configuration.

Three hops in that chain deserve a sentence the picture cannot carry. There are no appointment windows by choice: techs drive between scattered small buildings and cannot honour a window against traffic, parts runs and emergencies, so the tech texts “on my way” instead and the scheduler goes unused [T]. The field interface is SMS and nothing else — several techs are 1099, invoice by texting a photo of a paper invoice, and say plainly they do not know how to use a computer; one employee tech was set up as a vendor record in AppFolio purely so the VAs could text him rather than email him [T]. And vendor bills land in a human-watched ap@ inbox rather than AppFolio's Smart Bill, which the client side says codes them better than the human did [T].

The three dead ends

The clock nobody is holding, and the queue everyone ignores

Colorado gives a 24-hour cure on a broken stove. The work order pulled up live in session was dated the 14th and still open; the client side's own read was that a complaint to the governing body would carry a hefty penalty and that the only thing standing between the operation and that penalty was a tenant unlikely to litigate [T]. That is not a control. Separately, recurring and seasonal work — filter changes, pulling window ACs into storage — floods the dashboard on the first of the month, 46 of them on the day of the session, and both sides agreed the pattern has trained staff to ignore recurrings entirely [T]. A cure clock riding in a queue people have learned to skip is the failure mode, not either fact alone.

Our one hop

Exactly one box in that chain is ours: phone intake — and owning it means displacing a paid incumbent, which the retraction list sequences last, prices separately and gates behind a proven live escalation ladder (gate). Four things have to be true in it, and all four are recorded as platform gaps rather than as things that work today — semantic duplicate detection over open work orders at the unit (the live test call could not match “yellow jackets” to an open “bees” record and created a duplicate), a recurrence-or-reopen link distinct from a new record with recurring separated from the reactive queue, statutory cure clocks keyed to jurisdiction × issue type, and source attribution that distinguishes a Clara-created record from a staff-created one so the after-hours slice can be measured at all. SMS to the field is a constraint, not a feature: it is the only interface the techs will use [T]. That it also has to work in Spanish follows from a bilingual operation rather than from anything on record about the techs themselves inferred. Everything downstream of assignment — dispatch, the VA, Orca, the Friday batch, the allocation review — stays exactly as it is.

Staged, not smoothed. Bill-back and time-tracking were ruled out of PropFlow's scope in the room by the PropFlow side, and the client side agreed they were nearly irrelevant to what she had seen of the product [T]. The synthesis then named bill-back, move-outs and pest the largest uncontested dollar leaks with almost no political cost, because no incumbent process exists to displace. Both readings are on the page on purpose: the ruling stands as the sequencing decision, the money still sits where the synthesis says it does, and Orca landed on that same ground the same day. This is a staged order, not a resolved disagreement — the row is open in register.

The zero-risk move regardless of sequencing: size the bill-back opportunity from the 2,588 work orders and their flags [X]. It needs no client time, no write access and no commitment, and it converts an estimate the buyer herself could not ground into a number. It must be shown in aggregate only — the extract scores named individuals, and the disclosure policy in clock governs anything derived from it.

What we do not know

• The bill-back dollar value. Only counts are estimated, and the tape is genuinely ambiguous about whether “probably 50 of them would be billed back” means 50% or fifty records. Both readings are consistent with “fewer than 100 are.”
• Whether the extract even carries the bill-back flag. The first analysis is proposed, not run; nothing in the evidence confirms the field was captured.
• Orca's boundary. No API, webhook or export is established; who owns the contract is unknown. Sequencing bill-back behind an integration of unestablished feasibility is the live risk.
• Peaks. Averages only. No hourly distribution, no concurrency behaviour, no answer for a freeze night or a boiler failure hitting the same queue as the month-start recurring burst — and no statement of whether the cure clock keeps running while the agent is saturated.
• The cure-clock table. One clock is on record (Colorado, 24 hours, stove). The jurisdiction × issue-type table this hop depends on does not exist in any form here.
• How the 1,124 detail records were selected. Every lifecycle timing on this page rests on them, and the corpus records only that 43% had been pulled — not the ordering, the sampling rule, or whether the subset is representative.
• How many properties the call centre actually covers. The “all but two” figure is [?] — a Slack-standup parenthetical from Fede on 1 Sep, never checked against an AppFolio configuration screen or an invoice. Until it is, coverage stays one of the live explanations for the 14%, not a ruled-out one.
• The call centre's intake script, which is the behaviour spec Clara would be replacing, has been asked for and not produced.

OWNER: Fede · EXPIRES: 2026-10-01, or the day Orca's boundary is defined · SIGNAL: a Clara-created work order duplicates an open one at the same unit, or a work order carrying a cure clock passes it with no alert.

Renewals, notices and move-outs: the buyer's #1, the one bug that gets weaponised, and where a vacancy is born

The buyer side named renewals the single highest-ROI thing PropFlow could do, explicitly because it is the area they can actually control [T]. It is also a workflow where PropFlow already runs a live autonomous product. And it is the workflow with no process to automate, four dates that disagree, and no answer to who sets the price. Everything below is either a build spec or a reason to wait for the GPs.

Today: nagging, and a sheet nobody was told about

Asked what the renewal process is, the client side said that reviewing it is how they found out there isn't one [T]. What runs instead is manual chasing by call, text and email with no defined channel and no record of the attempt.

Four dates compete for the last 120 days of a lease. Only one of them is written in the lease.

The date bug, and what it obliges us to do

The consequence is not cosmetic. Tenant-facing renewal communications are currently inconsistent with the lease those tenants signed, and this tenant base has already been observed running a Situs lease through ChatGPT, finding an inconsistency and bringing it back to management [T]. So: PropFlow renewal outreach must suppress or supersede AppFolio's automatic email, and reconfiguring those custom fields is a required onboarding step per property, not an optional one. Outreach timing keys off the lease's notice term. The lease-end date is a display value and never a deadline we quote.

Build order: staged, both sides dated, not reconciled

Status: open. The GPs rule (register). Note what is missing from the August position — "fat finger" appears nowhere in this session's transcript, the Slack threads or the 674 findings. It is carried second-hand from an August demo and should be re-verified with the person it is attributed to before it is used again to hold revenue out of phase one.

What she asked for: an offer object, not a rate

Why correctness here is political, not just technical

The client side predicts staff will cite past automated-rent errors as the reason renewal automation cannot be trusted, then slow-walk increases fifty dollars at a time [T]. The worked example given was an inherited building with twenty-year tenants at $850 against a business plan that says $1,300 [T]. Read plainly: renewal automation at Situs is the enforcement arm of a value-add plan, and the people who must adopt it are the people it overrides. One real pricing bug becomes permanent ammunition. This is why the override object (schema-doors) is a precondition and not a later feature — discretion needs a sanctioned path or it takes a sabotage path.

Notice to vacate → the date Clara will be asked about

This is the most concrete Clara job named in the session, and it is a write path, not a read. Today tenants call, staff write it down, and AppFolio is never updated [T]. The client side now forces written notice to a leasing inbox and wants an agent to read it and set the move-out date. Open, and it is a live test, not a question: whether setting that move-out date is one of AppFolio's one-way transitions that cannot be edited afterwards. Nobody knows; run it in the browser agent before we promise the flow.

Ready-for-showings then derives from that date. The default offered was ten business days, and the client side was explicit that this is personal conservatism to avoid blowback [T] — not a rule, not an optimisation. It is a per-property knob, it must be recomputed as maintenance facts land, and it must propagate to the listing. It is also where the money is, and the diagram above measures it.

Move-out charges are the adjacent hole. There was no process at all for five years, discovered only when the single person doing it went on leave; charges are entered against inspection photos by judgment with a $0 placeholder held until the vendor bill lands [T]. What was asked for is narrow and buildable: an AI first pass over the move-out inspection that flags missing information and emails the tech for it ahead of the 30-day clock she cites. The tech is a compliant counterparty; the leasing room is not. Two revenue facts sit beside it, both stated by the client side against themselves — no transfer fee is charged today against a turn cost put at around a thousand, and there is no utility billback at most properties (two or three run a blended-rate program), because Colorado requires per-unit flow metering to bill actual usage [T].

OWNER: Gera (engine) with Fede (Situs policy) · EXPIRES: the day the GPs rule on renewals in phase one, or 2026-09-30 · SIGNAL: a renewal offer leaves without a holdback check, an override row, or a notice-term-keyed date.

The gate: what must be true before the first live Situs call — and, separately, before the first maintenance intake

A gate is a negative test with a named holder, not a milestone. "Isolation done" is a milestone; "a Situs-scoped browser action that reaches for a jpco property id is refused, and the refusal is alerted" is a gate. Milestones get ticked in a standup. Gates fail loudly when someone regresses them six weeks later. Below, every row is written as the thing that must be refused, and every row has one name against it. The rows we do not hold are drawn in a different colour, because those are the ones that will slip. And the section carries two trigger events, not one: the first live after-hours leasing call, and — separately, later — the first call on which Clara takes maintenance intake, which is also the day the MCC can be cut. Every row below says which of the two it hangs on.

flowchart TD
    LAD["Emergency ladder"]
    PILOT["Leasing pilot — ships now"]
    MCC["Cutting the MCC — waits"]

    LAD -.->|"does not gate"| PILOT
    LAD -->|"gates"| MCC

    classDef go fill:var(--accent-soft),stroke:var(--accent),stroke-width:2px;
    classDef held stroke:var(--warn),stroke-width:2px;

    class PILOT go;
    class MCC held;

flowchart TD
    subgraph LADDER["The ladder that replaces it · not written down"]
        direction TB
        R1["Rung 1 · classify the call"]
        R25["Rungs 2–5 · on-call rota"]
        R6["Rung 6 · voicemail + work order"]
        R1 -- "no answer" --> R25
        R25 -- "no answer" --> R6
    end

    MCC["MCC · answers every 2am call today"]
    MCC -. "the net under all of it" .-> LADDER

    classDef unwritten stroke-dasharray:6 4
    class R1,R25,R6 unwritten

The trigger itself is contested, and the register does not yet hold it. Is phase one scoped by hours or by function? The agreed wedge is after-hours and weekend leasing calls [T], and phase-one-slice rules it leasing and nothing else. But the client’s own acceptance bar is work-order-shaped — “take a shot at it, create a work order, and then we can have somebody follow up” [T]; design-brief.json scopes the phase-one voice layer by time of day (“after-hours/weekends only”) with caller classification that includes resident, not by function; and the same brief records that the build order was never reconciled in the room. This page does not settle it, because the record does not. It belongs in the register as a contradiction row — phase one is scoped by hours or by function? — with Fede and Eileen as resolvers, and no such row exists yet [?]. Until it does, the honest register is the one mcc-test-call-as-spec already uses: a maintenance requirement holds wherever Clara takes maintenance intake.

Two labels in the drawing are ours, not the client's. Rung 1's categories (flood · no heat · gas · lockout) are a proposed taxonomy — nothing in the corpus defines an emergency class, and design-brief.json does not contain the word. And "rota UNDOCUMENTED" means undocumented to us: see the row below. Read the drawing by trigger too: the capability ladder on the right and its three negative tests gate the first live leasing call; the six-rung escalation ladder on the left, the MCC hammock under it and the yellow-jackets case gate the second trigger — the first maintenance intake and the cut.

Ours — seventeen refusals before the first live leasing call, owner Gera

Each row is a test that must go red before the code exists and green after. The tag column is what makes cost-to-serve computable: reusable rows are platform we would have built for client three anyway; Situs-only rows are the ones that never amortise. Every row in this table hangs on trigger one; the maintenance-intake refusals have moved to their own table below.

Deliberately not a row: AI disclosure to the caller. Nobody has asked whether it is required, advisable, or itself a trust event (tenant-trust) [?], so there is nothing yet to refuse — it stays a counsel question rather than becoming a gate we cannot state.

Before Clara takes any maintenance intake — the second trigger

Phase one is after-hours and weekend leasing. These rows hang on a different event: the first call on which Clara takes a maintenance request, and the day the MCC hammock is cut. Filing them here is not a downgrade — it is the trigger being made explicit, so that nobody reads a leasing-only pilot as gated on an emergency ladder that phase one never touches, and nobody cuts the MCC believing these rows were already green.

Theirs — the critical path is not code

Emergency routing is the one same-day-loss failure — and the cutover trap

This subsection is the second trigger. It gates the day Clara takes maintenance intake and the day the MCC is cut — not the first live leasing call. Everything else on this page fails slowly. A 2am no-heat call in a Denver January at a B/C building fails inside one night, and it is a statutory clock as well as a habitability event: the session surfaced Colorado's 24-hour cure period live, on a broken stove whose work order had been open since the 14th [T]. Volume is not theoretical either — 22% of Situs work orders arrive before 8am or after 6pm and 10% on weekends, roughly 800 requests so far this year arriving outside office hours [X]. Those are not falling on the floor today, and that is precisely the trap: the MCC takes maintenance intake all day, on every Situs property but two [X], so the after-hours number measures a load that something else is currently absorbing.

The trap is sequencing. The MCC is cancelable and was put at roughly $800/month — a second-hand recollection on tape ("I think he said it was like 800 a month or something"), not a figure we have seen billed — and the client side named exactly that as the price floor: "at least we can pay you that" [T]. No pricing was negotiated on site [T]. So the commercial logic and the safety logic point in opposite directions: the cheapest way to fund us is to cut the thing currently catching the 2am maintenance call. Two rules follow. Cut it only after rungs 1–4 pass live, on real calls, not in shadow. And price its displacement separately from anything we sell on the leasing side, so that "we replaced the MCC" is a decision someone signs rather than a side effect of a discount.

What blocks scale rather than the first call

These do not gate the first live call. They gate property #22, and they are listed here only so nobody scopes them into the pilot by accident. Each is stated in full in its home section.

Situs-only vs reusable, so cost-to-serve is computable. Reusable: isolation, the capability ladder, the answerable inventory, the person spine, the language attribute, the override object, freshness, the four compliance refusals (campaign registration, opt-out state keyed to the spine, recording disclosure, an enforced quiet-hours window), the demonstrated stop control, the degraded-mode scripts, and alerting on our own pipes. Situs-only: the MCC script, the whiteboard cadence, 168-source credential handling, a Colorado clocks table, and the binding to whatever phone system the rebuild lands on. Anything that lands in the second list and is not priced as onboarding is margin we gave away.

Baselines come from our extract, never from hers

Every rollout baseline is re-derived from raw AppFolio extracts [X] — not from her dashboards, which died when the interns left two weeks before the session, and not from anything measured while staff knew they were being watched. Target and window are agreed before anything ships (decision).

OWNER: Gera · EXPIRES: each row on its passing test; the first-trigger rows on the first live leasing call, the second-trigger rows on the first maintenance intake · SIGNAL: a Situs property reaches live with any first-trigger row above unticked or with capabilityStage unset; or Clara takes a maintenance call before the second-trigger rows are green; or an outbound leaves with no registered campaign, no opt-out check or no enforced quiet-hours window; or Clara is live in an hour for which no PropFlow on-call holder has been named. No after-hours uptime or answer-rate target is stated in this section, because none has been agreed [?].

The register: every contradiction and open question, its resolver, its catcher, its deadline

Thirty-nine queued rows, four weak-provenance rows, and an index of the 21 contradictions and 8 atlas corrections that feed them. Every row names the kind of thing that settles it, the person who can, the day it is due where a deadline applies, and the one section that will state the fact once it lands. Nothing here is silently reconciled: a ruling gets a date and a name, and the row stays.

As of 2026-09-02 — one day after the ~5-hour, ~43,000-word on-site session of 2026-09-01 — every queued row is open except the six in Queue D, which carry a status of ruled, reframed or held-open. Held-open is a standing commitment, not a resolution. That is the honest state, and it is also the point of the register: a row past its deadline still reading “open” with no dated note is the failure signal for this whole document.

Queue A — 👤 free to resolve this week by asking

Catcher does one ask. Two rows are answered by our own extract instead of by a person and are tagged 🗄️. The queue is split into two dated blocks, because clock lays down a scheduling rule this queue used to ignore: capture the in-room artifacts now, in the days that are certain — documents she can send from anywhere can wait for the disputed window. One blanket deadline put the only irreplaceable asks after the window in which they can be made.

The date on Block 1 is an assumption, not a stated fact [?] — the session was Tuesday 2026-09-01, “this is my last week” [T], and the cross-country drive is “next week” [E], so the last certain day of in-Denver presence is taken here as Friday 2026-09-04. Nobody said that date out loud, and the record gives three incompatible end dates. A1 is the row that revises it: when A1 lands, correct this line and Block 1’s deadline together.

Block 1 — in-room, before she leaves Denver. Due 2026-09-04. The four artifacts clock names as physical and in-room. Only A4 is stated anywhere to be unobtainable once she leaves — gate calls the whiteboard photograph “only obtainable while she is physically in Denver”; the other three sit here because the certain window is the cheap one to ask in, not because they become impossible after it. A missed date on this block does not delay A4, it ends it.

Block 2 — sendable from anywhere, or ours to run. Due 2026-09-12. Nothing here is lost when she leaves Denver: each row is a document, a call, or our own extract.

Queue B — 🧪 one live test settles it

Not askable. Somebody has to run it once and write down what happened.

Queue C — ⚖️ counsel before it is a feature

Owner: Sean. Each row is due 2026-09-30 or before the feature it gates ships, whichever comes first. None of these is an engineering question and none should be answered by an engineer — one of them already was, in the room, by a non-lawyer.

Queue D — ∞ unresolvable by design, held open in the product

Owner: Gera. No deadline; reviewed at each gate. These do not get an answer — they get a mechanism, and the mechanism is the deliverable. A row here that has been “decided” instead of built is a defect.

Index: the 21 contradictions, and where each one lives

Every contradiction from the design brief, compressed to one line, with its HOME section and the queue row that resolves it. Open this when you want to check that a disagreement you remember has not quietly vanished.

Index: the atlas-vs-room corrections, rows a–h

The full was → is list lives in retractions and now runs to twenty rows. The eight below are the ones where the correction still changes a decision in front of us — that selection is editorial, not something the room ruled. Readers are still carrying the left-hand column.

Four claims we keep repeating with provenance too weak to survive

Carried forward from the previous atlas. Each is still in circulation internally; none is backed by a document, and two of the four appear nowhere in this corpus except inside the carried-forward note itself.

OWNER: Fede (Queues A–B) · Sean (C) · Gera (D); the four weak-provenance rows carry their own catchers  ·  EXPIRES: each row on its own deadline; Queue A Block 1 expires 2026-09-04 — an assumed in-Denver window, revised by A1 — and Block 2 expires 2026-09-12  ·  SIGNAL: a row past its deadline with status still “open” and no dated note — which is the same unowned-dependency failure this document diagnoses at the client, arriving in our own file.

The episodes

Thirteen sections is not something anyone reads on a Tuesday. These are the same material argued out loud, in three parts, so it can be listened to instead. Each page carries its own source brief — the document the episode is generated from — because that brief is often the more useful artifact of the two.

Why three, and not one

One episode covering thirty thousand words would be a lecture nobody finishes. Split this way each one answers a single question — should we sign this?, what is the system actually like?, what did we get wrong? — and any one of them stands alone for someone who only needs that answer.

How an episode gets made

Open the episode page, take the Source doc tab — copy it or download the .md — and run it through NotebookLM. That produces the audio. The file goes to artifacts/audio/<slug>.m4a, and the transcript, the read-along cue file and the waveform are generated from it in the same pass. The player is the shared component every podcast page on this site uses, so nothing about it is per-episode.