Camellia runs vendors on purchase orders.
We built everything on work orders.

1 · What a PO actually is at Camellia

From the full corpus — 722 POs, verbatim from AppFolio.

The PO is a vendor + trade + batch authorization token, not a per-job ticket. It's a bare sequential integer (currently in the 600s), issued by the PM (92% by Erika Wieser since 2023), and — since the Sep 2023 cutover — carrying no dollars at all: every one of the 381 modern-era POs is $0.00, unapproved-or-approved-but-never-received, and has zero bills attached (all 137 bill-linked POs are legacy backfill). The modern PO is a pure requisition/reference token — "Erika wants a dishwasher from A&K" — and the money flows somewhere outside the PO record entirely. It's what the vendor needs to submit an invoice, which is why they chase it; but nothing in AppFolio closes the loop.

Lifecycle is barely maintained — 618 Approved / 104 Pending; 71% never marked Received or Completed; the Instructions field holds the responsible person's first name ("Erika", "Joanna") and sometimes a check number. It's a paper process wearing software: on calls, the PM reads POs off a physical list. Since 2024, zero POs have bills recorded against them in AppFolio — invoice reconciliation happens outside the system too.

2 · The calls — vendors speak PO, Clara speaks work order

105 days of post-transfer transcript capture (Apr 13 – Jul 27), 58 vendor voice calls, all searched.

Every PO cited on a call exists in the mined corpus with matching vendor and job (613, 618, 644, 667, 682). The reverse is also clean: no vendor has ever cited a work-order ID in any recorded conversation. When Clara asks "what work order are you calling about?", vendors answer with a delivery, a unit, or a person's name. The mismatch is a measurable driver of the 66% transfer rate.

3 · POs in the turnover clock

231 unit turns (AppFolio unit_turn_detail) joined against the PO corpus.

The PO lands mid-turn — issued around scheduling time, consistent with the calls. The exact medians are window-sensitive (13–17d overall depending on match window), but one year-effect is robust under every check: 2025 was a real operational slowdown — median turn duration tripled (15–17d → 46d; 44% of turns blew past 60 days against a 10-day target) on AppFolio's own turn records, independent of POs, with the same staff and PO volume. 2026 has recovered, though the figure is right-censored (25 of 38 turns still open). Why 2025 happened is a question for JP, not the data. Three honest caveats: 128 turns matched no unit-specific PO — partly attribution limits (multi-unit paint batches), partly because not all PO work is turnover work; the binder study found Metropolitan's day-count "Clean House" POs are a recurring building-janitorial contract (GL: Janitorial – Service Contract), not per-turnover cleans — they belong to a service period, never a turnover; and inspection lag is not computable — AppFolio's inspection report stores only each unit's latest inspection date, and our condition reports only reach back a few months. Third confirmation of the WO disconnect: AppFolio's own Unit Turn feature has a PurchaseOrdersFromWorkOrders column — null on all 238 rows.

4 · Blast radius — every surface that speaks "work order" to a vendor

Full-code audit. Class: what the vendor sees/says. Effort: S/M/L to carry a PO instead.

5 · The design principle — per-property reference, two modes, no framework

Camellia proves POs; another property may genuinely run on work orders — AppFolio supports both and operators differ. The pivot is therefore not "switch WO→PO". It's:

Dependency-ordered backlog (from the code audit)

Decisions that are Fede's, not code's

