The document engine: Clara prepares the paperwork

One command now does section 5 for any company. It reads the company's past renewal documents through the robot's warm session (look only: no login, stops at the first sign-in page), learns where each typed blank comes from, and writes two files: a draft recipe that passes the app's release check, and the questions the office still has to answer. A blank counts as learned when one rule fits at least 90% of at least 5 documents; anything less becomes a question. Run on Oct 21 against all three companies, the 30 newest documents each, read only.

The gate: Western Slope against the recipe we already ship. On the same 11 documents behind release v3, at v3's own bar (80% over 3), the learner finds all 6 blanks with the same field ids, the same rules and the same counts. The 11 leftover differences are all explained: part names come from the template title; it asks about the insurance email and the notice letter, because v3 got those from Fede and the setup, not from documents; v3's end date still carries a count from before the month-end ruling, which the learner correctly leaves off; and it learns the expected pre-filled parts (11 of 11). At the stricter 90% bar, original lease start (9 of 11) and special terms (blank on 9 of 11) become questions. Planted check: PASS. Swapping the start and end dates on one document flags that document, and only that one.

Situs, seen for the first time, with no manual work:

• A renewal is a whole new lease, not a one-page amendment: lease plus about 13 addenda, about 21 typed blanks.
• 10 of the 30 newest renewals used a month-to-month lease instead; the office must say when.
• Every term starts on the 1st and ends on a month end (19 of 19), the same as Western Slope's rule.
• "County of" is typed on every addendum and follows the building (89–100%); deposit, language, parking and occupants vary by tenant and are questions.
• Their login cannot open the template editor, so 6 blanks are named by the words around them until we read the field ids from the prepare form.

Camellia: AppFolio prints the dates, rent and names on the form itself; the 5 typed boxes are blank on 83–93% of documents and have no labels in what we can read, so the office has to say what each is for.

Next: a "same as their last lease" rule would likely turn Situs deposit and language into learned blanks. Building facts such as "County of" need a property-fact source wired in before any replay. Draft recipes, questions and per-document reports stay in the harness (local, no tenant names).

Goal (Fede, Oct 23): when a new customer connects their PMS, Clara learns their renewal paperwork herself. She writes a draft recipe nothing uses, plus a plain "what Clara learned" card for the team. This supersedes the Oct 21 call D3 ("no in-app onboarding flow now").

Before → after

Situs recipe card (no tenant data)

• Book: 1,836 past renewals (671 signed, 44 out for signing, 5 printed, 1,116 cancelled). 30 newest read, read only.
• Main paperwork: "Updated Lease 2026", a whole new lease with 11 addenda (19 of 30). Month-to-month lease is its own recipe (10 of 30). A 6-month template was seen once and is too few to learn.
• Term: 12 months usual; every term starts on the 1st and ends on a month end (30 of 30).
• Office questions include: who sends, the respond-by day, the renewal letter, the insurance email, occupants, pet details and fees, and how amounts are written (with and without cents).
• For us: 6 blanks are named by their surrounding words until the prepare form gives their field ids.

Dry-run onboarding transcript (Situs read; every write at the Willows)

The card in production (Fairhaven test company, Oct 23)

QA on the live page: the card loads with no error; the policy card above it still has its controls; the customer list loads. Follow-ups: #22125, #22126.

