Three modules, ninety-four capabilities, and an honest mark against each one. What runs today, what needs building, what waits on Liberty, and what's decided and waiting on its build spec. Nothing waits on you as of 13 August.
Every capability across the three modules, marked. The bar is the real count of all ninety-four; the tracks below show the load-bearing ones.
Nearly two thirds of the system can be built today with nothing but reads. Liberty's group grant landed on 3 August, all six reads we asked for on 31 July, and the last five of those were probed on 5 August. Every one works. That emptied the unknown column and took buildable from 54 to 61. A second pass the same day found pets in the lease read, named, thirty of the fifty-two leases, which moved the pet gift out of the never column and took buildable to 62. Then your three decisions on 5 August moved two more. Filing a resident's service ticket used to sit in the "blocked on you" column; it now sits with Liberty, because sendWorkOrders isn't on the key and nobody has ever asked for it. Logging a recognition touch back to Entrata moved the same way, later the same day, when you reversed your own decision to park sendLeaseActivities and put it on the ask list instead. So Liberty is eight, not six, and you were twelve, not fourteen. Then your 10 August decision moved one more. "What the resident follow-up actually is" came out of your column entirely: you decided it's an AI-generated personal message about the resident's specific issue ("did your back door get fixed?"), not the survey that got cut, and it runs on work-order fields we already read, so nothing blocks building it. That put you at eleven, and buildable at sixty-three. Four things are genuinely waiting on Liberty: Aspen and Summerset onto the key, the apply link, that work-order permission, and the activity note, the last two in one email. Your signature still unblocks the entire mirror-into-Entrata half of Modules 1 and 2, and you've decided it's coming, on the properties you own, the day Foothold goes live on them. And nine things will never be in Entrata at all, so they have to live in GHL or a store we own. Then on 13 August you answered all twenty open decisions, and your column emptied to zero. Everything that was waiting on you is now decided and awaiting its build spec; the writes among them still sit behind rule 2's three conditions, unchanged. Liberty's side changed shape the same day: Aspen and Summerset are already being onboarded, in flight rather than un-asked, and the sendWorkOrders + sendLeaseActivities email is tabled by your call, written but unsent, so those two stay in Liberty's column as an ask on hold. The design is locked. Locked is not buildable: nine build-spec areas get written next, before any code.
The single rule the whole front end hangs on, stated as you defined it on 31 July.
Ebook downloads, waitlist signups, the nurture ladder, every email blast and broadcast. Nothing touches Entrata. Bulk marketing never crosses in either direction, ever.
A guest card is created, and chat, email and text all log against it. Liberty sees the whole thread in the system they already work in.
Two things to hold alongside it. Today the Entrata side of that line is entirely write-blocked, so crossing it produces a local record and a queued intent, and Liberty sees exactly nothing. The rule describes the finished system, not the one running now. Your 5 Aug decision gives that a date on the buildings you own, Aspen then Summerset, once each is live and signed off in writing. It gives Owyhee nothing, that one stays read-only because it isn't yours, so whatever we build to let Liberty see us there is the permanent answer, not a stopgap. And there's one deliberate exception: escalation to a human doesn't ride the line. It goes out of band to what Liberty actually watches, which Alex confirmed on 3 August is email and not their Google or Breakroom chats, and only files the Entrata note as the record, so a prospect asking for a person never waits on a permission.
Load-bearing capabilities only. Highlighted rows are the ones gating the most behind them.
Capture, qualify, converse, tour, hand off. Ebook to application.
Move-in, birthday, pre-renewal, referral, review. Handwrytten and gift cards.
updateLeads and sendLeads both carry an events array with a free-text comments field and both are on the key. The ask is unchanged, it's for resident touches and that's still the gap. And nothing loosened: appending a lead event is a write, so rule 2 governs it exactly the same way.Ticket visibility, the resident follow-up, and the bridge into FlightDeck.
This section used to carry the open list. On 13 August you answered all twenty; the full set with answers is on decisions.html and in DECISIONS.md. The design is locked. Locked is not buildable: nine build-spec areas get written next, before any code, and rule 2 stands untouched. The two heaviest calls stay below for the record, each carrying its answer.
Nothing is authorised yet, and that matters. Three things have to be true before a single write goes out: you own the property, Foothold is live on it, and you've signed off in writing naming that property and those methods. Aspen first, then Summerset. Owyhee isn't covered and won't be, it's Liberty's building, and everything we've verified so far was measured there, so a working probe was never a licence to write.
The visibility half got its answer on 13 Aug too: Liberty's surfaces are Entrata itself plus a five-line weekly digest email, no standalone Foothold page, and that's the permanent shape at Owyhee, not a stopgap. And the allowlist underneath all of it goes per-property rather than away, same choke point, same fail-safe, unknown property still means read-only. It has to be built that way from the first line, because bolting a per-property gate onto a global bar afterwards is where the accident happens.
Aspen and Summerset will live inside Liberty's Entrata org next to 98 other buildings. Access is org-scoped with per-property grants, so "the NPI org" is really a property-ID subset of a property manager's org.
That makes onboarding per-PM, not per-asset-manager, puts a third party with no contract with NPI in the middle of every sale, and turns the property-ID allowlist into a security boundary rather than a safety rail.
Answered 13 Aug: internal-only today, building toward self-serve software long-term. Not a done-for-you services business. The per-property allowlist still gets built as a security boundary from the first line, because the long-term direction depends on it.
One email, five items, all of it answered on 3 August and every granted method called on 5 August. Four things are open with them now: one is in flight on their side, one is sent and unanswered, and two are written but tabled by your 13 Aug call.
1. Aspen and Summerset onto the key. In flight as of 13 Aug: Liberty is already onboarding both, so this is monitor-and-verify, not an ask. It still gates the whole write half, since the write rule only lifts on buildings you own. 2. The apply link. Asked 3 Aug, unanswered, per property, whether tenants can apply anytime. Don't chase it with a second email. 3. sendWorkOrders, for owned properties. New on 5 Aug and never asked in any form. 4. sendLeaseActivities. You parked it on 5 Aug and reversed that the same day, and it goes in the same email as item 3: you're already asking for the bigger write, so the activity note costs one round trip instead of two. Pitch it as what it is for them, our touches landing in their system instead of their inbox. On 13 Aug you tabled that email, so items 3 and 4 are written and waiting on your go, not on a decision. Neither grant is permission to call anything, the sign-off still gates both, and at Owyhee the activity note stays unused even if they say yes.
The big one. Granted and probed the same day: real production work orders, including Completed "Make Ready." The picklists went on 5 Aug and came back carrying twelve named Liberty employees, so a ticket can point at a person.
getMitsLeases works and holds no birth dates at all. The lead record does, so the birthday card has a real source. It just isn't the one we asked for. We measured how far it reaches: 65% of current residents. The rest need the form, and no permission fixes that, so there's nothing more to ask Liberty.
Better than expected. The calendar is configured, not empty, and its self-guided setup matches the lock box story Alex told. Consent returns opt-in per channel. One correction: the window is seven days, not sixty.
Email, not their Google or Breakroom chats. Liberty's direct leasing and manager team, adrienne@libertyassetgroup.com today. They're restructuring that team, so treat the recipient as per-property config.
Pulled live on 31 July. One comparable Boise Class C building, and the denominator for every claim the brand thesis makes.
The probe ran on 31 July, so the month may be short a day and the window wasn't verified as a clean calendar month. Treat 109 and the 80/10 mix as directionally right, not audited. Re-pull a closed month before any of it goes in front of a partner.
We asked for one and got a live occupied building instead. Every call is against real residents, real prospects and real staff, which is the whole reason for the read-only rule.
Aspen closes 8/31 and isn't in Liberty's Entrata yet. Summerset either. Module 2 has no property it can legitimately run against until one of them lands. Liberty started onboarding both; in flight as of 13 Aug.
The read-only rule is still a property-class rule, so the day Aspen onboards it's read-only. Your 5 Aug decision says it comes off, on the buildings you own, when Foothold goes live on them. Three things, all of them: you own it, Foothold is live on it, and you've signed off in writing naming the property and the methods. Owyhee never qualifies, it isn't yours.
Same single choke point, same deny-by-default, same fail-safe. What changes is that a named property can carry a named set of permitted writes instead of the list being empty everywhere forever. An unknown or unreadable property config still means read-only. Build it that way from the first line, because retrofitting a per-property gate onto a global bar is exactly where the accident happens.
Of Owyhee's 785 work orders, 390 are resident-portal, 388 staff-entered, 7 system make-readies, and all 71 work-order locations are portal-enabled. That's why we redirect rather than intake, today and at Owyhee permanently. Two things to know before anything counts or texts: priority is dead weight (780 of 785 are Medium, triage on problem and location instead) and 312 of 785 are child tickets, so collapse them or one repair sends three messages.
Your call, 10 Aug: watch the aggregate, not individual tickets, which affirms the line the whole escalation design already rested on. What's new is that a responsiveness metric should now exist, and the design had none. It computes read-only off the work-order read (created and completed timestamps, plus date filters), no new permission and nothing to ask Liberty for. Measuring the aggregate isn't policing; chasing one ticket still is. ⚠️ It's dual-purpose and that's a constraint, not colour: good numbers are marketing proof, bad numbers are Liberty's accountability metric, so the definition gets written down once and never re-cut by window. Four traps: skip the system make-readies, collapse parent and child, don't segment on priority (780 of 785 are Medium), and confirm the created timestamp actually comes back populated before building on it, because it's in the spec and hasn't been seen live. Worth splitting in-hours from out-of-hours too, since 76% of the week has nobody on site. No target is set yet, and the 24-hour number on the scorecard is a first contact target, not a resolution one.
An unverified ticket sends a real technician to a real unit, so this is a safety gate, not a formality. Phone on file is strongest and cheapest, an inbound text from a matching number is a match with no friction at all. Unrecognised number: unit plus one more factor. Birth date is never the only gate, it covers 65% of residents, so a third of the building couldn't pass it. No match, a human takes it. And the after-hours hole doesn't close: an 11pm Friday ticket still waits for Monday, so a real emergency gets the phone, never a chat handoff and never an email.
Five events exist and none of them is availability or pricing, so the twelve-minute poll stays. What they add is the work-order and application layer. Decided 13 Aug: provision them, bundled into the Aspen + Summerset onboarding already in motion, and observe read-only at Owyhee. The poll stays the design either way.
The asset-management tiles are already unblocked. Rent roll, loss-to-lease, renewal exposure and NOI actuals all read today, so Phase 5 isn't really fifth.
Opt-in state per resident, per channel, reads clean as of 5 Aug. Nothing goes out to a resident or a lead without checking it first. The pick list behind it is the tightest rate limit on the key, ten calls a minute, so it gets cached rather than called per message.
Found 5 Aug. Thirty of the fifty-two leases have pets, thirty-four animals, and each record carries the pet's name along with type, breed, color, age and weight. It joins to the resident on the same key the birthday does. No form to build, no permission to ask for. One filter is mandatory rather than polite: assistance animals aren't pets under fair housing, so those records come out at ingest, out of the gift program, and out of any pet-themed marketing. The work-order read carries pet info too, which belongs in front of whoever gets sent to the unit.
Your call, 5 Aug: NPI has no use for a Social Security number and doesn't want the liability. The lease export defines the field and it's on our key, though Liberty leaves it empty, so there's nothing exposed today. It gets stripped anyway, at the same single choke point that enforces the read-only allowlist, before anything is stored, logged or shown to a model. Same rule on lease documents, where Aspen's forty-four executed leases each do carry one.
Both write permissions stay enabled by your call, so nothing on Liberty's side will catch our mistake. The maintenance group is reachable now too, reads only, which is a reason to be more careful rather than less. The deny-by-default allowlist has to exist before the first live call, and it has to be per-property from that first call, not global now and split later.