1. Disclosure bar: may Clara read a PO number to a caller matched only by self-claimed company name (PR #4375's trust tiers), or does a PO require a phone-verified vendor? The PO is quasi-financial — current guidance forbids payment details on name-only matches.
2. Issuance scope: read-and-answer only (Clara relays existing POs), or eventually mint POs? Minting requires the unbuilt AppFolio write path (browser L4) and touches an approval workflow — recommend explicitly out of scope for the pivot's first phase.
3. Mode inference: auto-classify each property's reference mode from observed PMS data, or set it manually at onboarding? (Recommend: manual field, auto-suggested from data.)
4. The 2025 lag anomaly: median PO lag was 33d in 2025 vs 7–8d in 2024/2026 — worth asking JP what changed before we encode assumptions about their cadence.

6 · The turnover pipeline, stage by stage

Full inspection of the turnover flow vs the PO-per-trade reality, verified against prod.

Minimal first slice (no write path): sync the purchase_order report into a read-model → auto-link PO lines to open turnover jobs on (vendor, unit, GL-trade, ±14d) with a manual override → show a PO chip on the turnover detail and return it from Clara's job-list tool so she can answer "what's the PO?" on a call → swap the dispatch-email reference to the PO when present. Erika keeps creating POs by hand; PropFlow just stops being blind to them. What genuinely needs the (deferred) browser write path: minting PO numbers and true batch POs.

7 · The test harness — what flips, what holds

Full inventory of every vendor/turnover harness, eval, and drift guard.

The structural irony: Clara currently has no sayable job identifier at all on vendor calls. The eval jargon-ban forbids her from saying "work order" to a vendor; the PO doesn't exist in the domain model. Meanwhile the shipped prompt scripts a punt for the exact question ("Do you have a PO number?" → "you don't carry one… flag it to the PM"), and the graders pass the punt: transferring a PO question to a human is currently rated GOOD. The pivot flips nine sites (prompt clause, two battery rules, three eval assertions, the dynamic-var key set, the judge's source-of-truth, reply attribution) and re-rates two corpus rows from GOOD to INSUFFICIENT — while every fabrication guard stays: Clara must never invent a PO; she must retrieve the real one, and the guard moves from regex-matching to provenance-checking.

8 · What the fleet measured

Deep-dive results that refine the design. Full studies in ~/agents/006/po-training-data/.

The binder — measured, not guessed

On the modern era (2024+, the only slice with real creation dates — the 2022 series turned out to be a bulk backfill entered on four days in Oct 2022): auto-binding on (vendor, unit, ±7 days) has zero collisions across 252 unit-claims; the turnover anchor (unit + move-out window) is 99%+ unambiguous when a candidate exists. Widening to ±30d breaks real cases (same vendor, same unit, dishwasher then stove two weeks apart). The AppFolio work-order report is a dead end as a join target — 374 of 389 Camellia WOs carry no vendor and 96% are resident requests; ceiling ~5% coverage. After auto-suppressing supply runs with no unit and the Metropolitan janitorial-contract POs, the genuine PM-confirmation residue is roughly 1–2 POs per month. Honest limit: there is no ground-truth label anywhere (every PO↔WO field in AppFolio is null), so these are ambiguity measurements, not accuracy against labels.

The human workflow (the "Joanna spec")

Erika creates 99% of modern POs in AppFolio; Joanna reads them to vendors off a paper list; the Instructions field records the requester (Joanna 176 / Erika 173). Two rules the design must honor: the PO never precedes the booking (twice it didn't exist yet at booking time), and it gates the invoice, not the work — vendors start jobs without it, which is exactly why it silently rots until an invoice is blocked (PO 618 sat 9 days until the vendor chased it). The office has never once volunteered a PO unprompted in any recorded call — so proactive delivery of a fresh PO to the waiting vendor would beat human parity, not just match it. Twelve parity behaviors were specified, dependency-tagged: five buildable today (intent recognition, digit-by-digit read-back — ASR already renders PO 618 as "$6.18" — tracked promises, scheduling provenance, post-transfer silence), four blocked on the read-model, three on issuance. One corpus correction: the 05/06 call rated "fabricated unit 207 + PO promise" is partially corroborated by AppFolio (PO 618, unit 207, created that day) — re-examine before it trains anything.

Vendor roster — the gap that blocks everything vendor-facing

All 32 PO vendors resolve cleanly to prod VendorCompany rows (zero name drift — never build name matching). But 26 of 32, covering 77% of PO volume, have no phone or email on file — including Metropolitan, A&K, Home Depot, Royal Textile, Bomar. Worse: the real caller-ids of Miracle Method and A&K exist in prod as orphan Persons with no vendor membership — two disconnected halves of the same vendor. Six of Camellia's 13 preferred-vendor trades are unconfirmed email_mining entries that resolve to empty — despite the mined vendor being right 9 times out of 10 against revealed PO preference. One PM confirmation pass is the single highest-leverage unblock. Also: GL defaults must key on vendor, not trade (Miracle Method is refinishing but books 90% to Plumbing Repairs), and the trade vocabulary lacks glass, signage, doors, and any way to say "supply house, don't dispatch" — which is 31% of POs.

Cross-PMS reality check

The per-property mode is a capability, not a preference: AppFolio has POs read-only (Plus/Max API tier only); Yardi has read and write but behind a separately-licensed module (~$25K/yr) and with no PO↔WO link at all (the join only materializes on bill lines after invoicing); RealPage's AppPartner surface and Buildium have no PO API whatsoever. Consequences already reflected in the design: the mode selector needs a per-module capability probe; PropFlow must own the PO↔job binding on every PMS (it's optional-and-unused on AppFolio, impossible on Yardi); purchaseOrderNumber is a mutable, human-facing string (AppFolio allows manual renumbering; Yardi has three number fields) and storage must key on externalPurchaseOrderId. And resolution on a live call needs a PO-indexed cache, not an on-demand report scan.

The 2023 cutover, explained by the data

There was no 2023 volume dip — throughput has been flat ~10–11 POs/month since 2021. What changed in a clean 3-day handoff in Sep 2023: the PO stopped being a financial document (legacy: 100% approved, priced, 62% received, 40% billed) and became a live requisition log (modern: $0, never received, never billed, 27% still Pending approval). Ten questions the data can't answer are queued for JP — the top one: is the modern $0/no-bill pattern deliberate ("PO = notification token") or process drift? The answer decides whether PropFlow should fill those fields or ignore them.

9 · The week — end-to-end to ON

Not just phases: a Mon→Fri plan that finishes with Clara answering PO questions on real Camellia calls. Effort figures come from the code audits; the fleet's Tier-0 PRs are already in flight, so the week starts from a fixed foundation.

Deliberately NOT in the week: PO minting (needs the unbuilt browser write path — Clara relays existing POs only), batch-PO turnover restructuring (the L), and AppFolio bill ingestion (empty for the current era). The scope is: PropFlow stops being blind to POs, and Clara reaches parity with Joanna's read-and-relay job.

10 · Workstreams in flight

A 19-agent fleet is extending this document. Landing here as they complete:

• Shipping now (PRs): the attribution mis-binding fix · the internal-ID leak in vendor chase emails · attribution unification across vendor handlers · PO capture in invoice/quote parsing · harness scaffolding (stripped PO fixture + no-minted-PO drift guard).
• Research: golden dataset of all production vendor calls (WO-era vs PO-era expected handling) · WO-vs-PO industry doctrine + linking best practices · cross-PMS PO survey (Yardi/RealPage/Buildium/Entrata) · binder precision measurement on real data · vendor roster coverage cross-ref · the "Joanna spec" (the human PO workflow Clara must replicate) · corpus anomaly deep-dive (2022 regime change, 2025 lag) · Camellia mailbox vendor-email mining · draft ADR for the per-property reference design · PO read-model architecture doc.

Corpus + intermediates: ~/agents/006/po-training-data/ (722 POs, transcripts, lag joins, golden dataset). Investigation date: 2026-07-27.