Where the ingest app fits (Gera's portfolio design)

• The learner runs after the import and never repeats its reads; it reads only past paperwork, which the import does not hold.
• Conflict 1: "import complete" does not mean leases are there (they come on the nightly pass). An automatic trigger must wait for both. Asked on the engineering bridge; not built here.
• Conflict 2: the import's customer stamp can be blank when staff run it, so the learner takes the company from the page, never from the import record.

PRs: #22099 (learner), the job + staff entry point, the Situs shape, the card. Follow-ups #22107, #22108. Records stay local; no tenant names here.

A read-only look at Western Slope's AppFolio (property 403, four paced GETs on the saved session, no sign-in, nothing written) shows their renewal defaults point at the lease template "Northridge Lease Agreement NEW LEASES" (template 3) rather than the renewals template (template 5), and the renewal addenda list does not include the one-page RENEW (SIMPLE) amendment Clara learned to fill.

Result: the typed-field check lists 9 fields today and 33 once robot PR #632 is live (24 are new-lease fields such as totals due at signing and 18 special-provision lines). Clara's filler knows only the six amendment blanks and none of these, so a robot renewal at this property would be refused before any write, on today's code and after #632 alike. The refusal is the safe direction; #632 does not change the outcome.

Open call for Fede: (a) point the property's renewal defaults at the RENEWALS template and add the amendment to the renewal addenda (a change in their AppFolio, their staff or Fede), or (b) teach Clara these fields from past documents. Recommended: (a). Until then, Western Slope renewals stay as they are today.

In: the kind (renewal, amendment, month-to-month, new lease), the terms (prior lease plus the office's typed decision, or the application, unit and policy), and the shape's active release.

Readiness, read only, before any write: eligible; no open offer (theirs wins); signers have emails; rent above zero; no past start. New leases also need the unit empty when the application converts (that is what blocked the Oct 20 test; an Available On date was not tested), screening done and the deposit decided.

Assembly: the print order is the complete list of what to put on the paper and what to leave off: parts in and out (AppFolio adds the property's defaults and the original lease's addenda itself), every value by field id with its exact text, and the options.

Park and read back: one call parks the offer "Prepared, not Sent"; then every value on the finished page must match and no blank may stay unfilled (on Oct 20 AppFolio accepted a wrong field id and parked a blank rent).

Then: at Prepare, staff press Send in their PMS; at Send, Clara re-reads, then sends. After signing, the daily status read checks rent and charges against the order.

Clara never sends an offer the office parked, and at Prepare she sends nothing at all.

Settings, head-on. Extend, don't add: the who-sends-the-paperwork setting already exists per company and building, unset means "their team", and Camellia's explicit "Clara" row stays untouched, so merging changes nothing. It gains one value: "Clara prepares, office sends". Shadow needs no setting because it writes nothing, and new leases keep the Oct 15–16 decision as built (the company's send-leases-for-signature switch plus the building's leasing status). Assumption for Fede: whether one new value counts as a "settings change" under the Sep 13 freeze (decision 2).

Two repos, never a gap. Each robot step deploys first and accepts both the old and the new request. The app moves only after that robot version shows as live on its health check. A default is deleted only after the app has sent that value on every call and a week of logs shows zero fallbacks. Each step reverts alone, and Camellia's order is proven byte-identical before any of its constants leave the robot, so there is never a window with neither guard.

Before → after: about six gates agree today before Clara sends one renewal; after, one value per company plus three rules in code.

The Oct 20 MVP ran locally, with no PR and no CI: the recipe runner learned Western Slope's recipe from 11 previews on disk, replayed them, and at the Willows filled, parked, read back and cancelled a ZZ TEST packet through the deployed robot's warm session.

Each PR is dark and mergeable alone, under about 600 lines (assumption). The compile tool (corpus pull, candidate rules and their counts, the setup report) runs locally on the subscription in November and enters Gera's ingest app as its own chain after his go. Camellia's move to full print orders and the robot clean-up are their own chain after the MVP (superseded by the Oct 21 note above). About a week for one builder (estimate).

Status. Merged 2026-10-21: #21605 door, #21652/#21653 engine + Temporal step, #21664 'Clara prepares, team sends' rung, #21655 month-end rule. Open: #21672 first caller. Next: Willows run.

Before and after

Proved, disproved, could not run

What we found in the robot

The Willows now: offers 369 and 370 cancelled; occupancy 986 shows no offer; property 45 equals its snapshot from before the writes; the ZZ TEST template and fields 1–6 are kept; 37 units, none created; 0 emails dated Oct 20. Screenshots stay local: they show test-record names.

Still to check

Setup. A seventh blank Clara has never seen was added to the Willows renewal form, plus a second addendum, with the Willows on the old prepare path. A renewal was started directly, no staff login.

Result. Clara's filler refused the form three times (one try, two retries, 21 minutes in all) and wrote nothing in AppFolio. The office then received one email: "Renewal not filled for unit 101. I couldn't fill the renewal for unit 101. The form AppFolio opened isn't the one I learned, so I left it blank." with a link to the renewal. The Willows form, addenda and setting were restored afterwards.

Two things found on the way, both fixed the same evening. (1) On the new engine path a held packet told nobody in the office; now the same one-line note goes out the same day (merged Oct 24, 20:30 UTC). (2) When the old path decides not to call the robot at all, it still reported "dispatched" and the office got a false "prepare timeout (42 minutes)" after a silent wait; a refused call now ends the renewal at once with the real reason (merged Oct 24, 20:45 UTC).

Western Slope read, Oct 24 (read only). Their live renewal setup is unchanged since Oct 20. What Clara learned fills the scattered homes, Courtyard and most of Pomona Park. Northridge, 239 S Elm, 1009 Colorado, one Pomona Park home, BCIE, Situs GJ and Ember stop with nothing written and need their own learned recipe. Plan for the week of Oct 26: Prepare rung at Western Slope (Clara fills, office presses Send). Two gates are Fede's: one park and cancel on their own form at their test property, then Renewals on and "Clara prepares, office sends".

Your question: a chosen subset of properties?

"not all properties will be enabled, do we need a chosen subset of properties eligible for the renewal engine?"

Fede's voice note, Oct 21 morning, as relayed through the Trinity DM

Today the who-sends-the-paperwork answer is read once when each renewal starts, building first, then company: a building's own row wins, a building without one follows its company's row, and a building with neither means "their team", so Clara writes nothing into its PMS (renewals as a whole can also be switched off per building or company). So no separate list is needed: the chosen subset is the buildings whose answer says Clara, and the design keeps exactly that shape, adding only the value "Clara prepares, office sends" to the same rows.

Not re-asked here

D13 is Fede's Oct 20 ruling; D14, D16, D17 and D20 stay as recommendations on the hub (section 11) and are not decided by this page.

• D13: the first fill is on a one-unit test property inside Western Slope's AppFolio; their OK is asked Oct 21 (Fede ruled Oct 20).
• D14: which documents: copy the office; Northridge and Section 8 stay with the office in v1.
• D16: texts at Western Slope wait for paper, then aim at the tenants who have not signed.
• D17: the renewal list replaces the Monday board, seeded once.
• D20: simplify first: the section 12.5 setup changes, on their OK, before the first packet.
• Moving down a rung is Fede's press only (both designers agree).
• The ZZ TEST template and its six fields stay in JP&Co's library as the Willows canary unless Fede says delete.

A new lease is the same job as a renewal: get the data, prepare the contract, send it. Same engine, same ladder. Only AppFolio's path differs, and it brings three traps: the unit, the prorated charges, rent on the ledger.

The ladder, in Fede's words

One rung per customer; only Fede moves it.

Fede's level 1 is the Prepare rung; level 2 is Send. Today Clara drafts only after a click on our review card (Gera, Oct 15); decision 9 removes the click. The "Setting today" column becomes one new company setting (below).

AppFolio's path and its three traps

Convert copies the tenant and unit from the application and cannot be reversed; leaving Lease Details posts the deposit. So everything is decided before Convert, and the park stops before Send to Tenant. These are checks and standing answers in the release, never robot rules.

The ledger check's control is the Sep 1 audit's seven misses: a first month skipped (about $1,000) and six move-ins at $0 rent (about $11,800, estimate). It must flag all seven.

What we already built

We built almost all of this once. On Sep 6 Clara drafted the lease in AppFolio as soon as the office approved, stopped before sending, and emailed the office. That was level 1. On Oct 15–16 it was retired: drafting moved behind a click on our review card, and nobody has clicked since. Clara sent one real lease, with the congrats text and email, once, at the Willows on Aug 26. No customer has ever had a lease drafted or sent by Clara. Camellia has 10 approval cards nobody acted on. Western Slope and Situs never get a card, because a missing lease policy quietly switches them off.

Camellia practice round, Oct 23 Lease parked unsent, office told

Fede said go ("ok go ahead with the practice round", then "Go."). Rerun at 7:36 to 7:38 pm MDT, after the robot's Willows-only rule came out (robot live on that merge, checked on its health page first). Clara prepared the new lease for Camellia application 126 in AppFolio, left it unsent, and emailed the office. Nobody pressed anything.

The note, as sent (name replaced; to the Camellia office address, hello@ on a hidden copy; SendGrid message vdmi9pWIRtO6-lsz8i-6Fg):

Subject: Lease prepared for <applicant>, unit 124

<applicant>'s new lease is filled and waiting for your Send

You approved <applicant> for unit 124. I filled the new lease in AppFolio and left it unsent.

What I filled
Term     Nov 1, 2026 to Oct 31, 2027
Rent     $1,200/mo
Deposit  $300
Open the lease in AppFolio  (jpco.appfolio.com/occupancies/1108)

Nothing goes to them until you press Send in AppFolio.

Clara

No Documents row: the change that adds it is not merged yet.

Monday morning: the office finds the note unread in their inbox. Opening the link shows the move-in at "Generate Lease". They check the lease and press Send, or cancel it. Correction (QA pass below): AppFolio has no Send button for a parked document. Left as Fede approved: JP&Co stays on prepare and recipe version 2 stays in use. So every new Camellia approval from now on gets a parked lease and a note, with no click in PropFlow (old approvals do not start runs). The same setting covers Yale 25 Station, which has no property software connected, so nothing starts there.

Not to plan, or worth knowing:

• The robot's first read try failed and its second passed 31 seconds later. The history does not say why.
• The "Rental Income" description went in on the robot's order, but nothing reads it back yet. Rent posts, and so becomes visible, only after the office finishes the move-in.
• Unit 124 also has application 120: approved, never converted, move-in Oct 2. Clara correctly ignored it (different move-in, not a co-applicant). The office may want to close it.
• The robot screenshot route was not used. The CLAUDE.md prefers warm-session page reads (GET only, no login) for look-only work, so these screenshots come from that path, cropped to hide the name.

QA pass on the parked lease, Oct 23, 8:20 pm Terms right, the hand-off is broken

Read only: warm-session page reads, GET only, no sign-in page, no budget errors, about 12 reads. Compared with the office's own move-ins at the same stage: occupancy 1088 (lease 885, sent, waiting for the tenant to sign, Nov 1 start) and occupancy 1090 (lease 883, move-in finished, Nov 1 start).

Decided (Fede, Oct 24, Trinity DM): "For new leases we are fine with just preparing." Clara prepares the new lease in AppFolio and leaves it unsent; the office sends. The missing Send button on a Clara-prepared lease is not treated as a problem. Camellia's renewal sending is unchanged and was never part of this question. The options below are closed and kept for the record.

Plain answer. Stopping before the send is on purpose: JP&Co is on "prepare". But AppFolio has no button to send a lease that was made and left unsent, and the move-in page does not show it. Pressing Prepare Lease, the office's natural step, builds a second lease. Options considered (closed):

1. Recommended: at "prepare", stop after the lease terms and make no document; the note says "Continue Move In, Prepare Lease, Send" and lists the terms and the total-rent box to type.
2. Keep 913; the note says "cancel the parked lease, then Prepare Lease and Send".
3. Find an AppFolio route that sends an existing unsent lease (none found in its pages or code).

Whichever: type the total-rent and part-month boxes the way the office does (recipe follow-up), and fix the note's "press Send" line.

The office note, fixed and proven at the Willows (Oct 24) Live everywhere, no switch

Fede, Oct 24: "Too verbose." Two fixes merged and reached production the same day: the note leads with one line and the lease button sits right under it; the "What I filled" table names the documents the park made. A real Willows run proved both: the test application was parked (occupancy 1109, lease document 915) and the team inbox received this note. Everything was cancelled and the Willows left as found.

Camellia new-lease recipe (read-only learn, Oct 23) Version 2 in use (Oct 23 practice round)

We read Camellia's 33 office-finished new leases (Jun 24 to Oct 23, 2026) through the warm session, GET only. That was about 41 paced reads, with no sign-in page and no budget errors. From them we wrote a recipe. Ids only on this page; the applicant boxes typed on each form were never copied here.

Replay. We ran the draft over all 33 past leases and compared it with what the office typed. A bold value is the office's; the arrow points to the engine's.

The engine would prepare 19 of the 33 (the move-in-on-the-1st ones). 14 of those 19 match the office on every field. The other five are 722, 749 and 753 (6-month terms), 761 (deposit) and 882 (rent). Planted checks all went red: ending one day early → 31 ends differ; the Willows deposit of 200 → 32 deposits differ; rent account 848 → 26 differ.

Application 126 in a dry plan (in memory, nothing sent). With the draft as stored, it is held: the rent description is under the bar. Once the description is named, it is ready: Nov 1, 2026 to Oct 31, 2027, rent 1200, deposit 300, accounts 229 and 83, form 408767.

Questions for the Camellia office (where past leases disagree):

1. Rent charge description: "Rental Income", "Rent", or blank?
2. When does a lease get 6 months instead of 12? (722, 749, 753, 776, 802)
3. Two leases end on the 30th instead of the month end (806, 911). Typo or rule?
4. 761 printed a 300 deposit; its tenancy holds 400. Which is right?
5. Is the "1 month free" special and the concession addendum 464793 still offered? No lease carries it.
6. Must the part-month and total-rent boxes be typed on a lease that starts on the 1st?
7. 882 and 694 were 1150 against a listed 1000. Was that a rent increase since, or a one-off?

What was written. One row in production, nothing else: PK=ORG#org_jpco SK=DOCRELEASE#new-lease#camellia-new-lease#V#00001. Read back identical. No pointer (…#ACTIVE), no learned record, and the new-lease setting stays team. No code change and no PR.

Update, Oct 23 evening (Fede's go): all three blockers are cleared. The robot rule is gone. Version 2 assumes "Rental Income" until the office answers question 1, and it is now in use. Application 126 parked; see the practice round. When the office answers, store version 3 with their answer.

Engine gaps this exposed (follow-ups, not blockers for application 126): no addenda slot; typed boxes left blank; mid-month move-ins are held. The learner reads renewals only, both in the app and in the robot's history route, so this read ran as a local read-only harness. Teaching the learner new leases is a follow-up.

The congrats text and email

Keep the copy as is. The text (English or Spanish) says the applicant is approved, links the resident portal to "review and sign your lease", and ends "Congratulations, and welcome home!" The email has the same lines and a "Review & Sign Lease" button. No fee amounts anywhere. It fires only after a real send: lease first, congrats second.

Proof: Willows, Aug 26, lease out at 18:23:37 UTC, congrats at 18:23:38. A congrats at level 1, once our read sees the office sent the lease, would be a new outbound: Fede's call, not in this cut.

The event: how we see an approval

Speed is fine; reliability is not yet. The trigger fires once. If that step fails, the error is logged and never retried; the next minute sees "approved → approved" and does nothing. Also, "approved at" is when we first saw it, not AppFolio's time, so after an outage or a first connect every old approval looks new.

The fix: an hourly state check, plus a nudge from the trigger. It looks for any application that is approved, not converted, without an order, and moving in on a date that has not passed. Each gets exactly one order, keyed by the application. A missed trigger is caught within the hour.

The move-in-date rule. The move-in date is the age test, not "approved at". It keeps a first run at a customer away from approvals whose move-in has passed. AppFolio's own approval date would be better, if its report carries one (unverified).

The setting: one value, three steps

One new company setting, built in the shape of the renewal setting (who sends the paperwork). It replaces the unused yes/no send switch, which has 0 rows, so nothing migrates.

• Company level only (Fede: "if that's enabled for that customer"). A building override can come later.
• Never reuse the renewal key. Camellia's renewal row says Clara, so a shared key would put Camellia's new leases at level 2 the moment the code lands. Same three words, separate key.
• Leasing Off stays the ceiling. The setting acts only at Live (decision 10).
• New customers are off twice: their modules start off, and the setting is unset.

Proposed key: newLease.paperworkSender. One entry in the existing registry and one admin picker under Leasing; no new settings registry.

Harnesses

Neither runs today's path (the card click) or the engine's print order. The Willows path the engine needs:

Planted defects the proof needs: a wrong rent on the read-back, an occupied unit, a past start date, a blank left unfilled, proration that differs from the lease.

Traps already handled vs not

The PR cut

Four PRs, each dark, mergeable alone and under about 600 lines. Level 1 needs no new ruling: drafting without a click has been allowed since Fede's Sep 4 change. Level 2 does, so it stays a local branch until decisions 11 and 12.

Cleanup (any time, no decision): delete the "change a sent lease" lane, the cancel check, the "Available On" check at capture, and the harness's live leg. After level 1 is proven at a customer: delete the card, the approve route, the Slack alert and the "Handled in AppFolio" wording.

Robot (its own chain): new-lease verbs on the print-order contract: park (convert, Lease Details with the order's values, prepare, stop before send), read back, send the parked lease, cancel. The new occupied-unit dialog answers "blocked". The defaults are deleted. Later the allowlist and the old send route go.

Open for Fede and Gera

The email the office gets when Clara has prepared a new lease and left it unsent. Real Camellia example: unit 124, the applicant (application 126), Nov 1, 2026 to Oct 31, 2027, $1,200 rent, $1,200 deposit, lease + 3 addenda. Each one is rendered through the production note wrapper and was sent to Fede on Oct 23 as "[Demo A/B/C]". hello@ gets a BCC copy in production; the demos went to Fede only.

Chosen by Fede, Oct 23: B. It answers "what did Clara fill" at a glance, and flags the one blank still open. A and C were not chosen. The production change is a separate PR.

Demo only, nothing merged. The lease link is a placeholder in the shape of a real AppFolio lease link. "Still needs you" is shown once with an example blank; in production it appears only when a blank is open. In code the PMS name and the lease link come from the PMS adapter, never a literal. SendGrid ids: A J48jiitJTY66V1WWntiWYQ, B pZ_pBAbKTpua5j19sthRVw, C AVPZG-KGRx24DeaW33UvQg.

About 76 files and 10,600 lines can go now, all in the robot. The app's renewal code is almost all live; the rest goes when the engine replaces it.

Every row was proven: nothing imports it and no script, workflow, doc, test, skill or app file names it. Anything Gera touched or reads goes to him first. Files the four robot fixes (now merged) touch were left out.

Customer-facing version: /a/western-slope-renewals-with-clara