Twenty decisions, answered.

I'd build the view first and add the digest on top of it, because the view is the thing that has to exist either way and the digest is an afternoon of work once it does. One page per property, link-gated, every Foothold touch with a timestamp and the thread underneath it. Then a weekly email that's five lines and a link, not a transcript. That respects the thing you already told Liberty this would do, put our touches in their system instead of their inbox, and it degrades gracefully: if they never open the page, the weekly email still carries the headline.

Narrow first. sendLeads and updateLeads are the two that unblock the most and they're the only writes on the key today, so they're the only ones you can actually sign off on. Filing a work order is a different kind of act from creating a guest card, it sends a person to somebody's apartment, and it isn't granted yet anyway. Two signatures in that order costs you ten minutes and keeps the blast radius honest.

The named list of hard signals, ANDed with the minimum-info gate. Write the signals down as a list you can point at, because when Liberty asks why a guest card exists you need an answer that isn't "the model thought so." Start with three signals, add more when you see what people actually do. Keep the property name as a required field on the card either way, since a card without a property is worse than no card.

Build the outbox payload against the numeric typeId path, and pull the 155 real IDs out of getLeadPickLists now while reads are the only thing allowed. Then write the true channel into the comments field regardless of which typeId lands, because it's free text and it's the only place the truth survives if the ID turns out wrong. Keep the enum-mapping option as the runtime fallback the first live write degrades to. And do not learn this by issuing a test write. There is no test company and every call lands on an occupied building.

Welcome text with a link, plus a small incentive, and the move-in anniversary as the silent fallback. The text converts better than paper and you're sending one anyway. The anniversary is the right fallback because it needs no capture, it computes for everyone, and it's a warmer touch than an email asking somebody for their date of birth. Then track one number: what share of current residents have a birthday from either source. That's the coverage metric the engine has been missing.

Poll now, webhook later, and treat the webhook as a latency upgrade rather than a dependency. Resolve status against Liberty's real StatusTypes and name the qualifying values explicitly in config, so a status rename on their side doesn't silently stop the engine. On timing I'd say next business morning, not same day. A text an hour after the tech leaves reads automated. The next morning reads like somebody checked. And it keeps the touch inside hours, which matters because 76% of the week has nobody on site if the reply needs a human.

Two, follow-up first, review ask a few days behind it, and the review ask fires on the event, never on the answer to the follow-up. That's the only shape that satisfies rule 7 and the don't-spam rule at once. Put it plainly in the spec so a future build can't quietly wire them together: the follow-up earns the right to ask, it never gets to decide whether to ask.

Hybrid. It's the only one that neither strands a Friday-night lead nor sends an email nobody reads while the prospect believes somebody's coming. And you now have something concrete to offer that lead: the 5 Aug probe showed self-guided touring is configured all seven days, 6 AM to 6 PM, one at a time. So the Friday-night answer isn't "wait till Monday," it's "you can walk it tomorrow morning." Separately and non-negotiably: a genuine maintenance emergency gets a phone number, never a chat handoff and never an email.

Propose for agent-guided, commit for self-guided. Show agent-guided availability as availability and never as a promise, and hand the confirmation to a person. Self-guided is where you can actually commit, because the configuration is real, the limit is 1, and nobody's drive time is involved. That gets you a bookable Saturday tour without owning a scheduling system, and it's the same lock-box mechanic Liberty already runs.

Both, and be clear which one is load-bearing: the live check on the send path is the gate and is non-negotiable, the nightly sync is hygiene so a GHL broadcast doesn't hit somebody who opted out with Liberty. Two build notes that come with it: cache the pick list, it holds the tightest hourly bucket on the whole key at 60 an hour and 10 a minute, and a missing preference means do not send, not "assume yes."

Measure first, target later, feeder line until it's baselined. You said the number is proof when it's good and an accountability metric when it's bad, and right now you don't know which it is. Putting an unbaselined number on the partner-facing Overview commits you before you know. Three months of Owyhee data tells you where the bar actually sits. One build gate before any of it: createdOn is in the vendor spec and has never been seen in a live response. One read-only call settles it, and if it comes back empty the metric needs a different clock and the design changes. Check it before you build, not after.

Promote it. You affirmed it with a real decision on 10 Aug, and four other things now rest on it, including a permanent exclusion from a Liberty ask. Anything load-bearing in five places that gets miscited three times is already behaving like a rule; write it down as one. The only cost is that crossing it later takes a deliberate amendment, and that's the point.

Spec it, don't build it, and put a date on the trigger: if Aspen isn't on the key two weeks before go-live, build it. That date comes straight out of E1, so ask Liberty for the lead time in the same email and you'll know when to pull the trigger. It's cheap to spec and expensive to be surprised by, and building it now spends a week on something that has a real chance of never running.

Provision now, but for a reason that isn't latency: there's a question worth bundling with it that nobody has asked. Does anything fire on lead or guest-card creation? It isn't on the published list of five, but Entrata models a lead and an application as the same object, and the lease events carry application stage IDs, so lease.started may fire at guest-card stage. If it does, the speed-to-lead clock starts on a push instead of a poll, which is the single biggest thing webhooks could buy this build. Worth one email to find out. Also get the signature answer while you're there: the vendor doc's prose and its own sample code disagree on what string is signed.

Ignore it. It's an Entrata-internal surface on Liberty's website, it would cost a new permission ask and a write authorization, and it moves nothing you're measured on. Revisit only if Liberty asks for it, which would make it a relationship gesture rather than a marketing decision, and a cheap one at that point.