From 08d9db4f09ef4836371deb0318ddc19841956b44 Mon Sep 17 00:00:00 2001 From: tocmo0nlord Date: Thu, 25 Jun 2026 03:20:57 +0000 Subject: [PATCH] Docs: dates are capture-and-defer (in-call computation removed) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Update the call-capture section to reflect the fix — AVA takes the day/time in the caller's words and defers exact-date confirmation to staff; the 45-day calendar injection and in-call date validation were removed after a real call derailed and the 8B model proved unable to compute dates reliably. Post-call resolved_date is best-effort/staff-verified only. Co-Authored-By: Claude Opus 4.8 --- CLAUDE.md | 34 ++++++++++++++++++---------------- 1 file changed, 18 insertions(+), 16 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index dbbc503..e23bc76 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -225,11 +225,11 @@ AB_MODEL_B= --- -## Call Data Capture & Date Validation +## Call Data Capture What AVA collects on a booking call and how it's logged. Driven by the system prompt -(`bot.py`) plus a per-call calendar injection; persisted by the post-call extractor -(`extract.py` → `practice.py` → Odoo lead). +(`bot.py`); persisted by the post-call extractor (`extract.py` → `practice.py` → Odoo lead). +Replies are kept to one short sentence. ### The six captured fields @@ -240,23 +240,25 @@ What AVA collects on a booking call and how it's logged. Driven by the system pr | Office / city | Asks city/area; never names an office unprompted | folded into `reason` prefix | | Reason | Captured from the conversation | `reason` | | Insurance | **Log only** — asks the plan, never promises/confirms/denies coverage or treatment (even a listed plan); staff verify on callback | `insurance` (note: "log only — staff to verify") | -| Preferred date & time | Validated against the calendar (below); confirmed before booking | `preferred_time` + resolved `YYYY-MM-DD` | +| Preferred day & time | **Capture & defer** — taken in the caller's own words; AVA does not compute or correct the date | `preferred_time` + best-effort resolved `YYYY-MM-DD` | -### Date validation +### Dates — capture & defer (do NOT compute in-call) -Each call's system message is injected with an **authoritative 45-day calendar** (today + -each upcoming date with its weekday), recomputed per call since the server is long-running -(`_date_context()` in `bot.py`). AVA must check any date the caller names against it. On an -impossible or weekday/number-mismatched date it pushes back and offers the correct one, e.g. -> "Next month, Monday lands on the sixth — would you like to schedule that date?" +AVA takes the day/time in the caller's **own words** ("next Monday", "the fifth") and tells +them staff will confirm the exact date on the callback. It must NOT work out, state, or correct +the calendar date, and must never argue about what today's date is. -The extractor is also given today's date so it can resolve relative phrasing -("next month, Monday") to a concrete `YYYY-MM-DD`; the caller's own words are always kept too. +**Why:** an earlier build injected a 45-day calendar and had AVA validate/correct dates in-call. +A real call derailed badly — AVA argued about the date, parroted the canned example, and (with +the model's weak adherence) also hallucinated availability. Tested directly, the local 8B model +computes appointment dates wrong ~5/5 times, so stating a computed date is a liability. The +calendar injection and in-call validation were removed (commit on 2026-06-25). -**Reliability note:** this is the local 8B model reasoning over injected facts — accurate in -testing but not guaranteed turn-to-turn. A deterministic date-resolver tool would harden it, -but in-call tools stay off for this model (it leaks JSON). Treat the resolved date as -staff-verifiable, not authoritative. Overlaps Phase 2 validation work. +The post-call extractor still gets today's date and records a **best-effort** `resolved_date` +for staff convenience — it is staff-verified on callback, not authoritative, and never spoken to +the caller. A deterministic (non-LLM) date resolver is the right hardening if accuracy is needed; +tracked as a later item. Also: never claim appointment availability or that a slot is open — +everything is a request staff confirm. ---