TL;DR
Maintenance is a loop, not a ticket: a resident reports, someone takes it, the work gets done, the resident hears about it. Today a coordinator runs that loop by hand, and at night it stops. 42–55% of resident requests arrive outside business hours and wait 11–14 hours (median) for a first assignment.
Clara runs the whole loop, day and night, as a coworker: she takes the report, files the work order in the PMS, offers the job to the right person, records a spoken “I’ll take it”, tells the resident what happens next, hands the morning to the office, and asks the resident whether it got fixed.
The PMS stays the system of record. Clara becomes the system of work. Staff can also tell Clara, on the call or later by text, to assign, dispatch, reach a vendor, file an order or text someone.
With Clara: every step, every hour; the human decides, Clara does the work.
intake
triage
work order
dispatch
work
verify
close the loop with the resident
learn
Today a coordinator, by hand, office hours
Before → after at Western Slope (measured on their AppFolio, 2026)
| Today | With Clara | |
|---|---|---|
| After-hours job owned and assigned | 14.4 h median at night (n=64; business hours 3.2 h, n=53) | Owner named at accept, in minutes; worker and time window by the morning hand-off |
| Resident told what happens next | After hours nothing goes back to the resident from the on-call chain (its numbers are internal; the office follows up in the morning). AppFolio’s own emails go out on 62% of orders (log sample of 259; recipients masked). | At escalation, at accept, next morning “did it get fixed?” |
| Proof someone took it | A pickup; a voicemail counted as a person tonight | A spoken accept that Clara restates, on any channel |
1. The loop
Eight steps, one engine. Dispatch is an offer to one person at a time, on every channel at once.
Incident (open)
↓
Offer to candidate 1call + text + email
↓
accepted
Ownedtonight or morning
↓
follow-through at the promised time
↓
done
↓
next-day resident checka “no” re-opens
declined · window expired · voicemail
Offer to candidate 2 …after three walks of the list
↓
escalation contact
↓
office email + resident told“still reaching the team; if it becomes dangerous call 911”
Side exits from any offer: “that can wait till morning” → routine · “we know, the main is out” → known issue (later callers appended, no new page)
What each step does
| Step | What it does |
|---|---|
| Intake | For an emergency: name, street address with unit, the problem and the safety questions; no read-back, no callback number (the calling number is used). For routine reports, the rest of today’s intake: new or existing issue, description, permission to enter, how the resident wants to be reached. |
| Triage | Uses the company’s own emergency list, state law, and the resident’s say-so. |
| Dispatch | An offer to one person at a time on every channel at once. The window is the wait for an accept on any channel, not the ring time; a pass is one walk of the list; then the escalation contact. |
| Close the loop | A message at every change and a “did it get fixed?” the next day, quoting the work order number. |
| Learn | The office’s correction becoming policy: asked once of a named person, recorded with its source. |
2. Today at our customers
At Western Slope, every after-hours emergency this year (40 of 40) went to AppFolio’s on-call robot; 64% of its chained orders were accepted, in a median 2 minutes. Only 6 of 32 accepted orders were assigned within 15 minutes. About one chained emergency in three reached nobody: AppFolio’s robot walks the list once and stops, and the job waits for the morning. AppFolio’s chain rings on about 19% of Western Slope’s orders and 7% of Situs’s; the morning hand-off is the volume.
Western Slope (from their AppFolio and their words)
| What | How it works today |
|---|---|
| What rings | The work order’s issue type decides. |
| Who is rung | AppFolio’s robot calls, texts and emails Ryan, then Jay, then the technician, five minutes each, until someone accepts (Jay: “press 1”; every accept in the log reads “via text”, so the channel is unconfirmed and is on the next call’s question list). |
| After hours, this year | 40 of 40 emergencies went that way; 64% of the chained orders were accepted (median 2 minutes); the other 36% were never accepted. |
| What press 1 does | Jay believes it “assigns it to yourself”. Measured: an accept writes a history line; 6 of 32 accepted orders were assigned within 15 minutes, 27 of 32 ever, 20 of those by the PM Assistant seat; Bev assigns the next morning. |
| The resident | Nothing goes back. |
| Orders the office types in | They never ring anyone, and neither do Clara’s, so Clara must ring her own. |
| Two front doors | They will exist until the fridge-magnet number is retired (contract to April 30, 2027, per Jay). |
Today: a logged Sunday emergency (Aug 23)
- 6:17 PM AppFolio’s robot texts and calls Ryan
- 6:18 Ryan passes
- 6:18–6:28 Jay, then Jonathan: no answer
- silence: one walk of the list, then nothing
- Mon 8:20 AM Bev assigns Jonathan
- 10:39 work done
With Clara: the same report
- 6:17 PM work order filed; page starts
- Ryan passes; Jay and Jonathan: no answer
- second and third walk of the list, then the escalation contact
- someone accepts, “morning”; the resident is texted
- 8:00 AM digest confirms Jonathan
- done
- next day: resident asked “fixed?”
The three customers side by side (April 12 to October 9, 2026)
| Western Slope | Situs Group | JP&Co / Camellia | |
|---|---|---|---|
| Requests per month | About 180 | About 290 | About 6 (35 orders) |
| Per unit per month | 0.70 | 0.68 (0.45 if 645 units) | 0.05 |
| Who takes the report | AppFolio call center (paid add-on) + Clara | AppFolio call center; wants Clara to answer nights and weekends (Hugo, Aug 27) | Not on file for nights |
| Who files the order | Residents via AppFolio intake 44%, staff 35%, call center 12%, system 5%, PM Assistant seat 3% (n=259) | PM Assistant seat 29%, staff 18%, call center 15%, resident intake 14%, inspection 13%, system 10%, resident portal 2% (n=1,627) | Resident portal 82%, Clara 15%, staff 3% (n=34) |
| Who is rung at night | Ryan → Jay → technician, 5 min each. 64% of 50 chained orders accepted, median 2 min | Techs John, Chauncy, Spencer, then Matt, Eileen, Hugo (AppFolio’s log names; nothing on file with us); 5 to 10 min steps. 46% of 110 chained orders accepted, median 1 min | No chain in AppFolio’s logs; a property emergency phone and one catch-all contact |
| Resident requests filed outside business hours (weekends, before 8:00, from 17:00 Denver time) | 55% | 42% | 56% of all orders (n=34) |
| First assignment, resident requests: day / night (median) | 3.2 h / 14.4 h (n=53/64) | 0.3 h / 10.7 h (n=284/206) | None: no one assigns in AppFolio (19 of 34 never assigned) |
| Who assigns, when | Bev, next morning (14.4 h median at night) | Within 15 min of accepting a page: 37 of 51 | Clara assigns the handyman; no staff member assigns in AppFolio |
| Resident updates | Nothing goes back from the on-call chain; the office follows up in the morning. AppFolio emails: email lines on 62% of orders, log sample of 259 (recipients masked); 9 in 10 orders show no resident update (earlier 12-month study) | Email lines on 67% of orders (recipients masked); 9 in 10 show no resident update (earlier 12-month study); recorded as told in 3 of 2,277 tickets (earlier PropFlow snapshot) | Clara emailed on 8 of 34; residents gave preferred times on 25 |
| Who does the work | Staff alone 64%, vendors alone 20%, none yet 15% | In-house techs 59%, outside vendors 2 to 5%, assigned (company not shown) 21%, never assigned 18% | One handyman recorded as a vendor, on 14 of 35 orders; no staff assignee |
| Maintenance in PropFlow today | Supervised (Clara drafts, staff approve) on 80 of 90 properties, off on 10 | Off on all 52 | Live at Camellia, off at Yale |
Measured from PropFlow’s copy of each customer’s AppFolio work orders. Limits on the numbers:
- PropFlow’s copy holds 58% (Western Slope) and 61% (Situs) of requests.
- Situs timing comes from a browser pull that ends Sep 1.
- Western Slope logs cover 259 of 696 orders.
- Camellia has 35 orders; no response times are claimed.
- Earlier cuts over PropFlow’s mirror (58% coverage) gave the same picture and are superseded by the log numbers above.
- The “PM Assistant” seat is reported as its own category.
- AppFolio email recipients are masked, so resident and vendor emails cannot be split.
Benchmarks: we found no independent figure for coordinator time or cost per work order. The one vendor figure, Property Meld’s 0.4 work orders per unit per month (2025 benchmarking report, quote unconfirmed), sits below the 0.68 to 0.70 measured here.
3. Clara as coworker
The accept is two turns: Clara asks, the person answers, Clara restates, and only the restated answer counts.
The accept is two turns. Clara asks; the person answers in their own words; Clara restates and asks “tonight or the morning?”; only the restated answer counts. A voicemail greeting never reaches the second turn, so nothing is accepted by accident and nobody presses a key. The same words work by text (“got it”, “pass”, “send it to Jay”) and when the person calls the line back. First accept owns the job; everyone else paged gets one line saying who took it.
Clara · turn 1
Hi Ryan, it’s Clara at Western Slope. Water pouring through a ceiling at 1601 Blake Street, unit 412, reported ten minutes ago by Jordan. Can you take it?
Ryan
Yeah, I’ll take it.
Clara · turn 2
Got it, I’ll tell Jordan you’re on it. Tonight or the morning?
Ryan · this answer counts
Morning.
Recorded: owner Ryan, arrival morning; resident texted; work order note + assignee set in PropFlow (written to AppFolio only when its API allows, phase 5); Jay and Jonathan told.
Voicemail greeting
Summary left: “reply GOT IT or call me back”
Never reaches turn 2. Never counts.
What the coworker can do for staff
- take it
- pass it
- hand it to someone
- what’s open tonight
- add a note
- text me the details
- connect me to the resident (always the human’s choice)
- file a work order for a resident
- ask for a vendor
Nothing to install: a call, a text thread, an email, and the PMS they already log into.
The action layer
On the page call, on a callback, or later by text, staff tell Clara what to do and she does it:
- “assign this to Jonathan for the morning”
- “dispatch the handyman”
- “reach my preferred plumber”
- “file an emergency work order for 1601 Blake Street, unit 412”
- “file an emergency purchase order for the plumber”
- “text Jay the details”
- “call the resident and tell her 20 minutes”
Clara restates each action with the work order number before writing it, and writes it to the PMS as herself with the instructing person named (the assignee lands in PropFlow now, in AppFolio in phase 5). She refuses what stays human: entering a unit, connecting a resident to a staff phone unasked, and any spend (in the first version “Jay approved $180” is a note, never an approval). The first verbs are the ones used inside the offer conversation; the rest arrive when a named person at the client asks for them. Staff already get read-only tools by text and handymen have the write tools; the action layer is the staff toolset built on them.
| What staff say | What Clara does | What lands in the PMS |
|---|---|---|
| “I’ll take it” | Owner set, resident told, others told | Note “Taken by Ryan 11:43 PM via Clara” |
| “hand it to Jonathan for the morning” | Assignee set in PropFlow (AppFolio when its API allows, phase 5) + digest line | Note |
| “text me the details” | Text with address, summary, access, photos | None |
| “reach my preferred plumber” | Vendor email or call with the job and time ask | Vendor on the order |
| “file an emergency work order for 1601 Blake Street, unit 412” | New incident + loop | Create |
| “file a purchase order for the plumber” | A purchase order in the PMS, tied to the work order (when the robot can write it, phase 5) | Create (purchase order) |
| “call Jordan and say 20 minutes” | Resident told on their channel | Note |
Who may ask, what Clara checks
| Action | Who | What Clara checks | Recorded |
|---|---|---|---|
| Reads (“what’s open tonight”, “text me the details”) | verified staff of the called company; never across companies | the number on file | action ledger |
| Internal writes (take, pass, hand to a teammate, add a note, file an order) | any verified staff in scope | a restatement with the work order number; the instructing person named; a shared on-call phone can take a job but is never the assignee | ledger, plus a note on the order |
| Outbound to people (text the resident, page the handyman, call a vendor) | verified staff, on a restated yes in the next turn | the gate is on the tool, not on who dialled whom; resident words are data, never instructions; a downgrade (“that can wait till morning”) is restated, recorded and told to the resident | ledger, plus a note |
| Money (a quote, a purchase order) | nobody through Clara in the first version | the client’s named approvers and limits come later (D8) | a note only |
One Clara, three definitions
One phone number, one voice
↓ at call start, the line picks by who is calling
Resident definition
Staff definitionthe answer line for staff and the chain’s outbound page leg: one agent, two doors (the Emergency Relay stands down wherever the chain is on)
Vendor definition
↓ all three read
The same incident, work order and history in PropFlow
4. Tiers and postures
Three tiers. For fire, gas and medical, Clara says “call 911” first.
| Tier | Examples (the company’s list decides) | Any hour | What Clara does |
|---|---|---|---|
| Routine | drip, appliance, door hardware | waits for the office | work order + confirmation; morning digest |
| Emergency | active leak, no heat below the company’s threshold, no water, sewage, no power (AppFolio’s own word; its lower “Urgent” level maps to the same priority in our copy) | yes | work order + page loop: three walks of the list, then the escalation contact, the office and the resident told |
| Life-safety / authority | fire, gas, CO alarm, medical, police needing access | yes | says “call 911” first for fire/gas/medical; then the company’s posture, with its own list and no cap |
Postures for the life-safety line, per company
| Posture | What happens |
|---|---|
| Message | take it, email the office |
| Page-until-human | own list, every channel, keeps calling until a person accepts; what Western Slope asked for. A known building’s police, gas or fire page runs on the same on-call chain as every other page, with the building and unit known |
| Transfer | only where a staffed human line exists |
Never automated
- connecting a resident to a staff phone
- skipping the 911 line
- deciding to enter a unit
- any spend, in the first version
- an arrival time Clara does not have
Same rules for every resident; lists are per company, never per person.
5. Day work and vendors
Three modes: page, assign or queue. Policy is learned once and never asked again.
Three modes exist today: queue is the Supervised hold, assign is autonomous dispatch, page is the alert chain. The only new thing is one setting per tier and time of day that picks among them.
Page (emergency)the explicit-accept loop (emergencies at any hour)
Queuenobody now; the morning digest lists what is open with the policy’s proposed person; the office assigns as it does today
→asked once, never a confirm queue
Assignthe policy names the person, Clara assigns and notifies, they can pass
Every row is visible on the company settings page, with where it came from: “learned from Jay by text, Oct 9”.
Western Slope on day one
| Tier | Mode |
|---|---|
| Emergencies | page |
| Routine | queue |
| Life-safety | page-until-human: keeps calling until a person accepts |
Policy is asked once, at onboarding or the first time a case comes up, of a named person with authority, and written as a setting with its source. Clara never runs a queue where the office confirms what she already knows.
Vendors are candidates too
- same offer
- longer window
- a vendor’s “yes” by text or email
- the quote/schedule/complete flow that exists today
Vendor emails exist in the code and are dark (they go to a test inbox); vendor calls exist only for turnovers, so resident orders need a new trigger; a preferred vendor per trade needs a field on the vendor engagement. Emailing or calling a real vendor is a new outbound: default off, Fede turns it on.
6. What varies, what never does
Same engine, different rows. What varies is a setting, never a fork.
| Never varies | Varies per client (a setting, never a fork) |
|---|---|
| Work order in the PMS at intake | The emergency list and its thresholds (Colorado added cooling, per Western Slope; statute not checked) |
| Explicit accept, restated; a pickup is never an accept | Who is on each list, in what order; a fixed order or a weekly rotation (a schedule rule on the on-call rows, never a new record) |
| One person at a time, every channel at once | Window (5 min at Western Slope) and passes before the escalation contact |
| Resident told at every change, on a channel the client allows | Which channels carry resident updates (text: decision D3) |
| 911 said first for fire, gas, medical | Life-safety posture: message, page-until-human, transfer |
| Routine waits for the office | Day modes per tier: page, assign, queue; who gets the digest |
| Same tier, same speed, same words for every resident, in their language | Whether vendors ring for emergencies (off unless the client says so); vendor tail at night; parallel quotes by day |
| Nothing to install for staff | Which inbox, which categories, which channel each person prefers |
Checked against five shapes
- a regional PMC with in-house techs and an on-call list (Western Slope)
- one large community with on-site staff (Camellia)
- a regional PMC with in-house techs, executives on the chain, a phone-tree hand-off and Spanish-speaking households (Situs)
- a small landlord with no staff (vendor-only rotations)
- a PMC replacing an answering service or keeping a human line for life-safety
What the next ten clients add
- A phone-tree hand-off is a transfer posture: Clara transfers only to a number that does not forward back into her line (a forwarded main line loops).
- Language: intake, triage and every update in the resident’s language; a Spanish-language emergency pages as fast as an English one (about 70% of Situs’s families speak Spanish).
- An accommodation request made during a repair call (an outage that matters because of a disability or a medical device) goes to a person; Clara never decides it, and it can raise the tier.
- A property run without staff confirmations (Camellia) gets the loop with no holds and no pings to staff: the work order lives where the team works.
- A client that keeps its own pager (AppFolio’s chain, Latchel, Property Meld) gets one row: who pages, Clara, theirs, or Clara after theirs.
Privacy, every client
- Recording links in office summaries sit behind sign-in or expire; audio is never attached to an email.
- Lockbox and gate codes go only to the person who took the job, after the accept; never to the whole chain, never to a vendor before they accept.
- Nothing Clara writes on a PMS order carries health details or transcript text (owners can see those orders); she links to PropFlow instead.
- Outbound calls to staff and vendors carry the recording disclosure in all-party-consent states.
7. Metrics Clara reports
Seven numbers, each with Western Slope today and a target.
| Metric | Western Slope today | Target |
|---|---|---|
| Time to acknowledge the resident | seconds (Clara answers) | seconds |
| Time to accept, after hours | ≈ 2 min median when accepted (AppFolio robot; 64% of chained orders are accepted) | within one 5-min window |
| Time to assign, after hours | 14.4 h median at night (n=64) | owner at accept; worker and window by the morning hand-off at the latest |
| First resident update | nothing from the on-call chain; the office, in the morning | at accept |
| “Did it get fixed?” answered | not asked | asked next day, every job |
| Unaccepted after 45 min | about one in three chained emergencies (36% never accepted; the robot walks the list once) | counted against the 64% baseline, zero target |
| Pages per person: taken, missed, passed | not visible | per-person scorecard |
Why these
| What | Source |
|---|---|
| Satisfaction is 4.41/5 when a repair lands within a day and 3.87/5 past 30 days | Property Meld benchmarks 2026 (vendor) |
| Colorado: a landlord must respond within 24 hours of a tenant’s notice of a habitability condition; repair deadlines are separate | C.R.S. 38-12-503 (read through a secondary copy) |
Vendor-sourced numbers are labeled as such.
8. Architecture and rollout
No new records: four that exist today, and one durable workflow per incident. Clara never cancels a PMS order on her own.
Four existing records
| Record | What it holds |
|---|---|
| Incident | the conversation (its chain-started mark) plus the work order: the unit, the tier, the PropFlow and PMS ids, the owner |
| Offer | today’s hunt ticket and its attempts: incident × candidate × attempt, each channel’s result, the window, the accept utterance |
| Candidate | a staff person with a role, or a vendor engagement; an on-call entry links to the person (Gera’s “add someone new”); a shared on-call phone with no linked person can take a job but cannot be the assignee |
| Policy | the on-call lists as stored today (per company, overridable per property); rotations on Gera’s assignment and schedule rows; modes and postures as settings with provenance. Never a new table |
One durable workflow per incident runs the loop; every inbound text, callback and call result is matched against open offers before anything else.
Gera’s lane owns the engine (the hunt ticket, the chain, the work-order trigger). This vision adds on top of it: the accept rule, the coworker leg, resident updates and day modes. No new lane.
Channels
voice in
voice out
SMS
email
Adapters
→
Incident workflowtimers, offers
→
Records
→
PMS writer
Settings: org-level, per-property override (Gera’s resolver)
The PMS boundary
| Clara writes | When |
|---|---|
| The work order | created at intake |
| Notes | at accept, follow-through and close |
| The assignee | when the robot can write it: today the create form carries an empty assignee field, there is no edit action, and no staff-to-AppFolio-user map exists |
| The Work Order Issue | never on her own orders: setting it would make AppFolio’s robot page the same people a second time |
| A cancel | never: Clara never cancels a PMS order on her own |
| Timing | about 5 minutes after the event (the sync waits for changes to settle) and sometimes rate-limited; the incident shows “not yet in AppFolio” until then; whether an emergency should skip the wait is open (ours) |
In Gera’s portfolio model, Policy and the on-call lists attach at the organization and can be overridden per property through the resolver, like lines and calendars.
What tonight’s build already is
| Built tonight | Already is |
|---|---|
| The hunt chain | the offer loop, with the wrong accept rule (a pickup) |
| Its text and email legs | offer channels |
| The chain’s call leg (a spoken summary plus machine detection, no conversation) | the voice leg, waiting for its brain |
| The office page | the summary |
Each becomes the general thing in one small PR.
What the loop deletes
- the Twilio “human” verdict counting as an accept
- the Emergency Relay’s single call (folded into the offer call)
- the early office page email (bug 3, fixed tonight)
- routing that rings only the first person
- 1Explicit accept replaces the pickup ruletonight’s bug-9 fix, no switch; ships on Fede’s accept-rule pick (D0), not on this page; Willows with fleet numbers and a voicemail control
- 2Coworker voicethe staff agent on the chain’s call leg (the Emergency Relay stands down where the chain is on); Willows, then the sandbox company in Western Slope’s shape
- 3Resident texts + office digestthe receipt after a phone-filed order is a fix (parity with text and portal orders); the accept, follow-through and next-day messages are a new outbound, company setting default off; Fede turns them on at Western Slope after proof
- 4Day modes + vendorsafter a supervised week
- 5AppFolio assignee writewhen the robot action exists
8b. From vision to execution: proof of concept, phases, risks
A local proof of concept first, then five phases. Every risk has a mitigation that ships regardless.
Before anything is built for a customer, a local proof of concept connects every piece on the Willows line with numbers we own:
- a resident call
- the work order
- the page
- a spoken “I’ll take it”
- a text “got it”
- a callback inside and outside the window
- a voicemail greeting that must not count
- one staff action by voice
It runs on scratch, never in CI; every grade has a planted-violation control; what it cannot prove is a risk below, with the mitigation we ship anyway.
Layer 1, the accept grader on scripted answers, ran tonight: 14 of 14 cases graded right, 19 of 19 planted violations red, 5 voicemail greetings never accepted. Layer 2, the live legs on the Willows line with our own numbers, is next.
| Phase | Proves | Components | Rung |
|---|---|---|---|
| 0 · Proof of concept (local, this week) | the loop end to end with real legs; a shadow run logs Clara’s tier and would-be page beside AppFolio’s real chain on every Western Slope order (a watcher, no switch) | loop runner, Offer records, adapters (text, voice out, callback), accept grader with controls | scratch harness |
| 1 · Explicit accept (a fix, no switch) | the bug-9 fix: a texted “got it” or a spoken yes; a pickup or a voicemail never accepts; a callback inside the window counts; “taken by” note in the PMS | hunt-chain accept rule, Offer records, callback matching | unit + replay + Willows |
| 2 · Coworker voice + action layer v1 | spoken accept; “text me the details”; hand to a person; add a note | the staff agent on the chain’s call leg, one brain for the answer line and the page; staff toolset in the role matrix | Willows → sandbox company |
| 3 · Resident updates + office digest (receipt = fix; the rest new, default off) | four messages + next-day “did it get fixed?”; low rating to the PM; “still broken” reopens | resident update channel, rating branch, resident reopen, digest job | sandbox → Western Slope on Fede’s turn-on |
| 4 · Day modes + vendors | assign / queue, learned policy, vendors as candidates | policy rows, morning digest, vendor offers (the dark vendor email path turned on per client; a call trigger for resident orders, new) | supervised week |
| 5 · PMS assignee + portal triage | AppFolio assignee written at accept; portal-submitted emergencies triaged and paged | robot action + user map; classifier and loop on the sync hook | after the robot action exists |
| Risk | How the proof of concept tests it | Mitigation that ships regardless |
|---|---|---|
| A spoken accept is misread (“ok”, “I heard you”, a greeting) | 30 scripted answers incl. voicemail greetings; a planted false accept must grade red | two-turn accept; ambiguous → one question; voicemail never counts |
| A text reply or callback is not matched to the offer | fleet number replies “got it” and calls back inside and outside the window | inbound is matched against open offers by number before anything else; late-accept rule |
| Two front doors page the same people (AppFolio’s robot and Clara) | mirror shows an AppFolio emergency order for the same unit within 24 h | known-issue check at intake; one page; Clara never sets AppFolio’s Work Order Issue on her own orders, so AppFolio’s robot cannot fire on them |
| Nobody accepts at 3 AM | three passes with no answer | escalation contact, office email, resident told, optional vendor tail |
| The on-call phone blocks or filters automated calls | a voicemail-greeting number; a landline/IVR case | onboarding checklist (save the number, no IVR destinations, do-not-disturb bypass); text and email always go out |
| The AppFolio assignee cannot be written yet | not testable | note + PropFlow owner in phase 1; robot action in phase 5 |
| A staff action lands on the wrong order or person | “assign it to Jay” with two open incidents | restate with the work order number before writing; staff-write-gate |
| Resident texts are held under Supervised mode | the Willows runs Live | phase 3 setting is on top of the mode; emergency and high already skip the hold |
| An accept on a call-center order never reaches Clara (AppFolio’s “accepted via text” line is not in the reports feed) | not testable | the after-accept loop runs on Clara’s own orders first; call-center orders need a browser read of the order or AppFolio’s notification email (phase 5) |
| A broken promise: “Ryan is on it tonight” when he said morning | the accept grader checks the restated answer | Clara repeats only what was committed; a check at the stated time; “still broken” reopens |
| Clara is the only pager for her own orders (AppFolio’s robot never fires on them) | an emergency order with no chain start | a watcher alerts us when an emergency has no chain start within minutes, live everywhere |
| Two units report the same leak | two calls, one source | one incident, one page; later callers appended |
| Two accepts land at once (a text and a callback seconds apart) | two fleet numbers answer “got it” within a second | one open-offer index per number and incident; the first accept is a conditional write, the second person hears who took it |
| AppFolio writes land late or fail (5-minute settle, rate limits, a day-old copy) | not testable | the incident shows “not yet in AppFolio”; re-read the order before a “taken by” write |
9. Decisions for Fede, and open questions
One line each: an explicit accept now (D0); one staff agent (D4); resident updates as a fix or a setting (D3); the page’s order (D5); no money in the first version (D8). Then the client’s answers, and what is open.
| # | Decision | Options | Recommendation |
|---|---|---|---|
| D0 | What counts as an accept (bug 9, tonight’s open pick) |
| A: a fix, no switch, ships now. B keeps the defect (any detector error ends the chain). C was ruled out by Fede. All 117 AppFolio accepts at Western Slope read “via text”. |
| D1 | Window and passes (the client’s answer on the onboarding checklist; our default) |
| A (Western Slope’s own 5 min; vendor docs: Latchel caps at 5 attempts, PagerDuty defaults to 30 min per level) |
| D2 | Life-safety posture (the client’s answer; our recommended default) |
| A (what Western Slope asked for; nobody in the field transfers to 911); a client with no authority list gets the 911 line plus a message to the office; a phone tree is a transfer posture, only to a number that does not forward back to Clara |
| D3 | Resident status texts |
| The receipt after a phone-filed order is parity with text and portal orders: a fix under A. The accept, follow-through and next-day messages are a new outbound to residents: B until the sandbox proof, then Fede turns them on |
| D4 | Coworker voice |
| A (the chain stands the Relay down wherever it is on; two staff agents would be two mechanisms) |
| D5 | Rollout order |
| A. B needs AppFolio’s accept lines, which the reports feed never carries (a browser read per order), and the 14 h night wait is mostly routine requests that wait for the office by design. The measured loss Clara fixes first is the one chained emergency in three that reaches nobody, plus the silent resident |
| D6 | What “I’ll take it” writes in AppFolio |
| A; first a live test of whether writing a vendor clears a staff assignee; Jay’s call on B |
| D7 | AppFolio’s own chain and Clara’s orders |
| A, after two live tests on a sandbox order: does the issue type fire the chain; can the robot set it at create |
| D8 | Money through Clara |
| A; B later, once a client writes approvers and limits down |
| D9 | Who owns the work |
| A (one owner for the chain; tonight two sessions fixed the same path) |
| D10 | Same house number and street in a different city (section 10a) |
| A until a real call shows a wrong-city filing; B is a small follow-up then |
| D11 | Give the classifier the date and the forecast (section 10b) |
| B one PR, no switch; A alone over-pages Western Slope all summer |
| D12 | A leak from the unit above: what Clara does with the source unit (section 10d) |
| A one prompt rule plus a source-unit field on the order, no switch. A new Clara behaviour, so it waits for Gera’s go (Fede passed D12 to him on 2026-10-10). In every overnight cycle Clara never asked where the water came from (10d). |
| D13 | A resident texts while Clara’s reply is held for Supervised review (section 10d) |
| A Fede ruled on 2026-08-20 that an escalated thread sends no canned acknowledgement; a Supervised hold is a review window, not an escalation, and today the resident hears nothing for its whole length. His call. |
| Open, the client’s to answer (asked on the onboarding checklist, never decided by us) | Open, ours |
|---|---|
|
|
10. Measurements from the overnight run
Address matching, measured on every home at Western Slope and Situs: no wrong home from ordinary speech (0 of 844), but a quarter of Western Slope’s homes and half of Situs’s cannot be reached by any spoken address as stored. Fixes are in flight tonight, no switch; this eval is their proof. 10c: what 16 products document on their own pages (none describes asking permission to enter; in one vendor-commissioned survey of about 300 renters, 82% want a human first for an urgent repair). 10b: 2,641 real work orders through Clara’s classifier: she follows the emergency lists (78–100% of named emergencies caught); what no list names she rates high, not emergency; at Western Slope one non-emergency report in twenty is called an emergency, and with the chain on each one rings the list. 10d: eleven graded live cycles on the Willows line overnight (05:28 to 11:01 UTC): 755 checks green, 35 red; the reds were a handful of repeating defects, most fixed and merged the same night, the rest on this page as decisions and issues.
10a. Address matching
Every home’s address was generated in the forms a caller says out loud, plus near-misses that must not match, and run through the same matcher and the same gate the emergency path uses after a call: read-only, offline, no model. A planted wrong label went red in its own run. Local harness address-matcher-eval: run 20261010T040309Z before any fix; the numbers below are the re-run on #18480 (its PR body carries the before column).
What a caller says, and whether the home is found (share found; 227 homes graded at Western Slope, 414 at Situs)
| Spoken form | Western Slope | Situs Group |
|---|---|---|
| Address exactly as stored | 99% (87 of 88) | 100% (33 of 33) |
| “Street” said as “St”, “Court” as “Ct” | 99% (85 of 86) | 100% |
| Unit given separately | 100% (114) | 100% (175) |
| Street word dropped (“1009 Colorado” for 1009 Colorado Avenue) | 99% (85 of 86) | 100% (32 of 32) |
| “North” for “N”, or the compass word dropped | 100% (10 of 10) | 100% (50 of 50) |
| House letter said apart (“2860 A”) | 100% (8 of 8) | none in the portfolio |
| Homes no ordinary spoken form can reach (stored as a range, a list, a name only, or building-prefixed units) | 1% (2 of 227) | 32% (134 of 414) |
| Filed on a wrong home from ordinary speech | 0 of 440 | 0 of 404 |
| Clear-cut near-misses that filed (wrong number, wrong street, another company’s address, invented) | 0 of 318 | 0 of 153 |
| Same number and street in another city, filed anyway (D10) | 77% (66 of 86) | 75% (24 of 32) |
Before the fixes one ordinary form filed on a wrong home (“and a half” said for a half-numbered house filed on the plain number); #18451 closed it, and the re-run files on a wrong home 0 times in 844 forms. Today a miss still starts the on-call chain on the address as spoken, with no home and no work order attached; under Fede’s ruling (no matched home: no work order, no page) a miss becomes a call where Clara keeps asking, which is the mid-call match in flight tonight. Fixes 1 to 5, 7 and 8 are live (#18451 and #18480, merged 2026-10-10, no switch); fix 6 is live too (#18495, merged 2026-10-10, no switch: a home the caller names, with no street number, is found by its name under the same one-home rule; 45 of the 51 name-only Situs homes now match). Still unreachable: 2 Western Slope homes (an identical-address pair, a data fix) and 89 at Situs: 6 with only a name on file that the name tiers cannot place, 55 on a range whose unit labels carry two hyphens (left off on purpose: a said number would be ambiguous there), and 28 on a three-building list the matcher does reach but the eval writes no variants for. A caller at one of those homes hears that nothing was dispatched and is asked for the address again (the mid-call match, #18454, makes that loop firm); every such call is logged as “no home bound, nothing dispatched”, and we read that log each morning.
Fixes, in the order they matter (each a fix with no switch; proof is this eval re-run with zero wrong-home filings)
- A street-type word, a compass word or a printed unit marker is optional when the number and the rest name exactly one home (151 of 151 such forms missed before it). Live, #18451.
- Stored ranges and lists (“8101-8195”, “3255, 3265 & 3285”) expand to the numbers they cover; a said number that equals a unit label picks that unit (163 Situs homes, 8 at Western Slope). Live, #18480.
- “North” equals “N”; “NE” never equals “SW”. Live, #18451.
- Building-prefixed unit labels (“565-101”) read as building number plus unit (36 Western Slope homes). Live, #18480.
- A house number with a letter (“2860A”) splits into number and letter; with the letter dropped, two candidates still decline. Live, #18451.
- A property name as a fallback, through the leasing matcher’s name tiers, under the same one-home rule (45 of the 51 name-only Situs homes now match; 6 do not). Live, #18495.
- “and a half” maps to “1/2”, and a half-address wins only when a half was said. Live, #18451.
- Number words become digits (“ten oh nine”), for transcripts that carry words. Live, #18451.
Not matched, by design: a lost first digit (Clara reads the address back on the call instead) and a city that disagrees with the stored one (D10). Data, not code: one Western Slope address is stored as two property rows and two Situs office suites as five and three rows; a call at those addresses matches nothing until the client merges them.
10b. The work-order corpus
Every resident-reportable work order in our read-only mirror of three clients, each written up as the one cold message a resident would send (from the staff text; no date, no photo, no follow-up question) and run through the same classifier Clara uses. Reference labels: a blind second model plus each company’s own emergency list, re-read by a stronger model on 473 rows (93% agreement); not human truth. Names, phones, addresses and units were stripped before any text entered the harness. Local harness maintenance-corpus, run large-1 (2026-10-10 06:03 UTC); classifier at 962722504a.
Of the real emergencies in the data, how many did Clara call an emergency? (heating and cooling set aside: they depend on the date, which the classifier never sees)
| Company | Orders tested (real emergencies) | Named in Clara’s rules or the company’s list | Named by no list | All together | When Clara said emergency, the reference agreed | Non-emergencies called emergency |
|---|---|---|---|---|---|---|
| Western Slope | 964 (57) | 89% (33 of 37) | 40% (8 of 20) | 72% | 55% | 5.1% (33 of 641) |
| Situs Group | 1,906 (471) | 78% (120 of 153) | 31% (99 of 318) | 46% | 73% | 1.7% (26 of 961) |
| JP&Co (Camellia) | 563 (14) | 100% (1 of 1) | 31% (4 of 13) | 36% | 83% | 0.2% (1 of 497) |
Which kinds of emergency Clara under-calls (all three companies, as sampled; share caught)
| Kind | Real emergencies | Caught |
|---|---|---|
| Flooding, burst pipe | 89 | 76% |
| Plumbing leak | 17 | 71% |
| Fire, smoke, burning smell | 13 | 62% |
| Drain or sewer backup | 85 | 51% |
| Electrical | 66 | 42% |
| Roof or ceiling leak | 120 | 33% |
| Door, lock, key | 57 | 9% |
What residents report most (whole corpus; unit-turn inspections are staff work and are left out: 15% at Western Slope, 13% at Situs)
| Company | Top five, share of all orders | After hours |
|---|---|---|
| Western Slope (1,514 orders) | AC or cooling 14%, door or lock 10%, kitchen appliance 8%, floors, walls, paint 5%, windows and screens 4% | AC 43%, water heater 61%, plumbing leak 41% |
| Situs Group (8,591) | kitchen appliance 9%, door or lock 8%, floors, walls, paint 7%, plumbing leak 5%, pests 5% | heating 49%, washer or dryer 39%, lighting 37% |
| JP&Co (584) | drain or sewer 32%, garbage disposal 10%, kitchen appliance 8%, toilet 7%, plumbing leak 6% | too few timed rows to say |
- Clara follows the lists. Named emergencies are caught 78 to 100% of the time; of the named misses the second reviewer agreed on 2 of 4 at Western Slope and 21 of 33 at Situs. What no list names she rates high, not emergency (10 of 12 and 208 of 219 misses): a work order at once, a message at every change, the morning digest, no page. Whether those should page is each client’s list (section 4), never a code change.
- Western Slope will over-page a little, and AppFolio over-pages more. One non-emergency report in twenty gets called an emergency; with the chain on, each one rings the list. AppFolio’s own rule fires on the issue picked (every AC, water heater, heater, fridge) whatever the text says: the reference calls 19% of those emergencies, and its chain rang on 211 orders AppFolio itself rated normal. The supervised week reads Clara’s false pages first.
- Ceiling leaks and lock-outs are the weak spots. Roof or ceiling leaks are caught 33% of the time, door and lock problems 9%. A lock-out at night is an emergency on some lists and not on others, and a “ceiling leak” without “flowing” reads routine; both are list wording, and both are on Western Slope’s list. Tonight’s Willows run showed the same borderline on a steady drip near a light fixture (issue #18465).
- The date matters and the classifier never sees it. With no date a heating outage reads the same in July as in January. Given the date (a what-if arm), hot-season AC outages at Western Slope go from 39% to 90% emergency and cold-season heating from 61% to 74%, while ordinary work barely moves (17 up, 11 down of 377). Western Slope’s own AC rule needs the 3-day forecast too: decision D11.
- “Troubleshoot first” on a real emergency. 2 of 57 at Western Slope and 21 of 471 at Situs were deflected to troubleshooting. One rule in the classifier: never troubleshoot a flagged emergency class (issue #18470, no switch).
- What the data cannot tell. The mirror holds 58% of Western Slope’s and 61% of Situs’s orders; Situs’s history has a 14-month hole (2023-08 to 2024-09); who reported is known for 69%, 30% and 8% of rows; the wording is synthetic and one cold message is not a conversation. Four product sync-test orders sit in Camellia’s production mirror under ids that collide with real 2018 orders (issue #18469).
Controls: a report-math self-test with planted violations; 60 planted known-answer reports, 60 of 60 right; a shuffled-reference control (recall falls to 1 to 11%); a raw-text arm on the staff wording (recall 73%, 48%, 29%; precision 97%, 88%, 80%); a call-framing arm (same priority on 83% of 182 rows). Full report: local harness maintenance-corpus, results/large-1/report.md; the scrubbed corpus and labels live in the private training bucket under maintenance-corpus.
10c. What the field documents
A read-only pass over 53 public pages: 16 products’ own pages, trade bodies, landlord-tenant law and two city datasets; 228 quotes, each labelled by source type. Quote sheet: agentic-maintenance-research.md. Nothing below is a measurement of ours; a vendor number carries no sample size unless one is stated.
Of the loop’s ten steps, how many a product’s own pages document (asks questions, troubleshoots first, photos, entry permission, resident picks a time, an emergency rule, after hours, dispatch, status updates, a follow-up survey)
| Product | Documented | Not documented |
|---|---|---|
| AppFolio Realm-X Maintenance Performer | 8 of 10 | entry permission, resident picks a time |
| EliseAI | 6 of 10 | photos, entry permission, resident picks a time, survey |
| Latchel | 6 of 10 | questions, photos, entry permission, survey |
| AI Frontdesk for Buildium | 5 of 10 | troubleshooting, photos, entry permission, resident picks a time, survey |
| The other eleven (Yardi, Buildium, Property Meld, Lessen, HappyCo, Facilio, Entrata, RealPage, Vendoroo, LetHub, Rently) | 0 to 3 of 10 each | entry permission on every one |
| A help-center portal with no AI (Green Residential) | 5 of 10 | the only page that documents entry permission: a checkbox on the form |
- Emergency lists disagree. Fire and a water leak sit on at least two of the lists read; no heat on two; nothing else repeats. There is no standard, which is why the client’s own AppFolio emergency types are the list (section 4; one list, one tier each, landed tonight).
- Residents want a person first. 82% for an urgent repair and 74% in an emergency, in a survey of about 300 renters commissioned by HappyCo and reported by Multifamily Executive; 30% are comfortable reporting an emergency to an AI. Clara’s job in an emergency is to get a person, not to be one: page-until-human, and a close that never says help is coming before someone accepts.
- No one commits to an update rhythm. Vendor pages say “proactive updates at key stages”; a help center shows received, technician contacted, scheduled, completed. None names an interval. Ours: a message at every change and “did it get fixed?” the next day.
- Permission to enter is undocumented on every AI product page. The law sets the notice instead: California Civil Code 1954 (date, approximate time, purpose; emergencies exempt), Chicago’s ordinance (two days; emergencies exempt). Ours: asked on the intake (section 3); the notice text a dispatched tech or vendor sends is open (ours).
- Industry shares, for scale. Emergency orders are 6.67% of all work orders and 66% of orders complete within 24 hours (National Apartment Association, citing AppWork 2023–24 data, no sample stated). AppFolio’s chain rings on 19% of Western Slope’s orders and 7% of Situs’s (section 2).
- Public data for the classifier. NYC’s housing-code complaints (heat and hot water is the top category: 529k building-wide rows since January 2024) and NYC 311 (one free-text column) carry labels, not resident speech. Our own corpus (10b) is the primary set; these are a supplement.
10d. The overnight Willows cycles
Eight graded cycles of the end-to-end harness on the Willows test line between 05:28 and 11:01 UTC on 2026-10-10, each against the production build of the moment. 14 scripted scenarios (13 robot calls, 1 text): routine work orders, floods, a gas smell, a leak from the unit above, several open requests at once, after hours, and a text whose reply is held for Supervised review. Every check reads the real records afterwards (the work order, the on-call chain, the office email, the Slack thread, the text log) and links the call. Counts are checks, not scenarios; a check that depends on an order another rig deleted mid-cycle counts as interference, never as a pass or a defect. Reports: local harness maintenance-e2e, results/<stamp>.md, one per cycle.
Cycle by cycle (UTC; build = the production commit under test, an arrow when a deploy landed mid-cycle; the reds in plain words)
| Cycle | Start | Build | Green | Red | What went red |
|---|---|---|---|---|---|
| 2 | 05:28 | a35ed7dc98 | 91 | 5 | leak from above never paged on the call and the source unit never asked; gas close “they’re on it”; office emailed while the chain still rang; a page result not read before the next line |
| 3 | 06:08 | a35ed7dc98 | 61 | 2 | leak from above: never paged on the call, source unit never asked |
| 4 | 06:52 | a35ed7dc98 | 81 | 7 | gas close without a callback promise; two page results came back failed (gas and flood); office emailed early, twice; three questions in one turn; “on file” said to a caller. 23 more checks void: another rig deleted the orders mid-cycle |
| 5 | 07:58 | a35ed7dc98 | 79 | 4 | gas close without a callback promise; office emailed early; two questions in one turn, twice |
| 6 | 08:55 | a35ed7dc98 → b9f0dbc02f | 71 | 2 | leak from above never paged on the call; office emailed early |
| 7 | 09:28 | b9f0dbc02f → 4639002412 | 32 | 2 | no reply to a resident’s text (a Supervised hold; now graded as documented, not red); office emailed early |
| 8 | 09:51 | 9708ae6b58 → ff29c26731 | 63 | 4 | office emailed early, twice; two questions in one turn, twice |
| 9 | 11:01 | ff29c26731 → 586cf1851b | 108 | 6 | two questions in one turn; office emailed early, twice; source unit never asked; gas close “has been reached” 38 s before anyone answered; the owner emailed “asked us something we could not answer” for a held reply |
| 10 | 12:33 | 7b32d52be4 | 73 | 1 | source unit of a leak from above not asked (D12) |
| 11 | 13:06 | 7b32d52be4; gas prompt synced 13:17 mid-run | 69 | 2 | gas close on the old prompt (the call came before the sync; repeated as round 12); a repeat call said “if the on-call person picks this up” after someone already had (#18543) |
| 12 | 13:42 | 94a62c8365 | 27 | 0 | nothing |
Rounds 10 to 12 ran this morning on the builds that carry every overnight fix (Production 7b32d52be4 from 12:30 UTC, 94a62c8365 from 13:34 UTC; the gas prompt reached ElevenLabs at 13:17 UTC). Round 11 ran its four scenarios in the harness’s own order, so its gas call came eleven minutes before the sync and was repeated as round 12. Over the eleven graded rounds: 755 checks green, 35 red, every red named above. The Willows on-call list went back to its normal entries at 13:55 UTC.
What the cycles found and what was done (merged = in main; live = in production; proof = seen green in a later cycle)
| Finding | Fix | State |
|---|---|---|
| The emergency close promised more than had happened (“a tech is being dispatched”, “they’re on it”) before anyone had picked up; seen on the first harness runs and on Fede’s own flood call | the page tool reports only what happened and the prompt reads it as given: the on-call list is being called, the first to pick up calls back (#18459, #18485) | live; no flood close went red in the graded cycles. The gas branch still improvised in cycle 9 (“has been reached”, 38 s before anyone answered): its prompt fix is in review |
| The gas-smell close said “they’ve been reached” before anyone had answered | #18534: the gas close names the on-call list being called and the call-back on this number; a flagged (not paged) result is said as given | live; proven in round 12 (“the on-call team has been alerted with your details — the first person who takes it will call you back at this number”) |
| The office email went out while the on-call people were still being tried (every cycle, every water call) | #18410 put the office email behind the chain for the mid-call page; a water call pages at the “high” tier after the call, and that path still emailed at once. #18520 (merged) and #18521 (in review) hold the office email until the chain has finished, with a 10-minute backstop; the held close tells the caller only that the team has been flagged | live; proven in rounds 10–12 (Q1, E7, E1, Q3: nothing reached the office before the chain finished) |
| Two questions in one turn, when the caller has several open requests or when Clara hands over the next step | #18502 (one request at a time) and #18527 (one question mark per turn, pinned by a test that counts them); #18529 keeps the example neutral | live; proven in round 11 (E5 and E6: one question per turn, 7 and 4 turns) |
| The owner was emailed “asked us something we could not answer” for a text whose reply Clara had written and the Supervised hold was keeping | #18528: a held reply sends no owner note | live; proven in round 10 (R3: the reply was held and the owner got nothing) |
| A ceiling drip from the unit above was never paged on the call; the after-call sweep rated it an emergency and rang the chain, and the caller heard a routine close | one emergency tier list for prompt, tool and policy (#18444); the in-call page for a drip near a light fixture is issue #18465 | paged on the call in cycle 9; whether a steady drip pages at all is the client’s list (section 4) |
| Clara never asked where the water comes from and never named the source unit (every cycle) | decision D12 | waits for Gera’s go (Fede passed D12 and D13 to Gera, 2026-10-10 08:20 MDT) |
| An unrecognised caller with no matched home | no order, no page, no calls; Clara keeps asking for the address and matches by name and address (#18433, #18463, #18489, #18506, #18524; Fede’s 9:50 PM rule) | live on 63d616c41f; Gera’s final bench call at the Fairhaven test building passed at 11:41 UTC |
| An emergency on a call where the home was pinned mid-call did not ring that home’s on-call list | #18471 | merged 11:45 UTC; not yet exercised live |
- Seen once and not again. “I don’t have any open work orders on file for your unit” said to a caller, and two page results that came back failed, all in cycle 4, inside the window where another rig was wiping the bench.
- The bench is shared. Agent Smith’s nightly evaluation (07:09 to 07:37 UTC) deleted five open orders mid-cycle; the harness now claims the bench on the engineering bridge before each cycle and blacks out 07:00–07:45 and 03:40–04:30 UTC. A re-read that finds no order is interference, never a product red.
- Proven live in the morning rounds. The held office email (#18521; rounds 10–12, nothing reached the office before the chain finished on four water and gas calls), the one-question rule (#18502, #18527; round 11, E5 and E6), the held reply (#18528; round 10, R3), the gas close (#18534; round 12). Still to prove: the pinned home (#18471), which needs the caller-number reset.
- Open issues from the night. #18465 (the drip near a light fixture), #18510 (a shared-area emergency from an unrecognised caller cannot be paged), #18519 (maintenance tools refused on a thread with an open renewal), #18526 (the office-email hold timer gives up after 30 s), #18529 (the neutral example), #18470 (a flagged emergency class deflected to troubleshooting, from 10b).
- New this morning. #18543: on a repeat or status call about an open emergency, Clara confirms the order but says “if the on-call person picks this up” after someone already had; the status answer does not read who picked up (round 11, E5 and E6). The error that fired on unknown-caller emergencies has had no event since #18433 reached production (Sentry, read 13:30 UTC, marked resolved).
- Needs Gera (Fede passed these to him on 2026-10-10). D12, D13, the Twilio flip for the caller-number scenario, the caller-number reset for the unknown-caller scenarios (one test company at a time), and the talk-over scenario (a caller speaking while the page runs) never met its own condition in any cycle.
- The prompt sync is green again. The job that copies the phone prompts to ElevenLabs failed at its last step (a workspace tool clean-up) on every push from 06:04 to 11:45 UTC; the prompts were applied each time. Gera’s #18396 landed and the 12:19 UTC run and every run since completed; the gas prompt reached ElevenLabs at 13:17 UTC.