Changelog

Part of the Anaya Care Handbook. Every change to the handbook gets a dated entry here — newest first. An entry says what changed in plain language and names the rule IDs it touched (added, changed, moved, or retired), so anyone can trace a rule's history.

Convention: when you change a handbook page, add an entry in the same change. One line is enough. Never rewrite or delete old entries.

RELEASE-DATE

• Healing Ally records wounds; it no longer judges them. On Anaya Healing Ally, nothing reads a wound photo any more: the AI's size estimate, its description, the Worth flagging note, the drafted-value badges and the draft check are gone, and the notes fields offer no AI writing help. Judging a wound is the client's healthcare providers' work, so a wound check no longer records a size, a pain level or a Better / Same / Worse call either, and wounds have no trend. A check is now a photo — still required, still from the in-app camera on the phone — and optional notes, saved in one step. The only comparison left is the wound's progress, its photos side by side. Healing Ally raises no alerts at all: the worsening alert, the overdue alert and the "photo read" notice are gone, overdue checks are still marked, and the check screen points anyone worried to a change of conditions. Wounds recorded before this change will be deleted with their checks and photos when it ships.

  • Added: HEAL-27 (placed beside HEAL-1), HEAL-28 (placed beside HEAL-10).
  • Changed: HEAL-6, HEAL-7, HEAL-8, HEAL-11, HEAL-13, HEAL-20; on AI Features, AI-21 no longer lists Healing Ally among the places the documentation helper must reach.
  • Retired, never to be reused: HEAL-4, HEAL-5, HEAL-10, HEAL-12, HEAL-14, HEAL-15, HEAL-22, HEAL-23, HEAL-24, HEAL-25.

• Plainer names for Anaya's help in the Assessment Builder. On Assessment Builder, the Assessment templates page's Anaya's help button is now AI settings, and its two switches say what Anaya does instead of listing feature names; Finish the gaps on the review page is now Ask the missing questions; and a template card says it feeds Anaya's plans, as the builder's settings already did. The Fill with Anaya button keeps its name and adds a second line, "from notes or a recording", and the template preview says once at the top how many questions Anaya can suggest an answer to, marking only the questions it won't. No rule IDs were added, changed, renumbered or retired.

• A person's own answer settles a Quote only question. Answering a Quote only question on the form — Not applicable and Not evaluated included — now settles Anaya's quotes about it, so a choice already made on the form (the Allen Cognitive Level's mode, say) no longer holds the assessment back from being completed. A quote about one row of a question is settled by an answer to that row — and only when that row's answer changes: answering another row saves the whole question again, carried answers included, and that is not the person choosing them.

  • Changed: ABLD-25.

• A proposal goes to the family only through someone who can accept it. On Care Proposals, CP-14 now says a send or resend must include at least one Care Circle member with an email — the only recipient who gets an account and can accept — with copies to other addresses allowed alongside, never alone; a Responsible Party email corrected while sending counts, and a send without such a member is refused before any email goes out. CP-15 says other addresses get a link they cannot act on, and CP-16 that the client cannot accept by link, even as their own Responsible Party. No rule IDs were added, renumbered or retired.

• A duplicated proposal's assessment leaves out signatures and asked-fresh answers. On Care Proposals, CP-3 now says what ABLD-29 already did: duplicating a proposal copies its assessment's answers as a Draft, except a signature and any answer to a question asked fresh each time. No rule IDs were added, renumbered or retired.

• Client Activities: every AI-written sheet finalizes. The Known gap on Client Activities said only the crossword and the counting sheet start as Finalizing; every sheet a run writes does, and has since hand-made activities were removed. The gap now says only that editing a sheet's words covers three types. No rule IDs were added, changed, renumbered or retired.

• Creating a client from a proposal warns about a possible duplicate. Create client record used to make a second client with the same name without a word. Its confirmation now lists any client the agency already has with the same first name, last name and date of birth, each with a link, before anything is created; staff can still create the client, or cancel. Adding a client by hand is unchanged. Clients adds CL-43 (placed beside CL-4); no rule IDs were renumbered or retired.

• The guided intake no longer renames the client or the Responsible Party. The guided intake sent the client's name as one string and saving it split the name at the first space, overwriting the name the agency had typed — a client saved as QA AI Client A / Oct7 became QA / AI Client A Oct7, and the proposal letter then said "Dear QA". The Responsible Party's name was re-split the same way (Mary Ann / Smith became Mary / Ann Smith). Now Anaya records the first and last name as two fields and fills them in only when the intake has no name yet; a Care Circle member's saved name is never rewritten. Assessment Mode AMODE-9 changed. No rule IDs were added, renumbered or retired.

• Converting an intake twice no longer makes two care proposals. Pressing Convert again while a conversion was still running — after a double click, or once the page stopped waiting after 20 seconds — could create a second proposal from the same intake. A conversion now claims the intake first, so a second one is refused with a message saying the intake is already being converted, or already was; Convert waits up to two minutes, and if that runs out it says the conversion may still finish and offers a refresh instead of another Convert. Assessments AS-4 changed. No rule IDs were added, renumbered or retired.

• A client without routine meal times no longer goes Active with Meal Assignments unfinished. A client who is not NPO and has an approved meal but no routine meal times used to have Meal Assignments waived for the Care Task List, so the list published and the client went Active with Meal Assignments still Locked. Generating the Care Task List, and publishing a Draft client's first one, now waits with "Set the client's routine meal times." When the meal times are set but fall outside every shift, Meal Assignments reads Not applicable with that reason and the Care Task List can proceed. Clients already Active are unchanged, and their republishes are not re-checked. Care Lifecycle LIFE-8 and LIFE-10 changed. No rule IDs were added, renumbered or retired.

• Healing Ally becomes the client's wound tracker. Anaya Healing Ally is rewritten around tracking a client's wounds, and now owns every wound rule. A client's wounds are pins on a body map drawn for Anaya, whose regions now include heels, elbows, ears, shoulder blades and the back of the head. Each wound records when it was first noticed and whether it was present at the start of care or appeared during care; one that appeared during care offers an incident report, linked back to the wound. A wound is Open or Healed (the Active, Healing, Chronic and Referred statuses are gone), and marking it healed offers a final photo. Each open wound has a check schedule — weekly unless changed to every visit or every N days — with due checks shown to the care provider on the client's hub and their shift, and an overdue check told to the management team once. A wound check (formerly a wound assessment) asks for a photo, from which the AI drafts only a size estimate and a plain description — no more tissue, drainage, edge or skin detail, which people were confirming without seeing it — then the person's Better / Same / Worse call, the pain level and notes. The trend now comes from that call, with the estimated area charted beside it as evidence. Only two things alert the management team now: every check answered Worse, and an overdue check (once); an ordinary confirmed check, which used to notify every manager, notifies nobody. The AI's advice shrinks to a short Worth flagging note that never alerts. Representatives can view the tracker read-only. Wounds recorded before the redesign were deleted from staging and production on 2026-10-07, with their photos. Health Readings keeps a short pointer and resolves its decision on AI wound findings (advisory only); the glossary moves the wound terms into a new Healing Ally section.

  • Added: HEAL-16 – HEAL-26.
  • Changed: HEAL-2, HEAL-5, HEAL-6, HEAL-7, HEAL-10, HEAL-11, HEAL-13, HEAL-14; HEAL-9 moves from ⚠️ Partial to 🚧 Spec only, because nothing links a wound to the care plan.
  • Retired, never to be reused: HEALTH-10 – HEALTH-19 and HEALTH-44 – HEALTH-46, each moved to or replaced by a HEAL rule named where it stood.

• My Calendar: everyone's own calendar, on the web and the phone. A new page, My Calendar, governs a calendar every member of an agency has for themselves — owners, admins, care managers, care providers, representatives and medical professionals alike — showing what they take part in: the shifts they work, the visits of the person they represent, the doctor's appointments they are the doctor for or are involved in through the client, the onboarding meetings they set up or are invited to, the trainings they owe, and every announcement their agency publishes. Each event says why it is there. A cancelled shift stays on the calendar, struck through; an unstaffed visit leaves a representative's calendar once its time has passed. It is reached from the sidebar on the web and from the Me screen on the phone, and a medical professional's Open Calendar button now opens it instead of the agency calendar, which medical professionals cannot open. The glossary adds My Calendar, Involvement and All-day item, and Client Calendar points to the new page. Adds MYCAL-1 – MYCAL-12. No rule IDs were renumbered or retired.

2026-10-06

• Template-driven intake and the Assessment Builder are live. Release #426 put both on production on 2026-10-06. The move to templates ran on staging on 2026-10-03 and on production on 2026-10-06, and the old assessment records were dropped from both on 2026-10-06. The handbook stops calling template-driven intake "being built, not released": each page's banner says it is live, the notes that described the fixed forms, the built-in inventory, value-added services and the score uplift "until it ships" are gone, and every rule it touched was checked against the code before its tag changed. Assessment Builder describes the move as done; Assessment Mode says the interview covers the care setting, the family's voice and the intake template's sections; Identity, Access & the Business loses the Spec-only note on Agency setup; Base Rates and From intake to client say their screenshots were taken before the release. Known gaps the release closed are gone: the fixed forms, the missing setup gate, value-added prices and the score uplift, the proposal's Word document printing fixed service copy, and the six care assessments being readable by linked care providers, representatives and medical professionals. Two gaps found while checking are added: an unrecorded nothing by mouth is still read as No (ABLD-15), and the materiality threshold can't be configured (RAC-13). Clients, Hospice Care Support, Routine & Habit Tracking, Client Activities, AI-Generated Task Instruction Steps, Care Lifecycle, AI Features, Assessment Builder Research and the glossary follow.

  • Now ✅ In code: ABLD-1, ABLD-13, ABLD-19, ABLD-21, ABLD-32, ABLD-34 – ABLD-38; AS-6, AS-26, AS-27, AS-32, AS-36, AS-37; CP-3, CP-19, CP-26, CP-30, CP-31, CP-34, CP-40; CA-1 – CA-3, CA-6, CA-7, CA-9 – CA-12; RATE-1, RATE-7; AMODE-7, AMODE-11, AMODE-13; RAC-16, RAC-17; ACCESS-40; and contract 8 on Care Lifecycle.
  • ⚠️ Partial, for what is still missing: ABLD-15 (an unrecorded nothing by mouth is read as No); ABLD-20 (care-plan wording drawn from agency answers still reaches client memory and job postings); ABLD-27 (agency assessments have no printout); ABLD-39 (production's old records were dropped the same day as the move, not a day later); AS-2 (the missing details and the assessment's unanswered questions are not listed together); AMODE-8 (a section with no question Anaya may fill is not a gated topic); AMODE-9 (the suggested answers come from a separate Fill with Anaya run); CA-14 (whole task lists are marked out of date, not the affected steps); CA-15 (the history can't be viewed); RAC-13 (the threshold can't be configured).
  • Moved from ✅ to ⚠️ Partial: AI-30 — a correction applied from a generation writes a revision, but nothing recomputes materiality after it, so it raises no regeneration flag of its own.
  • Notes trimmed, status unchanged: ABLD-23 and CP-38 (✅). No rule IDs were added, renumbered or retired.

• A fourth document look, Signature, and the appointment summary joins the Word pipeline. Document look offers Signature for the header and the footer, modelled on agency stationery: a fine rule with a short accent tab, the agency's square logo on the right when it has uploaded one beside its wide logo, the contact details on one centred line, and the confidentiality text set beneath them as fine print. Document look also gains a paper colour (White, Cream, or any pale colour) that fills every page of every care document, edge to edge; logos keep their transparency so they sit on it cleanly. The appointment history summary, the last care document drawn by a separate PDF engine, is now built as a Word document and converted like the others, so it carries the agency's chosen header and footer instead of an approximation of them. Staff can also read the newest visit-history summary on the client's Doctor's appointments page on the web, generate or refresh it there, and download it as a PDF or as a Word document to edit before sending. Closes the RPT-23 known gap and amends HEALTH-31 (Word as well as PDF); RPT-26 is unchanged. No rule IDs were added, renumbered, or retired.

• The idle sign-out works, on the web dashboard. ACCESS-10 never fired: the dashboard's background requests counted as activity, and a session renewing itself was never checked. Now only keyboard, mouse or touch input counts, a warning appears at 14 minutes with Stay signed in, and at 15 minutes the person is signed out and the sign-in page says why. The rule now says it covers the web dashboard only; the mobile app keeps its sessions, recorded under Known gaps of Identity, Access & the Business. ACCESS-10 changed. No rule IDs were added, renumbered or retired.

• Template-driven intake is in the handbook, decided and being built, not released. The owner decided on 2026-10-01 that every assessment runs on a template. The six care assessments become Anaya library instruments — locked templates an agency adds from the library, one copy each, placed on every client, with the licences their owners gave (the owner confirmed the Routine Task Inventory–Expanded and Allen Cognitive Level rights that day, and dropped the MNA-SF and the IDDSI numbers from the Meal Assessment for every agency, Live and Stay included). The initial assessment and the care proposal each run on a published intake template and proposal template the agency chooses at agency setup, and each agency defines its own service add-ons in place of value-added services. Converting an intake copies its answers as a draft to review when both use one template, and has Anaya suggest answers when they differ; a new client receives a copy of the proposal's answers. No assessment score changes a price any more. Until an agency is set up, its staff wait at a setup gate on the web and the phone. The old records move across once, in an offline window with a dry run, an archive of every value changed, and verification before anything is removed. Every rule below that describes this is tagged 🚧 Spec only or ⚠️ Partial, with what the product does today, and flips when it ships. Care Assessments is renamed Anaya Library Instruments (same address, same CA rules); Assessment Builder gains sections on the intake and proposal templates, service add-ons and moving the old records across, a table of which of Anaya's plans read which assessments, and the instruments' licences; Identity, Access & the Business gains an Agency setup section; From intake to client gains a step 0; Assessment Builder Research gets dated notes where the decision moved past it; the glossary swaps value-added services and Care Mentor for Service add-on and adds Library instrument, Intake template, Proposal template, Agency setup, Setup gate and Revision.

  • Added: ABLD-34 (library instruments, locked, publish rights, one copy), ABLD-35 (intake and proposal templates), ABLD-36 (convert: same template copies as a draft, a different one is pre-filled by Anaya), ABLD-37 (a new client gets a copy of the proposal's answers), ABLD-38 (service add-ons), ABLD-39 (the move to templates), AS-37 and CP-40 (no intake or proposal until setup is done), RATE-7 (rates carry hourly, overtime and live-in only), ACCESS-40 (the agency setup gate, delivered to phones by an over-the-air update).
  • Retired, never to be reused: ABLD-4 (the six as built-in forms), ABLD-33 (starters suggested by value-added service), AS-28 (the intake's inventory grounds generation), CA-4 (the client's inventory seeded Completed), CA-5 (now ABLD-32), CA-8 (inventory completeness, now the instrument's needed questions), CA-16 (the synchronized assessment generation).
  • Changed: ABLD-1, ABLD-13, ABLD-15, ABLD-19 – ABLD-21, ABLD-23, ABLD-27, ABLD-32; AS-2, AS-6, AS-26, AS-27, AS-32, AS-36; AMODE-2, AMODE-7, AMODE-8, AMODE-9, AMODE-11, AMODE-13 (the interview's topics come from the intake template, after the care setting and the family's voice); CA-1 – CA-3, CA-6, CA-7, CA-9 – CA-15, CA-17; CP-3, CP-19, CP-26, CP-30, CP-31, CP-34, CP-38; RATE-1; ACCESS-12; RAC-13, RAC-16, RAC-17; STEP-1, STEP-5; PLAN-36, PLAN-37; ENG-13, ENG-14, ENG-26; CL-25; AI-30; and contract 8 on Care Lifecycle. Hospice, Meals and Routines follow.
  • What the release will change for agencies, named now: (1) the six instruments, their screens and the client summary built from them become staff-only — care providers, representatives and medical professionals can no longer open them (ABLD-20, CA-6); (2) a Home Safety draft nobody filled reads Needs attention on every checkpoint, because the checklist moves from two states to three; (3) Home Safety's Generate recommendations button is retired — Fill with Anaya still suggests the recommendations from a visit conversation; (4) duplicating a client copies its assessments as drafts, the six instruments included (ABLD-32); (5) intake and proposal templates must feed Anaya's plans (ABLD-35); (6) the assessment-score uplift is gone: recalculating a draft proposal drops it, and figures already stored keep it (CP-34); (7) the Word document's services section is headed Services, lists the chosen add-ons, and shows "Additional $X.XX per hour" for a priced one (CP-31); (8) Care Mentor is gone; (9) generation runs in progress when the window starts are stopped, and say so (ABLD-39); (10) a reassessment finished before the move can show some suggestions as text only (RAC-16); (11) at convert, a proposal on the same template as its intake starts as a draft for staff to review (ABLD-36); (12) the Meal Assessment loses its MNA-SF nutrition screen and total, and names food textures and drink thickness in plain words mapped one-to-one from the old IDDSI numbers — stored MNA-SF answers are archived, never shown (CA-12).

• The Assessment Builder is released. Production now serves it to customers: the template library with Anaya's starters, Describe it, Snap a paper form, the builder, publishing editions, agency assessments on the client record, and Fill with Anaya from the visit conversation. Assessment Builder loses its Coming soon badge and its implementation status says it is released; the two known gaps about the coming-soon hold and the old coming-soon entries are gone, and the ABLD-20 gap now says why production holds no client memory drawn from agency answers. The client record no longer lists Caring Touch, Always Fresh and Care Bliss as coming soon: they are Anaya starters, adopted from the library and filled under the client's Agency assessments, so the Care Assessments group counts the six care assessments, and old links to those pages open the client's record or the template library. Care Assessments marks Decision 3 resolved and drops the placeholder gap; Clients says where agency assessments sit on the record and drops the placeholder follow-on; Assessments, AI Features and the glossary no longer call the builder coming soon or planned, and Assessments marks AS-26 ✅ In code (it still called the builder spec only) and drops the Known gap that only said the builder is released; Hospice says Care Bliss is a starter instead of picturing its Coming soon page, and why the page has no screenshot; Assessment Builder Research says the "Done when" measures can now be taken. Admin roles and care-manager roles saved before the module existed receive its four permissions once migration 084 has run on production. ABLD-3, ABLD-20 and ABLD-27 stay ⚠️ Partial. No rule IDs were added, renumbered or retired.

2026-09-30

• Client memory no longer reads agency answers, and the Assessment Builder page catches up with the product. On Assessment Builder, ABLD-19 now opens completed agency answers to the care plan alone: client memory stops reading them, because care providers, representatives and medical professionals linked to the client can read it, and the meal plan and care provider tasks stay closed until they are checked against clients who take nothing by mouth. ABLD-21 says the same, and ABLD-20 stays ⚠️ Partial with its known gaps rewritten. Questions gain a Carry the last answer forward setting, a new key term: turned off, a question is asked fresh on every new assessment. Supervisory Visit and Record an outside result now ask every question fresh, and Supervisory Visit is due again 90 days after the last one is completed. ABLD-29 now says a signature, and any answer asked fresh, is never carried into the next assessment or onto a duplicated client; ABLD-32 says a duplicated client's agency assessments come over as drafts, and that deleting a client deletes its visit recordings too. ABLD-26 now says recordings are made outside Anaya and uploaded, with everyone's agreement confirmed on screen first. ABLD-15's warning catches more ways of asking about a safety detail (NPO, IDDSI levels, pureed or minced food, tube feeding, Alzheimer's). ABLD-3 and ABLD-27 stay ⚠️ Partial with corrected notes: adopted copies now record which starter element each part came from, though reviewing a new starter edition into the draft is still to build; and a library template whose licence isn't confirmed is already refused, so only the printout is missing. ABLD-30 now says the Anaya library ships with the product and changes with a release, and Who can do what matches. The Care topic key term now says a topic labels a question without yet sending its answer to a part of the plan. The page describes the template setting Review due after (formerly Review reminder) and says nobody is reminded yet. The open decision on which plans may draw on agency answers is removed, now decided; the one on photos asks only what their default should be. Assessment Builder Research no longer says phase 1b is built: the meal plan and care provider tasks are not opened. No rule IDs were added, renumbered or retired.

• The Assessment Builder is built, and not yet released. Assessment Builder moves from Planned to Coming soon: the template library with Anaya's starters, Describe it, Snap a paper form, the builder, publishing editions, filling an agency assessment on the client record, and Fill with Anaya from the visit conversation are all in the product, and production shows the module as coming soon until it is released. The page is audited against the code: ABLD-1, ABLD-2 and ABLD-4 – ABLD-19, ABLD-21 – ABLD-26 and ABLD-28 – ABLD-33 are ✅ In code; ABLD-3, ABLD-20 and ABLD-27 are ⚠️ Partial, each naming what is missing. Its pictures are now the product's own screens, with fictional sample data, in place of the design prototype. It gains a Known gaps section, and two new open decisions: which of Anaya's plans may draw on agency answers, and whether photos carry into the next visit. The library is found under Assessment templates in the sidebar, not under Settings. Assessment Builder Research records where the rollout stands. AI Features, Assessments, Care Assessments, Clients and the glossary now say the builder is built and coming soon. No rule IDs were added, renumbered or retired.

2026-09-29

• A generation that is saving is no longer reported as failed. For the second or two a generation spends saving its result, a status check answered that it had finished without success, and a care-report intake read in that moment was marked failed. The end-to-end test run caught it: a task list that was about to succeed failed the journey. A status check now says the run is still going until it has completed, failed or been cancelled. Three places still treat a saving run as finished; they are listed under Known gaps of AI Features. No rule IDs were added, renumbered or retired.

• Migration 148 has run on production. The release that stores references as ids reached production, and the migration ran minutes after it: eleven kinds of reference held plain strings there and hold ids now, and the 39 people who had two notification-preference rows have one. No pair disagreed on a setting, so nothing was chosen between. Known gaps of the ten affected pages now record both runs instead of a pending one. No rule IDs were added, renumbered or retired.

• The Assessment Builder is in the handbook, as planned. A new page, Assessment Builder, governs how an agency builds its own assessments from templates — from Anaya's library, from a description Anaya drafts, from a photographed paper form, or from blank — publishes them as editions that never change, and fills them on the client record during a home visit, with Anaya suggesting answers from the visit conversation, each with its quote, for the care manager to review. Agency assessments sit beside the six care assessments and never change them; only completed ones reach Anaya's plans, and never through anything care providers, representatives or medical professionals can see. Library templates carry their licence, and Anaya never copies a licensed instrument's questions. The page is pictured with a clickable design prototype made with sample data. A companion page, Assessment Builder Research, records what state and payer rules require, how other platforms do it, what the experience research recommends, which instruments the library may include, the three designs that were compared, and the rollout plan. The glossary defines Assessment Builder, Assessment template, Edition, Agency assessment, Anaya starter, Outside result, Anaya may fill this, Support state and Requirement pack. The open decision on an Assessment Builder is settled: agency assessments live on the client record and the intake stays the fixed standard form (AS-26 and AMODE-7 reworded; whether the intake should ever take agency additions stays open). Caring Touch, Always Fresh and Care Bliss become Anaya starters, which addresses Care Assessments Decision 3. Care Assessments (a new Agency assessment term, and CA-3 pointing to the builder's AI limits), Clients and AI Features now point to the new page. Adds ABLD-1 – ABLD-33. No rule IDs were renumbered or retired.

• Care Assessments, Assessment Mode and Reassessment re-audited while researching the builder. CA-6, CA-12, CA-14, CA-15 and RAC-1 are now ⚠️ Partial and CA-16 is ✅; AMODE-8 notes the interview's eighth topic, the family's voice. The details are recorded as known gaps on Care Assessments, Reassessment and Assessment Builder Research. No rule IDs were added, renumbered, or retired by this entry.

2026-09-28

• Migration 148 has run on staging; production is next. Every reference that was stored as a plain string is an id on staging now, and the Assignments tab, the certificate lists and the training statistics read the same counts as the records. The first run stopped partway: some people had two notification-preference rows, one per form of the reference, and converting the string one would have broken the rule of one row per person. The migration now looks for such pairs under every uniqueness rule before it converts, keeps the row saved most recently, copies onto it any setting it lacks from the other, and removes the other. Its dry run lists every pair, and it refuses a pair whose rows disagree on a setting until someone accepts the kept row's values. On staging 132 people had a pair and none disagreed. Production gets the change with the next release, and the migration has to run there right after that deploy. Known gaps of the affected pages say so (Communication carries the note on preferences). No rule IDs were added, renumbered or retired.

2026-09-27

• References are stored as ids, everywhere. Ninety-seven references across thirty-four kinds of record — who wrote a post, which client an assessment belongs to, who a message was delivered to, which training an assignment is for — were declared in a way that stored whatever the code passed, so the same field held a plain string on some rows and an id on others, and lists that join on them could come back empty (the Assignments tab and My certificates did). Every such reference is now declared as an id and stored as one, and migration 148 converts the rows that already exist; until it has run on an environment, a query on one of those references can miss the older rows there. Known gaps of the affected pages say so. No rule IDs were added, renumbered or retired.

• The phone's training screens are in the handbook. Seven frames from the development build, shot on 2026-09-27 as a care provider: the Training Center with the training assigned and due, the training page, a section, the quiz and its graded result, the completion screen with the certificate and its validity, and My certificates (Trainings). Shooting them found a crash on the training page for a learner who had not started — the phone read an empty progress as a record — fixed in the same change; it reaches phones with the next build. No rule IDs were added, renumbered or retired.

• Trainings gets its screenshots. Trainings now shows the agency's list with an outline waiting for review, the proposed outline, a coverage note and the quiz step in the editor, the certificate settings, the Refine panel, a working copy, the Assignments tab with a required role, the learner's Training Center, a section held until its end is reached, My certificates, the agency's Certificates list, the verification page and the reminder setting — fourteen frames shot from the local stack on 2026-09-27. Shooting them found and fixed three bugs: a learner's first save on a section was dropped, so the section never read as started; the Assignments tab and a learner's My certificates read as empty because the lists matched references in the wrong form; and the dashboard's "read to the end" gate never opened. No rule IDs were added, renumbered or retired.

• The dashboard waits for the end of a section too, and a few doors are locked. On the dashboard, Mark as complete stays off until the notes are scrolled to their end and the video has ended or the last slide was shown, with a line saying what is left; how much of the video was actually played is recorded, so the analytics can say who skipped ahead (TRAIN-42 now in code; TRAIN-33 note updated). A training's analytics and a certificate by its id or download link now answer only to the agency, the certificate's owner or the platform team; the older notes on TRAIN-6, TRAIN-8, TRAIN-9, TRAIN-13 and TRAIN-37 say what today's work settled. No rule IDs were added, renumbered or retired.

• The dashboard shows when a certificate expires, offers Renew, and lists the agency's certificates. Every certificate on the dashboard — My certificates, a member's profile, the training page, the public verification page and the printed certificate — now says "Valid until", "Expires in N days", "Lapsed on" or "Superseded", and the verification page says outright when a certificate has lapsed or was replaced (TRAIN-43). A finished training offers Renew — the named renewal training, or the same training again as a fresh run from the first section — and a lapsed or expiring certificate offers it from My certificates; a renewal assignment is marked as one (TRAIN-44). Staff who manage trainings get a Certificates list under Trainings with search, an expiry filter and download (TRAIN-36). A learner out of attempts asks for another from the quiz screen, with a note, and the analytics mark who asked, show a learner's run number, and say in how many sections with media the learner skipped ahead (TRAIN-35, TRAIN-42). The certificate lists now carry the expiry fields and the renewal flag. No rule IDs were added, renumbered or retired.

• An agency chooses how far ahead it hears that a certificate is expiring. Settings › Business gains a Training certificates block: the number of days before a certificate expires that the care provider and the staff who assign trainings are reminded, 7 to 90, blank for the platform's 30. The nightly sweep holds each certificate to its own agency's lead time (TRAIN-43). No rule IDs were added, renumbered or retired.

• The training editor has a Refine panel and certificate settings. A Draft, a Rejected training or a working copy can be changed by asking from the editor's own header — once the editor's changes are saved, so the request works on what is stored — and the editor reloads the refined sections when the run settles; a platform training cannot be refined yet (TRAIN-22 now in code; AI-34 amended). The Basics step gains a Certificate block: how long a certificate stays valid (never, 6, 12, 24 or 36 months, or a number of months) and which training renews it — the same training again, or a shorter published training the author picks — and the Review step says so (TRAIN-43, TRAIN-44). No rule IDs were added, renumbered or retired.

• The phone shows when a certificate expires, and offers Renew. From its next build, every certificate on the phone — in My certificates, on the training page and on the completion screen — says "Valid until", "Expires in N days" (from 30 days out), "Lapsed on" or "Superseded" (TRAIN-43). A finished training offers Renew: the shorter renewal training its author named, or the same training again as a fresh run that starts at the first section and leaves the current certificate valid until it expires; a lapsed or expiring certificate offers the same from My certificates, and a renewal assignment is marked as one and sits under Assigned, not Completed (TRAIN-44). The assignment list now carries the renewal flag and, for a training not in the learner's list, its stored duration (TRAIN-32). No rule IDs were added, renumbered or retired.

• Anaya asks when the brief is unclear. When a training brief does not say who the training is for or what it must cover, and the documents do not settle it, the outline run now asks one clarifying question — with choices when the likely answers can be listed — and waits durably, as any generation does (AI-24). The question shows in the generation dialog where the author is and in the generation dock, is answered once, and the answer is folded into the outline and carried to the write run; a clear brief gets no question, and a second question is refused (TRAIN-21 now in code). The backend deploy that carries this reshaped training run is drain-gated: ship it when no training run is in flight. No rule IDs were added, renumbered or retired.

• The dashboard's assignment screens are built. From a training's page or a team member's profile, staff assign a training to people, to a role or to everyone in a role, with a due date and note (TRAIN-29). The analytics page lists who is assigned, in progress, completed and overdue with each learner's quiz results, marks the training required for a role and clears it (TRAIN-30, TRAIN-38), and resets a learner's attempts; a member's profile lists every training assigned, started or completed and their certificates, and offers the same reset (TRAIN-35, TRAIN-38). The catalog offers Preview and tells an added copy when the catalog has a newer version (TRAIN-27), and a voided training's page offers Restore to draft, which the editor's void dialog now says (TRAIN-28). No rule IDs were added, renumbered or retired.

• The dashboard's editor shows what Anaya is still making. The cover, each section's slides and narration, and each quiz show their job's state — queued, being made, ready or failed — with Retry for a failed one, and a section drafted beyond the documents shows its coverage note, where its words came from, and a Dismiss (TRAIN-19, TRAIN-21). The training's card shows an outline waiting for the author with Review outline, the writing under way with Open progress, media still on the way, and a failed run with Try again, so closing the generation dialog loses nothing (TRAIN-20, TRAIN-23). Opening a published training in the editor opens its working copy, creating one when there is none, with a banner, the way back and a Discard, and Publish on the working copy replaces the published version or submits it for review (TRAIN-24). The Basics step shows the estimated duration and lets the author override it (TRAIN-17). No rule IDs were added, renumbered or retired.

• A training draft can be changed by asking. A draft, or the working copy of a published training, can be refined in plain words like a care plan: the request is recorded before the run starts, the run reads the training as saved — hand edits included — and returns every section with its id so nothing the request did not reach is lost, what changed is measured on save rather than taken from the model's word, and the conversation stays with the training; a cancelled or failed request settles as such (TRAIN-22; AI-34 now lists trainings). Server side and the shared refinement panel's wiring; placing the panel in the editor follows. No rule IDs were added, renumbered or retired.

• Certificates can expire, and are renewed by a fresh run. A training can carry a validity period; its certificate then shows an expiry date, the care provider and the staff who assign trainings are told once 30 days ahead and once on the day it lapses, and a lapsed certificate reads as lapsed and is never deleted (TRAIN-43). Renewing means starting the training again as a fresh run — the earlier run and its certificate are kept — or completing the shorter renewal training the author named; either issues a new certificate with a new number, and the old one stays verifiable as superseded. A required training whose certificate is about to lapse is assigned again on its own as a renewal, due on the expiry date, without inheriting the old run (TRAIN-44; TRAIN-13 partly built). Server side; the validity field, the Renew button and the expiry on the screens follow. No rule IDs were added, renumbered or retired.

• Assignments tell people things, and a role can be required to train. A learner is notified when a training is assigned to them, reminded three days before the due date and on the day, and told once when it is overdue — as is the person who assigned it, who also hears when the learner completes it; overdue is derived from the due date and moving the date later clears it (TRAIN-31). Staff can assign a training to one person, to everyone in a role, or to a custom role, change the due date or note, and remove an assignment that is not completed (TRAIN-29). An agency can mark a published training required for a role: everyone in the role is assigned it, and anyone who joins later gets it on joining, due 30 days on unless the agency chose otherwise (TRAIN-30). For any training, staff see who is assigned, in progress, completed and overdue, and for any member, every training and certificate (TRAIN-38). The agency's training managers are told when the platform team approves a training or sends it back, and a learner out of attempts who asks for another is heard by the staff who assign trainings (TRAIN-26, TRAIN-35). All of this is the server's side; the dashboard's assignment screens follow. No rule IDs were added, renumbered or retired.

• The phone's training screens are rebuilt for the next build. The Training Center starts from what is assigned and due, then what is in progress, available and completed, with a My certificates tab (TRAIN-32); a section shows its media first and its notes open, slides play with their narration, uploaded and YouTube videos play inside the app, "Mark as complete" waits until the end of the notes and the media is reached, and the app reopens where the learner left off (TRAIN-33, TRAIN-42); the quiz shows the server's graded attempt with the explanations and the attempts left, and a learner out of attempts can ask a manager for another (TRAIN-34, TRAIN-35); finishing opens a completion screen that waits for the certificate, with view, download and share (TRAIN-36); every duration comes from the shared estimate (TRAIN-17). Publishing on the server now refuses an incomplete training and names what is missing (TRAIN-25); a published training can be edited as a working copy that replaces it when published, or approved (TRAIN-24); a training is voided only from Draft, Rejected or Published and can be restored (TRAIN-28); an agency's training managers can read a catalog training before adding it, and a copy knows when the catalog has a newer version (TRAIN-27); the verification page names the agency, and a certificate's document can be rendered again (TRAIN-36, TRAIN-37); a duplicate keeps its quizzes, slides and captions. No rule IDs were added, renumbered or retired.

• Quizzes are graded on the server, and a pass stays a pass. Every attempt now counts toward the limit, passed or failed, and the limit is checked before scoring; a section whose quiz was passed stays passed and complete whatever a later attempt scores, and only the best score is kept. The submit call returns the graded attempt — each question with the learner's answer, the right answer and the explanation, and how many attempts remain — and a client that asks (the dashboard does; the phone will once its next build is out) no longer receives the answers with the training at all (TRAIN-34). A learner out of attempts can ask for another, and a manager can grant a fresh set, keeping the old attempts for the analytics (TRAIN-35, server side). How much of a section's media was played and when its end was reached are recorded (TRAIN-42, server side). No rule IDs were added, renumbered or retired.

• The dashboard's training screens catch up with the page. A certificate now prints anayacare.com/certificates/<number> and a QR code, and that public page confirms the certificate (TRAIN-37). In the editor, Publish saves first and says what it will do — Publish, Submit for review, Resubmit for review or Unpublish — the wizard has a way out that asks about unsaved changes, and a menu with Preview as a learner, Analytics, Void (confirmed, only from Draft, Rejected or Published) and Delete (TRAIN-25, TRAIN-28). A reviewer, or anyone with a preview link, reads the whole training without starting progress, with the quiz answers shown, and a pending training can be approved or sent back from its own page (TRAIN-26). The catalog marks what the agency already added (TRAIN-27). For learners on the dashboard, notes are open, slides are shown, Continue after a passed quiz goes on to the next section, the training page waits for the certificate, every duration comes from the shared estimate, and the Training Center starts from what is assigned and due, with a My certificates tab (TRAIN-17, TRAIN-32, TRAIN-33, TRAIN-36). No rule IDs were added, renumbered or retired.

• Anaya drafts a training in two steps, and says where the documents fall short. Asking Anaya for a training now proposes an outline first — title, description, sections with a line each and the documents each draws on, plus which learning objectives the documents do not cover — for the author to rename, reorder, add to, ask again about in plain words, or accept; only then are the sections written, and the write refuses a draft that does not match the confirmed outline (TRAIN-18). The brief offers Short, Standard and In depth lengths, a warm or professional voice (the academic tone is gone, TRAIN-41), and quiz defaults that every generated quiz follows. A brief with no documents drafts from general caregiving knowledge and marks every section and the description as such (TRAIN-39). Each section keeps its key points and, where the documents leave a gap, a coverage note that a rewrite or a dismissal clears (TRAIN-21). The cover, each section's slides, narration and quiz are now separate jobs with their own state and a retry endpoint, and the generation job is completed, failed or cancelled to match (TRAIN-19); a failed run can be tried again from the same brief and outline (TRAIN-20). Every training carries an estimated duration from one shared rule (TRAIN-17). No rule IDs were added, renumbered or retired.

• A training Anaya drafts becomes a Draft again. Since the durable training agent replaced the old loop, a training drafted from the dashboard stayed "Generating" for ever when any media was asked for — which the dashboard always did — and asking for a cover photo crashed the media step on a draft it was never handed. The draft is now saved as a Draft the moment its sections exist, the media is made afterwards without ever holding the status, a cancelled run keeps the sections written so far or removes the placeholder when nothing was written, and a failed run says so on the card instead of spinning. TRAIN-3 is in code again; TRAIN-19 and TRAIN-20 are partly built (no per-section media states or Retry yet). No rule IDs were added, renumbered or retired.

• Trainings: the open decisions are decided. Every question left under Decisions needed on Trainings this morning is now a rule. With no documents selected, Anaya drafts from general caregiving knowledge and says so on every section, and a coverage note on a grounded draft offers to write that one part the same way, marked (TRAIN-39; TRAIN-11 amended to say so). The platform team drafts catalog trainings from a platform library of its own (TRAIN-40). Plain words govern every training as AI-33 says; the brief's audience changes the examples and which exact terms are named, never the reading level, and the academic tone goes (TRAIN-41). "Reached the end" means the notes and the media both, skipping ahead allowed but recorded and shown in the analytics (TRAIN-42; TRAIN-33 amended). A certificate can carry a validity period: the care provider and the agency are reminded 30 days before it expires, or at a lead time the agency sets, and told on the day; a lapsed certificate reads as lapsed and is never deleted (TRAIN-43). Renewal is the same training again or a shorter renewal training the author names, issuing a new certificate with the old one still verifiable as superseded, and a required training is re-assigned on its own before its certificate lapses (TRAIN-44). A renewal is a fresh run through the training, so TRAIN-8 now says one current certificate per training, TRAIN-10 carves the renewal assignment out of inheriting old progress, and TRAIN-21 lets the author ask for a gap to be filled from general knowledge. The glossary defines Platform library, Validity period and Renewal training. Adds TRAIN-39 – TRAIN-44; amends TRAIN-8, TRAIN-10, TRAIN-11, TRAIN-21 and TRAIN-33. No rule IDs were renumbered or retired.

• Trainings: the flow the module is moving to. Trainings now describes how making, assigning and taking a training should work, decided on 2026-09-27 and to be built next, after an audit of the dashboard, the phone and the backend. Anaya drafts in two steps — an outline the author confirms, then the sections — and a training is Generating only while the sections are written; the cover, slides, narration and quizzes are made afterwards as separate jobs per section, each with its own Retry, so a failed one never fails the training (TRAIN-18, TRAIN-19, TRAIN-20). Where the documents do not cover an objective, the draft says so with a coverage note instead of filling the gap (TRAIN-21), and a section can be refined by asking, like a care plan (TRAIN-22; AI-34 amended to name trainings). Every training gets an estimated duration in place of the fixed "~3 min" every screen shows today (TRAIN-17). A published training is edited as a working copy, so learners see the published version until the change is published — and, for an agency, reviewed again (TRAIN-24, which settles the known gap against TRAIN-2). Publishing saves first and checks the training is complete, the button says whether it publishes or submits for review (TRAIN-25), the reviewer sees the whole training and decides from it (TRAIN-26), catalog trainings can be previewed and a copy knows when a newer version exists (TRAIN-27), and voiding is confirmed, limited to Draft, Rejected and Published, and reversible (TRAIN-28, which closes the "Retiring a training" decision). Assignments get their screens — from the training or the team member, to people or a whole role, with a due date — plus required trainings for a role that new members are assigned on joining, reminders three days before and on the day, one overdue notice to the learner and the assigner, and a completion notice (TRAIN-29 – TRAIN-31, which close the "Assignment notifications" decision), with a per-training and per-member view of who has done what (TRAIN-38). For learners, the Training Center starts from what is assigned and due (TRAIN-32); notes are shown open, slides play in the app with narration and captions, YouTube plays in the app, and a section completes only once its content has been reached to the end (TRAIN-33); quizzes are scored on the server only, the answers reach the device after the attempt, a passed quiz stays passed, and a learner out of attempts can ask a manager for a reset (TRAIN-34, which settles TRAIN-6; TRAIN-35); finishing shows a completion screen with the certificate, there is a My certificates list, and each certificate has a public verification page with a QR code (TRAIN-36, TRAIN-37, which settles TRAIN-8). The glossary defines Brief, Outline, Coverage note, Media, Estimated duration, Working copy, Required training, Attempt reset and Verification page. The page's status notes and Known gaps record what the audit found, including that a training Anaya drafts from the dashboard today never leaves Generating. Decisions needed asks whether AI-33's plain words govern training content or the brief's audience and tone do. Adds TRAIN-17 – TRAIN-38; amends the status of TRAIN-3, TRAIN-6, TRAIN-8 and TRAIN-9, and AI-34. No rule IDs were renumbered or retired.

2026-09-26

• From Intake to Client: the whole path on one page. A new walkthrough, From Intake to Client, follows one prospective client from the first intake through the care proposal, internal review, the family's decision and the new client, with a screenshot of each screen. The screenshots come from the end-to-end test that walks the same journey, with fictional names, so they can be taken again whenever the screens change. The page states no rules of its own. No rule IDs were added, renumbered, or retired.

• Editing a Ready intake reopens it, as the handbook already said. AS-3 and AS-34 have said since 2026-07-18 that editing a Completed initial assessment reopens it to Draft, and both were marked in code, but it was never built: an edited assessment stayed Completed and could be converted with whatever the edit left. Now any change to its content reopens it, with "Reopened by editing" in its history; a save that changes nothing does not; and the ⋯ menu has Reopen as draft. The status notes of AS-3 and AS-34 say so.

• An intake needs what its proposal needs, and Convert asks first. Completing an initial assessment now also needs the client's last name and a full address with city and state — the fields the converted proposal must have before it can be submitted — and converting checks those rules again on what is stored. Convert opens a confirmation first, since it cannot be undone. An assessment can be archived and restored from its ⋯ menu, shows a banner while archived, and cannot be completed until it is restored. Deleting an assessment offers to delete its proposal only to someone who may delete proposals, and the other way round. Amends AS-2, AS-4, AS-9 and CP-26.

• Care managers can cancel their proposals until they are approved (CP-21). The rule said only approvers could cancel, while the product offered care managers a Cancel button and then refused it. Decided for care managers: anyone with Care Proposals Manage can cancel a proposal in Draft, Pending Approval or Revisions Needed; from Approved on, it still needs an approver. The lifecycle diagram also gains the approver's cancel from Representative Accepted, which the product always allowed. Amends CP-4 and CP-21.

• The family never sees the agency's internal review (CP-39). A representative could open the agency's first review round from the family portal and read the reviewers' comments, names and replies. They now see only the rounds they took part in, and only the entries written for them. Adds CP-39.

• "Round" means a review round; a request for changes is a revision. The proposal's badge counted requests for changes and called them rounds, while the review page counted review rounds, so one proposal could read "Round 2" on one screen and "Review round 3" on the next. The badge and the history now say Revision (the history starts with "Original proposal"), and the history lists every reviewer again after a family round-trip. Care Proposals defines Revision next to Review round, and also describes what a send reports when some addresses fail (CP-14), Updates since last review, the review outline's section count, and Send to family as the header's next step at Approved. No rule IDs were renumbered or retired.

• Saving an intake's schedule works again. Since 2026-09-23 on staging and 2026-09-25 in production, a save of an open initial assessment that carried its weekly schedule — nearly every autosave from the dashboard — failed with "Failed to save", because the stored rate table held an internal id that the schedule rule (CP-34) tried to treat as a rate row. No rule changed; CP-34 describes what happens again.

2026-09-24

• Finance's data is ready in production. The timesheet backfill (migration 147) and the finance permission grant (084) ran on production with the release, so the Finance known gap now says only that the module itself is not yet released. No rule IDs were added, renumbered, or retired.

• Crafts and games keep food away from a client who takes nothing by mouth, and no craft, food craft or game uses what a client is allergic to. When the meal assessment says a client takes nothing by mouth, a Care Crafter or Timeless Treasures sheet now has no food or drink in it at all — not as a material, prop, prize, reward or break — and no tasting. The care manager is not asked, because neither sheet needs food. For a recorded allergy, all three sheets also leave out things made from the allergen, both in what the client uses and in the pictures: seashells and mother-of-pearl for a shellfish allergy, balloons and rubber bands for latex, nut shells and acorns for nuts, eggshells and egg cartons for egg, flour, pasta and play dough for wheat or gluten, fresh or dried flowers, grass, hay and pine cones for pollen, and feathers and down for a feather allergy. Look-alikes such as paper flowers or plastic eggs are fine. A sheet that breaks one of these limits is written again rather than kept. Client Activities says so under "How it works" (ENG-26 amended). No rule IDs were added, renumbered, or retired.

2026-09-23

• The planned pages show what exists today. Every page marked Planned or Future now carries a screenshot of the nearest thing the product already has, captioned with what that screen does and what the page still asks for, so the gap is visible rather than only described: the Coming soon Care Bliss assessment for Hospice, a task's instruction steps for Task Instruction Steps, the Montessori profile's Daily Rhythms for Routines, a shift's Location tab for Anaya Walk, the Coming soon Directory for the Elder Services Marketplace, a client's medical professionals for Care Coordination, in-chat calling for Telehealth, the phone's Send Feedback sheet for Feedback, the phone's settings for Accessibility, regional preferences for Multi-Language Support, the medical record's equipment list for Adaptive Technology, account deletions for Data Ownership & Retention, a shift's clock record for EVV Compliance, the Training Center for Gamification, connected accounts for Integrations & API, a care provider's assignments for Performance Evaluation, and Platform Logs for Security & Compliance. Offline Mode has nothing to picture yet and says what little exists. No rule IDs were added, renumbered, or retired.

• A proposal's rate rows follow its schedule when the schedule is saved. The Hourly Rates Reference should list the shift lengths the client is being quoted, but its rows only moved to match the schedule when someone clicked Calculate Rates, so changing the schedule left the PDF showing the old rows or the 2-, 4-, 8- and 24-hour preset every record starts on. Saving the schedule now moves them, on the initial assessment as well as the proposal. A row someone included or hid by hand stays as they set it; on the initial assessment the next recalculation used to undo it. With no schedule, the preset is still shown. Amends CP-34. No rule IDs were added, renumbered, or retired.

• Saving an edit to a training no longer sends it back to draft. Every change to a training used to reset it to draft, even when the change said nothing about status, so any fix to one of the platform team's published trainings unpublished it, and an agency could bring a voided training back to draft by editing it. An edit now keeps the training's status unless it sets one — the dashboard's edit form no longer saves every change as a draft, and only its Save as Draft button takes a published training back to draft — and a voided training stays voided. Trainings adds a known gap: an agency's edit to a published training reaches learners without a second platform review (TRAIN-2). No rule IDs were added, renumbered, or retired.

• Draft announcements stay with the people who manage announcements (COMM-42). The announcements list needed only the view permission, which care providers, representatives and medical professionals hold by default, and it showed them every draft and scheduled announcement in the agency, with a count of each. An announcement's statistics answered for a draft too, and the list of who had acknowledged one had no permission check at all. Now anyone without the announcement-management permission sees only published and past-deadline announcements, the counts cover only those, statistics for a draft or scheduled one answer "not found", and the acknowledgment list needs the management permission. Communication's who-can-do-what table says the same. Adds COMM-42. No rule IDs were renumbered or retired.

• Screenshots of the product, and status that matches it. Forty-three pages now show the screens they describe — the dashboard, and the care provider's phone where the work happens there — taken from staging with names, emails and addresses replaced or blurred; click one to enlarge it. Four pages had a status that no longer matched the product. Home Inventory is released, so it loses its "Planned" badge and gains its first audit: ten rules in code, INV-9 and INV-11 partial, and five new known gaps where the product differs from the page. Essential Needs, Anaya Wallet and Finance are built but held back from customers, so they now read Coming soon — the product's own word for them — instead of "Planned" or nothing. Essential Needs is audited rule by rule for the first time (NEED-1 – NEED-30; NEED-8, NEED-11, NEED-17, NEED-19 and NEED-22 were marked spec only but are built or part-built), and NEED-21 now counts its terminal states correctly as three. Finance and Anaya Wallet move out of "Planned infrastructure" into a Money group, and the index lists every page again.

• Crafts, food crafts, games and Memory & Reading are written by the AI, and nothing is "coming soon" any more. Care Crafter, Culinary Crafts, Timeless Treasures and Memory & Reading are now generated from the Care Prints engine, the same way Care Prints writes them, so the picker's "coming soon" group is empty and the Known gap "Nothing makes a new Memory & Reading sheet yet" is gone. Client Activities explains them in a new section under "How it works". Each asks for a page layout, chosen from sketches of the page and fixed once the sheet is made; Memory & Reading also asks how many questions follow the story, from 1 to 20 and five unless changed; Care Crafter no longer asks how involved the craft should be (ENG-3 amended). Craft, food and game sheets now get a picture for every step as well as the main photo. They are drawn after the sheet is made, in order, each from the one before, and a Draw all button makes the missing ones and stops at the first failure (ENG-25, new). Craft sheets made before this keep their one photo. A new Memory & Reading sheet's one picture is its background, drawn on request like the others, and the sheet waits for it. Food crafts follow the client's recorded allergies, diet and swallowing notes, crafts and games leave out allergens, and for a client who takes nothing by mouth the run asks the care manager first and writes a food craft only as a hands-on activity with no eating or tasting (ENG-26, new). Two Known gaps were out of date: every type but three now has settings of its own, and every picture type is drawn on request. They now say only what is still open: Word Grid, Coloring Page and Canvas & Colors have no settings yet, and apart from Memory & Reading a sheet prints without a background until someone asks for one. No rule IDs were renumbered or retired.

• Memory & Reading is edited as words, and nothing is made by hand any more. The canvas that drew Memory & Reading sheets is gone, and with it the only way to create a client activity by hand, so every activity is now written by AI and starts as Finalizing (ENG-2, and the summary under "How it works"). Sheets already in a client's bank stay there, and can still be viewed, approved, and printed. A care manager now changes their words in the same Content panel a crossword uses: the title, the story, the heading over the questions, and the questions with their answers, while the print layout, styling, and background picture stay as they were (ENG-23). The worksheet AI does not generate Memory & Reading yet, so Known gaps says nothing makes a new one. No rule IDs were added, renumbered, or retired.

• Finance is in the handbook. A new page, Finance, governs what an agency pays its care providers and bills its clients for each pay period, priced from the hours care providers actually clocked and the hourly pay and bill rates in force on the day. It covers the rates and the pay-period calendar, rounding, the flags a person must settle before a period closes, closing a period and carrying later changes forward as adjustments, bonuses, reimbursements, deductions and refunds for purchases a care provider paid for themselves, the payroll and billing exports, and correcting or adding a timesheet — whose hours are now kept, and still paid and billed, when its shift is deleted. Essential Needs now records who paid for a purchase, and Anaya Wallet says what that changes for a care provider who fronts the money anyway: it is visible and repaid, not acceptable. That page's open decision on what a provider pays with at the till, and the known gap beside it, now say the same, and the decision stays open. Identity & Access adds finance:view, finance:rates, finance:close and timesheets:manage to the permission catalogue, and the glossary defines Pay period, Rate version, Per-client pay rate, Bill rate, Adjustment, Flag review, Incomplete record, Line item and Wallet refund. Adds FIN-1 – FIN-17; amends NEED-3, and the status notes of NEED-12 and WALLET-19. No rule IDs were renumbered or retired.

• Rates now fall back city → state → base, and the catalog ships pre-filled. Base Rates gains a state rate tier between city overrides and the single base rate, seeded from the CareScout (Genworth) Cost of Care Survey 2025 medians for the nation, all 50 states and the District of Columbia, and the principal cities of every surveyed metropolitan area. Every rate lookup now reports which tier applied, a rate staff set by hand is never overwritten by a re-seed, and changing the base rate re-checks every state and city rate. The glossary defines State rate. Amends RATE-2, RATE-3 (now built as written), RATE-4, RATE-5, and CP-34; adds RATE-6. No rule IDs were renumbered or retired.

2026-09-22

• A person's profile no longer opens across agencies (ACCESS-39). Looking someone up used to return anyone on the platform to anyone signed in. Now a profile opens for the person themselves, for platform staff, and for colleagues in the same agency. Across agencies it opens only for someone who belongs to no agency, such as an independent care provider, whom the marketplace already shows to everyone, or for a care provider who has applied to the viewer's agency, whatever became of the application. A birthday check that showed any member's date of birth, even to representatives and against the member's own feed opt-out, was removed, which closes that Care Feed gap. Identity & Access rewords its lookup gap to what remains. Adds ACCESS-39. No rule IDs were renumbered or retired.

• Four known gaps were out of date, and now say only what is still open. Care Lock already keeps each agency's documents inside that agency, so the gap against OPS-11 is gone. Emergency alerts no longer carry acknowledgment permissions that do nothing; what remains is that nobody can list or acknowledge an alert (SOS-7). Acknowledging a change-of-conditions note already needs health-monitoring rights; what remains is that a draft can be acknowledged (COC-4). Submitting the same dose twice is now refused, but two near-simultaneous submissions, or deleting one and recording the dose again, still count it twice (MED-13). No rule IDs were added, renumbered, or retired.

2026-09-21

• Walkthroughs are on the agency dashboard, not only one client's Care Circle. Staff with client-management permission see every invite for their agency under Client Care → Walkthroughs. SuperAdmins still use the console list to host rooms and paste a join URL. Amends CL-37 and CL-42 who-can-do-what; no rule IDs were added, renumbered, or retired.

• Client onboarding meetings are in the product (CL-36 – CL-42). Staff invite from Care Circle or a Draft overview; guests book or manage from a public token link; Anaya hosts Zoom/Meet on the same calendar as sales demos, with occupancy as a half-open interval. SuperAdmins see family walkthroughs on a list distinct from Demo Bookings. No rule IDs were added, renumbered, or retired.

• An agency can invite a client or family member to a walkthrough of how care will run on Anaya Care. That call is a client onboarding meeting: staff pick a time, or send a booking link so the guest picks a slot and Zoom or Google Meet, and Anaya hosts the room on the same calendar as marketing-site demos so the two never overlap. It is not portal access, not the guided family-onboarding flow (CL-27), not telehealth, and not the sales Book a Demo. Clients adds the meeting to Family onboarding; the glossary defines the term. Adds CL-36 – CL-42. No rule IDs were renumbered or retired.

• Document look is a shortcut on care documents, and visible in Settings without full permissions. Staff can open header, footer, and colour from a care proposal, care plan, summary, shift report, or period report — and from Settings → Document look — even if they cannot edit the rest of the agency. Saving still requires business:settings. Amends RPT-26; identity catalogue wording for business:settings updated. No rule IDs were added, renumbered, or retired.

• Client activities are Care Prints worksheets, not Anaya stationery. The printed sheet carries Care Prints' lockup (puzzle heart, Care Prints, CARE YOU CAN PRINT, care-prints.com, 1.888.896.8275) and the maker chrome uses Care Prints' clay theme; the client and Anaya sidebars stay Anaya. Client Activities now names that partnership; the glossary replaces the Montessori craft/cooking session definition; AI Features drafts a Care Prints worksheet rather than an illustrated Montessori session. RPT-26 is explicit that Care Prints worksheets are not care documents and do not take the producing business's branding. No rule IDs were added, renumbered, or retired.

2026-09-14

• Filing an incident report no longer carries reviewing it. Incident Reports has always named Owner, Admin, and Care manager as the people who review, resolve, and share a report, but the product gated all three on the same permission a care provider files and edits a report with — so a care provider could start a review of their own report, resolve it, or share it with the family, which cannot be undone (INC-9). Reviewing, resolving, and sharing now sit behind a separate Review Incident Reports permission, held by Admin and Care Manager by default and not by Care Provider, and the dashboard shows those actions only to people who hold it. Sharing moves with review because it is decided in review, not by whoever filed the report. Every stored role that could manage incident reports keeps these actions except the Care Provider base role, so no agency's managers lose them. Setting significance still also requires managing care reviews. Adds INC-34. No rule IDs were renumbered.

2026-09-10

• The advance-directive alert is now something a care provider answers, not just something they see. The handbook has said since CL-23 and CL-24 that a client with a Do-Not-Resuscitate order or advance directive on file shows a non-dismissible alert, and that each care provider must acknowledge it before their first shift with that client. The alert was built. The acknowledgment was built behind it — recorded per provider per client, and correctly marked stale when the directive document is replaced. Nothing ever asked a care provider to give one, and nothing checked for one, so in practice the rule was a banner and no acknowledgments existed. The handbook recorded both rules as unbuilt, which was wrong in one direction and misleading in the other; this entry corrects the record and closes the gap.

  CL-24 now states what was previously an open decision: the acknowledgment is per client, not per shift, and is renewed when the directive document itself changes — a provider who read an older version has not read the current one. It also states who may give one: the care provider themselves, for a client they are actually assigned to. Acknowledging is an act of having read the directive, so the document is put in front of the provider before they can acknowledge it; recording that someone read something never shown to them would be recording a fact that is not true.

  CL-35 and SCH-69 are new and cover what happens at clock-in. Enforcement is an agency setting and it is off by default: the care provider clocks in and the shift is flagged for the care manager, exactly as an out-of-range clock-in is flagged (SCH-19), and an agency that wants the acknowledgment to be a hard requirement turns it on. Defaulting to on would have stopped shifts that are already staffed and under way, at agencies that had never been asked. One case can never block regardless of the setting: a client whose advance-directive indicator is set but whose document cannot be found in the vault. That combination is a data problem between the indicator and the vault, and it must not strand a care provider at a client's door with no way forward. Care managers get a per-client view of who has acknowledged and who has not.

  Both new rules and CL-24 ship built rather than specified: the care provider is prompted on the client hub and care plan, reads the directive on the document screen and confirms there, and acknowledge() now refuses anyone without an active care-team assignment on that client — it was previously open to any user holding shift-execute permission. The endpoint that reports whether a caregiver still owes an acknowledgment, which had no permission check at all, has one. CL-23 is recorded as built. The third Decisions needed question on Clients — what exactly must be acknowledged and how "first shift" is determined — is answered by the above and removed. No rule IDs were renumbered or retired.

2026-09-04

• The product no longer carries the founding agency's branding. Anaya Care began as a single-tenant product for one agency, and that agency's identity was still reaching every other tenant. A doctor's-appointment PDF carried its logo, email address and phone number whatever business produced it — the one care document that never moved to the Word pipeline, and the last gap in RPT-26, now closed by resolving branding from the producing business with the Anaya Care identity as the fallback. The guided intake told the AI it was working for that agency by name, and asked every family "what's brought you to" it; both now carry the tenant's own name, resolved when the run starts. Anaya's shared voice told care providers to "notify your GCS supervisor", and the referral wording every agency's generated documentation is built on said that agency would follow up with the client's doctor. A tenant whose knowledge base was empty had that agency's values and service pillars fed into their job postings; the fallback is now generic home-care values naming no one.

  Terminology follows. The assessment model is the Capacity / Support now / Risk model and intake runs on the fixed standard form — the same instrument, without the agency's initials in its name (AS-26, AS-28, AMODE-7, CA-8 wording only; no rule IDs added, renumbered or retired). The reminder-only scope (MED-23) no longer names one agency as its example. The agency's own knowledge-base documents were rebranded to its current name, Live and Stay — they still carried the name it traded under before the rename, which its own care providers would have read.

  Two things were found on the way and fixed rather than left. Migrations 027 and 107 looked their target business up by the old name and aborted outright when it was missing, which it has been since the rename; they now match on the slug and assert the current name, as 133 already did, and 001 creates the business under the name the other three expect. And the system account seeded for platform notifications had a known, repository-visible password while being treated as owner-equivalent in permission checks; nothing ever authenticates as it, so it now gets a random secret. The hardcoded-watermark route, which stamped the old agency's name on any image and had no caller, was removed instead of rebranded (OPS-7 amended).

2026-08-30

• The Refine panel now sits beside the document instead of on top of it, and looks the same on all four. Asking Anaya to change a draft was one feature wearing four faces. Where the document was a page (care proposal, care plan) the conversation slid in over the right of it; where the document was a pop-up window (a meal, an AI job posting) it had nowhere to go but on top, so a meal ended up with two windows stacked on each other, and a job posting had the conversation crammed into a second column that vanished behind a pair of tabs on a laptop screen. The button that opened it was in a different place on every one — in the toolbar on a care plan, buried a third of the way down the form on a care proposal, floating mid-page on a meal, and entirely absent on a job posting.

  It is now one panel, opened from Refine with Anaya in the document's own row of actions, on all four. On a wide screen it takes a column down the right and the document makes room for it, so the section being discussed stays readable while it changes — which is what AI-34 promised and what the handbook has said all along. On a narrower screen it slides in over the side, because there is no room for two columns. A meal and an AI job-posting draft each get a page of their own so they can be treated the same as the other two; the older link to a job-posting draft still works. An unsent request is kept if the panel is closed, or if the reviewer navigates away and comes back — it used to be discarded. No rule IDs were added, changed or retired: this is how an existing rule is met, not a change to what it requires.

• A generated meal can now be changed by asking. Refinement (AI-34) reaches a fourth artifact. A care manager opens a meal Anaya wrote and types what they want different — "make this softer to chew", "swap the rice for mashed potato" — and that one meal is revised as it currently stands, hand edits included. MEAL-15 is new and says what the boundaries are: one meal, never a second; never more than the request reaches; and a meal a person wrote by hand cannot be refined at all, because there is no generated draft behind it to revise.

  Two things are protected explicitly because the obvious implementation loses them. Meals are saved by INSERT, so reusing the normal save on a refinement would have doubled the client's meal bank on every message rather than revising it; a refinement writes back to the same meal instead. And the parts of a meal that a person adds after generation — substitutions recorded against an ingredient — are not part of what Anaya writes, so a plain re-write would have quietly erased them every time. They are carried across now, matched by ingredient name, and so is the meal's picture, which is never redrawn by a refinement. No rule IDs were renumbered or retired.

• A refinement now reports what it actually changed, and can no longer be talked into rewriting what nobody asked about. The "what changed" note on a refinement was the AI's own account of its work: the list came from which emit tools it called, so a section rewritten word-for-word identically was still reported as changed, a section altered in passing was not reported at all, and a job posting reported nothing whatsoever because it is written in one piece. AI-37 is amended: what a refinement reports as changed must be what actually changed, established by comparing the document before and after. Where the AI's account and the comparison disagree, staff are shown what moved without being mentioned — which is the case that matters, because AI-35 exists to stop a refinement reaching further than it was asked to and nothing until now could tell whether it had.

  The second half is the reason that check was overdue. On a care proposal the AI was still being told to run its own quality review during a refinement, and that review grades the saved proposal — the one a care manager has already read and edited — not the work of the current request. So a proposal whose cover letter a person had shortened, or signed off by hand, or which repeated a line across two care areas, could be flagged and rewritten by a request that never mentioned it. In the worst case it reversed the instruction outright: asked to shorten the cover letter, the AI would comply, its own review would object that the letter was now too short, and it would pad it back. The review no longer runs on a refinement, and the refinement instructions now say so — the care-plan instructions already carried that supersession, and the care-proposal ones did not, which is why only proposals were exposed. No rule IDs were added, renumbered or retired.

• Refining a draft is now written down where the drafts are — and a cancelled request no longer reads as one still running. Asking Anaya to change a finished draft in plain words shipped on 2026-08-26 with rules AI-34 – AI-38, but it was described only on AI Features: the three pages that own the documents it acts on — Care Proposals, Care Plans & the Care Task List and Job Postings — never mentioned it, the changelog had no entry for it at all, and the glossary defined neither Refine nor Refinement thread. Anyone reading a document's own page had no way to learn the feature existed. Each of those pages now describes it in its own terms, including the two things that differ by document: refining a care plan does not publish a new version, and refining a job posting acts on the draft as it is on screen, hand-edits included. The glossary gains Refine, Refinement thread, Generation dock and Generation run, and Refine says plainly what it is not — the refinement passes inside Thorough mode are an automated quality review during a first generation and involve no person, which is a different thing wearing the same word.

  One correctness fix comes with it, against AI-37. Cancelling a job-posting refinement left its request sitting in the thread as though it were still being worked on: the cancel path for that one document did not settle its request, and because a cancel escalates to a kill when the graceful stop does not take, the workflow's own tidy-up never ran either. A request that changed nothing therefore read exactly like one still in progress, indefinitely. Care plans and care proposals were unaffected. The gap existed because "which documents can be refined" was implied in three separate places with nothing tying them together, so there was no list to check the third against; there is one now, and it is enforced.

  A clarification, not a change, on AI-2: business AI defaults still only pre-fill the web request form, and the Known gap recording that is unchanged and still open. It now also states that refinement requests inherit it — they always run in Standard, because there is no request form to pre-fill. Whether those defaults should be binding everywhere remains an open decision on that page; refinement should not answer it on its own. No rule IDs were added, renumbered or retired.

2026-08-29

• Anaya Care records health readings; it does not monitor them. A government body warned the company that it is not permitted to monitor clients' vital signs. The activity itself is lawful and unchanged — a family member or representative asks the agency to write a reading down, and a care provider records the number during a shift and reports anything unusual, without interpreting it or acting on it. What was wrong was the wording and, more seriously, the attribution: every surface named the care manager as the person who decided what got checked, which describes exactly the surveillance the company may not perform.

  The Health Monitoring page is now Health Readings — same HEALTH prefix, no rule renumbered, all cross-links repointed. HEALTH-47 is rewritten so the requester is the family or representative and the care manager merely records that request by marking a reading Check on shifts; the old Monitored toggle is renamed to match the label the web UI already used. HEALTH-1, HEALTH-2, HEALTH-3 and HEALTH-34 drop "tracks" and "monitoring", and the key terms become Health readings, Out-of-range reading, and Per-client alert numbers. Care Plans & the Care Task List rewrites PLAN-46, PLAN-47 and PLAN-48 onto the same footing, and the plan's section becomes Health Readings. AI Features amends AI-32: no AI surface may describe the agency as monitoring, tracking, or watching a client's health, and that is now enforced at runtime rather than asked for in the prompt — the care-plan and care-provider-tasks agents hand text back to the model when the vocabulary appears — in their clarifying questions and, unlike the plain-words check, in the drafted Health Readings section itself, because that section is the text a regulator would actually read (PERSONA-12). The check is deliberately scoped to those two surfaces so the reassessment outcome named MONITOR and the blood pressure monitor (the device) keep working.

  The reword reaches further than the screens. Task-template labels — "Blood Pressure Monitoring" and its siblings — are the single source for the mobile task list, the web baseline cards, the AI consent row, the abnormal-reading push and email, and the report tables, so they are renamed to "… Reading" and migrated in the database rather than only in the seed file. Two documents that leave the building are corrected: the care summary's welfare statement no longer certifies "based on regular monitoring", and the scope disclaimer now states plainly that Anaya Care is non-medical, records readings on request, and does not assess or interpret them. The App Store listing loses "vitals tracking". Synonyms were treated as in scope: "track", "watch" and "screen for" describe the same activity and were not substituted in. No rule IDs were renumbered or retired.

2026-08-27

• A generated worksheet can now be changed, not just accepted or rejected — and the run no longer draws anything. A finished run handed over a sheet nobody could edit. The only thing a care manager could change was how it looked — fonts, colours, margins — while every word on it was frozen at whatever Anaya wrote (ENG-2). An awkward clue, a title that missed, an answer word wrong for this particular elder: the only fix was to throw the sheet away and generate another one. That is at odds with AI-8, which says AI output is a draft for a person to review — reviewing had come to mean approving or rejecting, never correcting.

  There is now a Finalizing stage between the run and approval (ENG-22). A generated activity lands there, and while it is finalizing it is not shown to anyone who approves and is not counted as waiting for them — a half-made sheet no longer sits in a representative's list looking ready. In that stage a care manager edits the sheet's words as well as its appearance (ENG-23): its title, and for a crossword its clues and its answers, with the grid re-laid whenever an answer changes so the puzzle always matches its own answer key. Two things stay fixed on purpose, and the rule says which and why: a newspaper-style crossword's answers, because its grid is a fixed pattern and refilling one is a generation run rather than an edit; and where a counting sheet's pictures fall, which is already its own step (ENG-20). When the care manager is done they send it for approval, which is refused while any picture is still outstanding (ENG-21).

  Two smaller corrections come with it. A counting sheet's grid was asked for in the generate dialog, before anyone knew how many pictures there would be or what they looked like — every one of its neighbours is decided after the run, and now the grid is too (ENG-3, ENG-18 amended). In its place the dialog asks the one thing that genuinely has to be decided up front, because it changes how every picture is drawn: what the pictures should look like — clip art, a photograph, watercolour, a vintage illustration, or something minimal. And the page's background picture, the one picture nobody ever asked for, was the only one still drawn automatically inside the run. Now nothing is drawn during generation at all (ENG-24): the run writes a description of every picture and stops, and each is drawn afterwards on request, from wording a care manager may change first. A generation run can therefore no longer fail because a picture failed. The accepted cost is recorded as a Known gap: a sheet of any type now prints without a background until someone asks for one. ENG-22 through ENG-24 are new; ENG-2, ENG-3 and ENG-18 were amended; no rule IDs were renumbered or retired.

• Asking for an activity now asks about that activity — and picture sheets are drawn after the sheet is written, not before. Step two of the generate dialog asked the same four things of all twenty-three activity types: a topic, an extra instruction, and the AI settings (ENG-3). So a crossword and a counting sheet were ordered identically, and the things that actually decide what the sheet looks like were unreachable — a care manager could not say whether they wanted a roomy classic crossword or a dense newspaper-style grid, could not choose that grid, could not say how many clues to write, and could not set how many pictures a counting sheet should hold. The engine understood every one of those; only the form did not ask. ENG-3 is amended: a request now carries the settings the chosen type needs.

  The second half is about pictures. A counting sheet was generated by making its pictures first — a main picture and several variations, each described from scratch and drawn independently — and only then saving anything. Two things went wrong with that. One failed picture threw away the whole run, including the writing that had succeeded; and because each variation was described on its own rather than drawn from the first, the set drifted in style, which is fatal for a sheet whose whole question is how many of these are the same. Now the run writes the activity and a plain description of every picture it needs, and saves it (ENG-18). The pictures are made afterwards, on request, one at a time, and a care manager may reword any description first or ask for a single picture again without regenerating the activity. Variations are made from the first picture rather than described independently, so only the thing being counted differs (ENG-19). A sheet arrives with three of them — the activity engine's own default, rather than the maximum of five it used to be given because the cognitive-level item count was being forwarded into a setting that does not mean the same thing there — and any one of them can be dropped without rewriting the rest (ENG-18). How many variations there are, and how many squares each fills, are the care manager's to set — they are what make a sheet easy or hard, and the second is the puzzle's own answer. Arranging the pictures across the sheet is then its own step (ENG-20), so the layout stops being re-dealt behind the care manager every time they redraw one picture, and can be run again for a different arrangement. Because that means a sheet can now exist with its pictures still missing, or with every picture made and nothing arranged, ENG-21 says what must not happen: it cannot be approved or printed, and the product names the pictures still outstanding rather than offering a blank sheet — AI-8 and AI-9 applied to pictures. This lands for crosswords and counting sheets only; the other picture-based types still make their pictures inside the run, and the Known gap recording that this page still describes the pre-worksheet model is unchanged and still open. ENG-18 through ENG-21 are new; no rule IDs were renumbered or retired.

• Asking the AI for an activity now makes one activity of one type. A care manager could tick several activity types and set a number of copies of each, so one request could ask for twenty worksheets across a dozen types (ENG-3). Nothing in the system actually distributed that work: there is one generation run and no loop over the chosen types, so the split existed only as a sentence in the instructions handed to the model — and when the model under-delivered, the run finished looking exactly like a complete one. A request that cannot be checked is not a promise the product should make. Generation now takes exactly one activity type and produces one activity (ENG-3 amended); making several means running it several times, choosing a type each time. Nothing else about generation changes — the topic, difficulty and item count are as they were, the activity-fit verdicts still group the choices and still dim rather than remove a poor fit (ENG-12, AI-8), and every generated activity is still a draft awaiting approval (ENG-2). The Known gap recording that this page still describes the pre-worksheet model is unchanged and still open. No rule IDs were added, renumbered or retired.

2026-08-26

• A care provider can now be offered a choice of activities — and choose freely when nothing was planned. An engagement task in a shift held exactly one activity, picked weeks earlier by a care manager (ENG-4). That is the right shape for a meal, which is shopped for and prepped in advance, and the wrong shape for an activity, which depends on how the client is that morning — a holiday, a visitor, a low-energy day, and the plan is already wrong with no way to say so. An engagement task now holds a shortlist rather than a single activity (ENG-4 amended), and its size is what it means: one activity is a fixed instruction, two or more is an offer, and no shortlist at all leaves the choice open (ENG-7). Where a task carries no shortlist the care provider picks from everything approved for that client (ENG-8); where one exists they may run one or more of it — a shortlist is an offer, never a checklist, because activities that must all happen belong on separate tasks. What the care provider chose is the record: stored in the order chosen, with who chose it and when, and it is what the client calendar, the family view and shift reports show (ENG-9), rather than the plan nobody followed. The boundary is kept — only activities approved for that client, and only from the shortlist where there is one (ENG-10) — and a new Decisions needed entry records what that costs: a client who asks for something else on the day cannot have it recorded against the task. Bulk scheduling now offers a set on each task instead of picking one for it (ENG-11). This is a deliberate divergence from its sibling and not a drift: Meals MEAL-7 is unchanged, and a meal-preparation task still holds exactly one meal. Two Known gaps are recorded rather than closed — this page still describes the pre-worksheet model, so ENG-3 is already untrue of the system and the page needs a rewrite; and the care manager has no screen for placing activities on shift tasks at all, which is why the engagement assignments step of a client's care-operations checklist cannot be completed. No rule IDs were renumbered, and no retired IDs were reused.

2026-08-25

• "Owners have no profile setup" was read as "Owners see no setup screens", because three different steps shared one word. Identity, Access & the Business said plainly that Owners, Admins, and custom-role staff have no profile setup — and that is true and correctly built. What it never said is that there is a second, earlier step every account passes through whatever its role: confirm your name, choose a profile photo, once, after verification and before the dashboard. So an Owner meeting that screen looked like a contradiction of the handbook when it was a hole in it. The page now names the three separately — the business onboarding survey an Owner answers about the agency (ACCESS-12), the personal onboarding everyone does about themselves, and the role-specific profile setup only Care Providers and Medical Professionals have (ACCESS-18) — with a new section describing the middle one, all three added to Key terms, and the Owners bullet extended to say what having no profile setup does not mean. New ACCESS-38 records the step and its ordering. Nothing about the product changes: the system already restricted profile setup to the two roles the handbook names. No rule IDs were renumbered, and no retired IDs were reused.
• Adding documents to the knowledge base is now a drop, not a form — and Anaya files each one for you to check. Uploading was capped at one file at a time, so an agency putting its policy binder in reopened the same nine-field dialog once per document. Only one of those fields was ever required — the file — and the rest carried defaults, which is what made the ceremony so costly: the fastest path was to accept every default, and one of those defaults was category, the field that decides whether a document is ever drawn on when the AI writes. A policy left in General was filed, searchable, and silently absent from every draft that should have quoted it. Now the agency drops a stack of files onto the page at once. Each one uploads, Anaya reads it, and it comes back as a card already filled in with a title, a category, tags, and a one-line description, marked as its suggestion until someone changes it. A person edits what is wrong and confirms — per card or for the whole batch — and nothing joins the library unconfirmed (KB-9). What Anaya proposes is deliberately bounded to those four fields: it never guesses who a document is for, how sensitive it is, or which client it belongs to, so no part of this reads names to make an association. New KB-10 closes a failure that used to be invisible: a scanned or image-only document has no words to read, and until now it was accepted cheerfully and then reported as Indexed — because the page markers the reader emits ("page 1 of 12") are themselves text, so the document was filed as searchable while containing nothing anyone could search for. It is now said plainly at the moment of saving — the document is still added and still downloadable, it simply will not be found by AI search until a readable copy replaces it. No rule IDs were renumbered, and no retired IDs were reused.

2026-08-24

• AI job-posting drafts are now short and grounded on the agency knowledge base. The draft the care manager reviews is no longer a three-paragraph sales essay with generic "meaningful work" benefits. It is one short overview, 5–8 care-need responsibilities from the care plan and functional assessment, the schedule, a few ideal-candidate bullets, and a What We Offer list taken from the agency knowledge base — core values and caregiver offer, not invented filler. Job Postings records that generation in the posting lifecycle. No rule IDs were added, renumbered, or retired.

2026-08-21

• A posting for a client now starts from that client's own care schedule. When postings stopped advertising bundles of individual shifts and started advertising a weekly schedule (2026-08-20), the schedule became required — and the one thing that used to fill it in went away with the bundle. Staff opening the create form for a client who already had a full care schedule on file were met with an empty editor, a red "add at least one day and time", and the job of retyping days and hours the system already knew. Worse, the timezone those hours would be read in defaulted to the browser's, so a posting written in Manila for a client in New York was eight hours out before anyone typed a thing. Now the form reads the client's care schedules — expanding their repeat rules over the coming weeks, splitting an overnight stretch into the two day-boundary windows a care provider would have to declare to cover it, and joining hours that genuinely overlap while leaving a day/night split as the two separate shifts it is — and fills the Schedule card in on the client's own clock. JOB-28 is amended to require the offer and to say what it is not: staff may change every part of it, and a posting keeps the schedule it was saved with even if the client's schedule changes later. A client with no schedule yet gets the empty editor and a line saying so, rather than silence. No rule IDs were added, renumbered, or retired.
• A care provider can now say they could not do a task — and "was this done?" stops being a question buried in every form. The product had no way to record that a task did not happen. What it had instead was a field called Task Completed — Yes / No / Partial / Refused — written into 32 of the 53 task templates, asked at the end of a form the care provider could only reach by starting the task in the first place. It was worse than redundant: because it lived inside the template's own answers, nothing could count it, and nothing did. A submission answering "Refused" discharged the shift's required-task check exactly as "Yes" did, so a shift where nothing was done could still report its tasks complete. Fourteen templates asked nothing at all, so a care provider who could not serve breakfast had nowhere to say so. Now the completion state belongs to the submission, recorded the same way for every task whatever its template, and there are two states rather than three: Completed or Skipped (PLAN-28 rewritten — Partially Completed is dropped, because in practice it meant something different on every task and told a care manager nothing they could act on). Skipping is offered in the same place the care provider starts the task, and again after starting, for the task that turns out to be impossible once you are in the room. It asks for a reason from a fixed platform list — client refused, client unavailable, client unwell, supplies unavailable, not enough time, safety concern, other — and a note, and asks for nothing else: no form, no readings, and no ticking through the preparation steps, because making someone complete a briefing in order to record that the client refused is the same bug in a different place (PLAN-29 rewritten; the reason list is fixed rather than agency-configurable, so skips can be compared across agencies and, later, watched for patterns). Both the reason and the note are enforced by the server, not only by the app. A skipped task counts as accounted for — the care provider has answered for it, so it does not hold up clock-out — but it is never counted as done. PLAN-32 narrows to what now exists: skipped tasks are flagged on the shift detail view alongside the shift's other exceptions, while the recurring-skip pattern alert remains unbuilt and is recorded as a Known gap. PLAN-33 is rewritten: it used to measure the task library against a Task Templates Reference companion document of 59 templates, which does not exist and never has — the library itself is the definition, and no template may carry a field that restates the submission's own completion state. Two open items are recorded rather than settled: health-monitoring tasks still record "the reading did not happen" inside the form (PLAN-46), which now overlaps the Skipped state and may or may not want unifying; and four templates overlap subsystems that have since grown their own flows — Grocery Shopping against Essential Needs, Transportation & Appointments against the appointment task the calendar already generates, Fall / Incident Report against the Incident Reports module, and Hair Care, Shaving & Grooming and Nail Care against each other. No rule IDs were renumbered, and no retired IDs were reused.

2026-08-20

• A job posting now advertises a schedule, not a list of shifts — and a shift a care manager assigns is simply the care provider's to work. Four things were tangled together. An agency posting a job had to tick off individual generated shifts one by one, because a posting could be either a weekly pattern or a coverage bundle of concrete shifts, and the bundle was the path the product actually led staff down. A care provider applying then had to pick which of those shifts they could cover — asking them to re-state, per posting, what their declared availability already said. Accepting them created exclusive staged coverage that a separate commit step later turned into real assignments. And every assigned shift then waited on the provider to accept or decline it. Now there is one kind of posting and it states a weekly schedule (JOB-1, JOB-3 and JOB-28 amended — the schedule is required; JOB-4 retired). A provider applies with a cover message and nothing else: the hours they can work come from the availability on their own record, read against the posting and shown as a fit — full, partial, or none, naming the days that do not line up — which is advice and never a gate (JOB-10 and MAP-10 rewritten; MAP-9 amended). Only a blank availability profile blocks applying. Acceptance shrinks to what it always claimed to be: onboard the provider to the agency, add them to the client's care team, stop (JOB-20, JOB-22, JOB-23, JOB-24, JOB-31, JOB-33, JOB-36, JOB-37 amended; JOB-29, JOB-30, JOB-32, JOB-34 and JOB-35 retired). Because a hire that never becomes work is the way this can now fail quietly, new JOB-44 requires the product to say at the moment of acceptance that shifts still need assigning, offer a direct path to it, and treat a client with an accepted applicant and unassigned shifts as an open item. On the scheduling side, assigning a shift commits it (SCH-9 rewritten) — there is no acceptance step, no response deadline, and no decline. A provider who cannot work a shift marks it not available, which returns it to the open pool and tells the care team it needs coverage (SCH-10 rewritten; the term is added to Scheduling & Shifts and the glossary, and coverage reservation, coverage bundle, approved shifts and staged coverage are removed from both). Reassignment commits the same way (SCH-11), the checks that used to count reservations now count the shifts a provider already holds (SCH-13, SCH-14, MAP-8), and the live re-check at assignment (SCH-54) is strengthened: it is now the only thing standing between an assignment and an impossible one, so it must run on every path. SCH-16, SCH-53 and SCH-66 are retired, along with the coverage-reservation machinery behind them (SCH-56, SCH-57, SCH-60 and MAP-20 amended). Two notes on what this reverses and what it fixes. SCH-66 — answering many awaiting shifts at once — shipped on 2026-08-15, five days ago; it is retired here not because it worked badly but because assignment no longer produces a shift that awaits an answer, so there is nothing left to answer in bulk. And the Known gap recorded under SCH-17 — that the product let a care provider clock in to a shift they had not accepted, with two parts of the system disagreeing about whether that was allowed — is closed by construction rather than fixed: with no acceptance step, the disagreement has no subject. SCH-17 is rewritten to say only that the assigned care provider may clock in. A new Decisions needed entry on Job Postings records the cost of this simplification: a weekly pattern states weekdays and hours, never calendar dates, and it is now the only kind of posting there is — so a fixed-length engagement has nowhere to state its end date. No rule IDs were renumbered, and no retired IDs were reused.
• Each vital now has its own "Monitored" toggle, and the care plan finally knows about the mobile task list. Two changes land together. First, a care manager setting alert numbers on a client's Health Baselines could not say which vitals should actually be checked on shifts — any configured number pulled every vital into the care plan. Now each vital carries a Monitored toggle (Health Readings adds HEALTH-47): only monitored vitals appear in the plan's Health Monitoring section and get check tasks on the Care Task List, while alert numbers keep checking any reading that is recorded either way. Saving numbers through the AI's gentle reminder also marks that vital monitored — the care manager's own action, said plainly on the consent row (AI-32 amended). Care Plans & the Care Task List amends PLAN-47 (monitored, not merely configured) and adds PLAN-48: the toggle is followed end to end — a check task for an unmonitored vital is sent back to the AI and stripped if it survives, and a monitored vital with no check task anywhere is flagged for review. Second, the AI that writes the care plan had no idea its plan is executed as per-shift checklists on a care provider's phone — it wrote for a reader, not an executor. PLAN-49: the plan author now knows the pipeline (plan → Care Task List → Anaya mobile app), reads the same task-template library the task generator must draw from, writes domain instructions as concrete doable actions that map to it, and never writes shift instructions the library cannot carry (PLAN-45) — those needs are raised to the care manager instead. No rule IDs were renumbered.
• A care-plan question about an assessment row now arrives as the form's own answer control. When care-plan generation asks about a blank or conflicting care assessment row — an SRTI capacity or support level, an ACL mode, a meal texture — the question now carries the pointer to that exact field, so the reviewer answers in the same select the assessment form uses and can tick "also save this" to fill the row (AI-25, AI-31). Before, the agent had no way to learn a field's exact path, so these questions arrived as free-text chips with no save-back. The agent gained the same read-the-assessment grounding tool the reassessment agent already had, and a question whose record pointer is wrong or missing its field is now sent back to the AI to fix rather than silently shipped without its input control. No rule IDs were added or renumbered.
• Anaya stops asking about vital signs, and starts speaking plainly everywhere. Two things were wrong on staging. First, when a client had no vital-sign thresholds set, the AI would flag it, ask whether there was a doctor's order, and offer an "Anaya suggests" vitals form to fill in — on a platform run by a non-medical home-care company, where those numbers are a care manager's to enter from the client's healthcare-provider direction, not the AI's to guess at. AI Features adds AI-32: the AI never proposes or suggests a vital-sign reading, alert threshold, or monitoring baseline on any surface — no pre-filled values, no "Anaya suggests" preset — and where a client has none it may only remind the care manager once, gently and helpfully — "if there is a doctor's order with numbers to watch, you can check it and add them here" (the vitals form stays, empty, and can be skipped); it never asks why a baseline is missing or whether they are sure, and where a client has no baselines its drafts say nothing about vitals. The Correctable field term now says baselines are correctable only by the care manager's own hand. Care Plans & the Care Task List adds PLAN-47: the plan's Health Monitoring section carries vital-sign content only for the vitals a care manager has configured on the client's Health Baselines, with the thresholds as configured, and otherwise carries none — while still covering non-vital observation and when to report a change. Health Readings HEALTH-34 is amended with the same clause: thresholds are entered by people only, never proposed by the AI. Second, AI output read like a chart note — "cognitive impairment", "depression", "clinical planner" — because the shared non-clinical foundation was loaded by chat alone. Anaya — the AI Persona adds the key term Plain words and two rules: PERSONA-11, every AI-authored text — drafts, summaries for any reader including medical professionals (who still get the exact readings, in plain words), clarifying questions, every answer choice or chip, suggestions and their reasons, notes and labels — reads at about a 12-year-old's level with no clinical or diagnostic labels, saying what the person does or what was seen instead, with a common condition name already on the record allowed once and then explained; and PERSONA-12, this is enforced, not trusted — a clinical term in a short person-facing string is rejected by a deterministic check and sent back to the model to rephrase before anyone sees it, and long narratives are checked and logged. AI-33 binds every generation, summary, and helper on the AI Features page to those two rules, medical audiences not exempt. Because the shared character is now loaded first by every Anaya prompt, PERSONA-1, PERSONA-2, and PERSONA-10 move to In code and the persona page's first Known gap is rewritten; a new gap records that the check is a conservative term list, not a readability score. Anaya Healing Ally HEAL-5 and Reassessment RAC-16 are clarified (plain-language description per PERSONA-11; rationale rejected and rephrased per PERSONA-12), and one sentence each on Care Coordination, Report Generation, AI Chat Assistant, and Assessment Mode says the same of their surfaces. No rule IDs were renumbered.

2026-08-19

• An agency's own rules now reach the AI every time, instead of only when a search happened to surface them. Until now the only way to tell Anaya how this agency works was to upload a document into the Knowledge Base — where it is chunked, embedded, and retrieved by similarity, so a policy reached the model only if the question resembled it. That is right for reference material and wrong for policy: a rule that is silently skipped is worse than no rule. A new page, Agency Memory (new prefix AGM, rules AGM-1 – AGM-10), defines the agency's standing operating rules — escalation, methodology, house style, staffing, compliance — as a structured rule set that is given to the AI word-for-word on every matching request, never searched and never ranked (AGM-2). Each rule declares which AI surfaces it governs (AGM-3), can be deactivated without being deleted (AGM-4), and is ordered, with that order deciding precedence (AGM-10). Rules are authoritative over the AI's defaults but never over its safety, escalation, and scope-of-practice rules, and anything inside a rule that tries to change who the AI is must be ignored (AGM-5). Configuring them is Owner and Admin only (AGM-6), but the rules bind the AI output of every member of the business (AGM-7) — a care provider asking about a fall must get their agency's escalation rule even though they cannot edit it. Because rule text therefore reaches staff indirectly, agency memory must not hold confidential client information and the authoring screen has to say so (AGM-8). A prompt budget bounds how much can be injected, dropping the lowest-precedence rules first and telling the AI its view is partial (AGM-9).

• This closes the open "where do methodology rules live?" decision. Knowledge Base KB-7 asked whether an agency's care methodology rules should be a structured rule set or an uploaded document, and how the generation engine should read them. The answer is a structured rule set in Agency Memory. KB-7 is rewritten to point there and is no longer Spec only; the Knowledge Base "Decisions needed" entry is resolved and its Known gaps updated. AI-Generated Task Instruction Steps STEP-2 is repointed the same way and moves from Spec only to Partial, and its Known gap — "methodology-rule configuration is itself unbuilt, so STEP-2 has no upstream source" — is replaced by the narrower question of how far those rules actually shape step structure. The Knowledge Base role table drops the "Care manager has view-only" clause on methodology configuration, which contradicted the Owner/Admin row already on the Task Instruction Steps page. Agency memory applies to Anaya chat, care task and instruction-step generation, and engagement activities; the platform's other AI generators do not read it yet (Known gaps). No rule IDs were renumbered, and no retired IDs were reused.

2026-08-18

• Wound assessments are now photo-first, and the AI reads every photo automatically. Capture used to be backwards: the care provider typed length, width, and depth into three bare boxes, wrote the clinical notes from scratch, and then decided with a switch whether the AI got to look at the photo at all — after which its findings landed in a read-only panel nobody could correct. Now the photograph is the first and only thing asked for; it opens a draft assessment and the durable analysis starts by itself. The switch is gone, not defaulted on. When the reading lands it fills the assessment in — measurements, clinical narrative, wound bed, drainage, edges, surrounding skin — as editable drafts marked as drafted until a person changes them. The provider corrects what is wrong, records the pain level (which the AI never drafts, because it is what the client reports rather than what the camera sees), and confirms; only then does the entry join the wound's history, move the trajectory, notify management, or feed the client's memory. This also closes the long-standing question of how Anaya Healing Ally relates to the wound assessment in Health Readings: Healing Ally is the capture experience for that same assessment — one history per wound, not two. Health Monitoring rewrites HEALTH-12, HEALTH-14, HEALTH-15, and HEALTH-16, and adds HEALTH-44 – HEALTH-46. Healing Ally moves HEAL-1 – HEAL-7 and HEAL-12 to In code, rewrites HEAL-3, HEAL-5, HEAL-6, and HEAL-7, and adds HEAL-13 – HEAL-15. No existing rule IDs were renumbered.

• A home-inventory item marked "doesn't look right" now reaches the care team, and the reason goes with it. The representative could already say what was wrong, but nobody was told and the note was stored where no screen read it — staff saw a red badge and had to guess. Home Inventory adds INV-14: the flag notifies the client's care team immediately and the reason stays on the item, in the dashboard and in the app, until it is agreed again. Also adds INV-13: office staff may record an agreement for a representative reached by phone, email, or in person, but only with an account of how they were reached, and the history shows those apart from the representative's own tap — the same posture NEED-20 takes on funding answers. The role table splits agreeing from recording on behalf. No existing rule IDs were renumbered.

• The care provider who attended a doctor's appointment now submits the visit notes; a care manager reviews and approves. Completing used to be a manager-only one-step write. The person at the visit records diagnosis, prescriptions, notes, and documents; that submission stays pending review until a care manager checks it, edits anything that is wrong, and marks the appointment completed. There is no send-back. Managers can still complete a scheduled appointment in one step when nobody submitted. Newly prescribed medications join the client's list only on approve, not on submit (HEALTH-29). Pending appointments are not upcoming (HEALTH-28). Assigned care managers are notified of a submission; family is not (HEALTH-43). The unused Next Appointment Date field is gone from complete — a follow-up is a new doctor's appointment. Health Readings adds HEALTH-42 and HEALTH-43, and rewrites HEALTH-27. Identity records appointments:submit as a live workflow verb. No existing rule IDs were renumbered.

• Recurring is gone from essential needs. The toggle and interval were stored and shown, but nothing ever used them: calendar restocking onto a suggested-buy list (NEED-4) was never built, and suggested-buy already comes from on-hand versus par (NEED-6, NEED-7). Essential Needs supersedes NEED-4; the fields are dropped from the schema and $unset from stored items so a document looks as if they were never there. No existing rule IDs were renumbered.

• The representative now agrees each home-inventory item as it is shown — photograph and labels together — and that first agreement makes the item undeletable. The old grouped inventory document is gone, so INV-6 is no longer a batch signing ceremony: one tap accepts the live photo, name, category, condition, and any filled-in details. Each agree stores a full copy of that record (not a diff); staff may still edit afterwards, which returns the item to pending and keeps every previous copy as visible history until the representative agrees again (INV-12). INV-3 now forbids delete after the first agreement. A witness is not required. The “how do representatives sign a flat item list?” decision is closed. Home Inventory. No existing rule IDs were renumbered.

• The person who raised an essential-needs request can now edit or disregard it while the agency has not answered. A submitted request used to sit in the review queue with no way back: a wrong quantity or a change of mind meant waiting for a decline. Essential Needs adds NEED-30: editing pulls the request back to Draft so the bundle can be changed and sent again; disregarding deletes it and releases the items. Once a fund request has gone to the family, neither action is allowed. No existing rule IDs were renumbered.

• Home inventory is now one photographed item at a time, not a batched version. There is no grouped inventory document: each item is its own record, added by photographing it, confirming a drafted name and category, and choosing a condition (INV-1, INV-2, INV-8 – INV-11). Mobile is camera-only; the web dashboard may upload a file (INV-9). The stored photograph is the original capture, never an AI cutout (INV-10). The product may draft name and category and must never fill condition (INV-11). INV-4 (at most one draft version) and INV-5 (only drafts can be deleted) are retired; INV-3 now covers edit and delete of an item; INV-6 signing is kept as a requirement whose ceremony is undecided now that there is no version to sign. Home Inventory. No retired IDs were reused.

• External job-share email now skips every existing Anaya account. Invite by email is only for people who are not on the platform. Pasting an address that already belongs to a user — care provider or otherwise — no longer emails them or pings them in the app; the dialog marks those addresses already on Anaya before send. Existing providers still see published jobs in the app, and the publish-time agency alert is unchanged (JOB-38). Job Postings & Applications rewrites JOB-40 and extends JOB-43. No rule IDs were renumbered.

• Job-share invites now keep a delivery log. Pasting the same address onto a posting a second time is skipped, and each sent invite shows whether Resend delivered, bounced, or complained — the same webhook path user invites already used. Job Postings & Applications extends JOB-43. No rule IDs were renumbered.

• Every job posting now names a client. The agency-wide Job Postings list was a second place to create a posting with no client, so those jobs never appeared on Find Caregivers and inviting people outside Anaya had nowhere to live on the client. Job Postings & Applications rewrites JOB-1: a posting always belongs to one client; the global list is a view of those client postings; create and external email invite happen on Find Caregivers. "Generic" still means a pattern posting rather than a coverage bundle, not a posting with no client. No rule IDs were renumbered.

• Reassessment questions and suggestions now use the same typed controls as generation. A clarifying question during a reassessment can offer to save the answer onto the client record (AI-25), and the reviewer fills a date, number, measurement, yes/no, or vital the same way they do in the generation dock — the agent's suggested value is a one-click preset, not the answer itself. On the review, each suggested assessment change (RAC-16) is edited in that same typed control before it is accepted; what gets written is the value in the box, which may differ from what the agent proposed. When the field is an SRTI capacity/support/status row — or another assessment vocabulary such as ACL mode or meal IDDSI — the control is the same select the assessment form uses, not a free-text box. No rule IDs were renumbered.

• A published job can now be emailed to people who are not on Anaya Care, and they are asked to download the app before they can apply. Agencies already alert their own care providers when a posting goes live, but that reach stops at people who already have an account. Recruiting someone from outside the platform meant a separate user invite — which creates an account, requires a phone for care providers, and is not about a specific job — or asking them in some other channel and hoping they find the posting. Job Postings & Applications adds JOB-39 – JOB-43. Staff with job-posting management access paste addresses or upload a CSV onto a Published posting; Draft, Closed, and deleted postings cannot be shared this way, and the send is a separate action from the publish-time agency alert (JOB-38). Sharing never creates a user. Someone who is not on Anaya receives a job summary with no client identity — title, description, skills, pay, shift pattern, urgency, city and region, and the agency's name — plus a link that opens the app and store badges if they still need to install it. They download the app, sign up as a care provider, and apply like any other marketplace provider; acceptance still onboards an unaffiliated provider to the agency (JOB-21). Someone who already is a care provider and has not opted out is pointed at the posting in the app instead of being asked to download it again; someone who has opted out is skipped (JOB-9); an existing account that is not a care provider is not sent a job email. There is no web apply: the email and the public landing page exist only to get the recipient into the app. A send is validated, deduped, capped at 100 addresses, skips an address already emailed that posting, and records each outcome against it. No rule IDs were renumbered.

2026-08-16

• Answering the AI's question can now fix the record, not just the draft. A generation that noticed a gap — the health assessment lists hypertension, but nobody set a blood-pressure alert threshold — would ask the care manager, fold the answer into the care plan, and write nothing down. The plan came out right; the record stayed blank; the next generation found the same gap and asked again. The clarification was doing half its job, and the half it skipped was the half that would have stopped it repeating. AI Features adds AI-25 – AI-31. A clarifying question whose answer belongs on a record now carries a record correction: the same answer card, one extra checkbox, no separate queue — because the reviewer already holds the context at that moment, and a review item three days later costs them re-deriving all of it. Consent is required every time (AI-26); the AI proposes a field and a value and never writes on its own, which is LIFE-5 applied to data rather than to care documents. Only fields the platform has explicitly opened may be proposed (AI-27), and a proposal is refused whole rather than applied in part if it would leave a record the ordinary edit screen would reject. Three of the rules exist because the obvious version of this feature would have been quietly wrong. AI-28: a blank field is not the same as nothing happening — a client with no blood-pressure threshold is still alerted against a standard default — so the offer must show what is in force in the meantime, or it tells a scarier story than the truth. AI-29: filling a blank may be pre-selected, replacing a value a person typed never may; the first is additive and reversible, the second is overwriting someone's judgment, and a single default for both would have to be wrong in one direction. AI-31: a blank field on a care assessment is out of scope entirely — an unanswered assessment row is an incomplete assessment, and completing it is the assessor's job, not something to be inferred mid-care-plan. AI-30 settles the question the feature could not avoid: a correction to an assessment carries the same consequences as one applied during a reassessment review, including the version cut (CA-16) and the downstream regeneration flag (RAC-13 → STEP-17), because a corrected functional score invalidates the instructions derived from it no matter which screen approved it. One write path, one ceremony, provenance recorded separately. Built for care plan generation today; the other generations still ask without offering, which is why AI-25 is ✅ with that scope named. No rule IDs were renumbered.

2026-08-15

• An unanswered fund request now has a deadline the family can see, and care cannot end with money unexplained. The last two unbuilt rules on Anaya Wallet are built, and both were leaving money in an undefined state. WALLET-8. A fund request nobody answered used to sit at FundsRequested forever, and — worse than the silence — its items stayed locked against edits and deletion the whole time, so one ignored request quietly froze part of a household's list. The expiry period is now a needed-by date set by whoever raises the request, not a platform default or a per-agency window: both of those describe the platform's patience, while the question a household actually has is when it runs out of incontinence pads. Making it the requester's field turns a timeout into information — the date is shown to the family on the fund request and orders their cross-client funding inbox (NEED-29), because a deadline you have to open a request to discover is not urgency. A request raised without a date still expires on a one-week window from approval, so the rule binds where nobody thought about it. Management may extend a date while approving, but may not send onward a request whose date has already passed: it would arrive dead and be closed before anyone could answer, which reads as a broken feature rather than a deadline. Expiry releases the items, and is recorded as a new terminal Expired state rather than folded into Declined — nobody refused it, nobody answered it, and recording silence as refusal puts words in a family's mouth in the one record anyone would later consult. The edge is the only one in the request state machine no person can take: a system actor was added that resolveEssentialNeedRequestActor never returns, so "an expired request must never draw down a wallet" is enforced by the machine having no path from Expired to Funded rather than by a check somewhere remembering to look. NEED-2 and NEED-21 are updated on Essential Needs for the released items and the fourth terminal state. WALLET-11. Nothing happened to a wallet when care ended: a leftover balance was neither returned nor flagged, a receivable neither collected nor written off, and the wallet simply stopped moving with the family's money still recorded as owed to them by an agency no longer serving them. Closing a client is now gated on the wallet, in three bands. A remainder within five dollars is written off automatically — but with a ledger entry, because "never silently zeroed" is a rule about the record and not the amount, and a wallet ending at zero with nothing explaining how is exactly what it forbids. Anything larger refuses the close until somebody records what happened. Deliberately not an outright refusal at any non-zero balance: that reading is simpler to explain and eventually strands a case over ten cents. Because the platform never holds the money (WALLET-12), a card refund stays the agency's own action in its Stripe dashboard — that close-out mode records the decision and posts nothing, since the charge.refunded webhook already posts the matching debit, and posting one here as well would count the same refund twice and leave a family's wallet showing a debt the platform invented. The end-of-care half of the standing "how does a family get their money back" decision is answered; the before care ends half is explicitly still open, and now noted as needing only a family-facing way to start the same close-out machinery. Both pages' Decisions-needed entries are resolved or narrowed accordingly, the who-can-do-what table gains four rows, and the page's banner now records that no rule on it is unbuilt — four remain ⚠️ Partial, of which WALLET-19 is still the one that matters most. No rule IDs were renumbered.
• The wallet warns a household before the agency has to front anything, and stops scolding them for paying. WALLET-6 is built: a per-household balance minimum, set by Owner/Admin on the client's wallet and never by the responsible party, who could otherwise silence the warning they are the subject of. Per household rather than per agency because a family shopping weekly needs a different floor from one buying twice a year, and a single figure across a caseload is wrong at both ends — constant noise for one, silence for the other. No floor agreed is a real state distinct from a floor of zero: zero would speak only once the wallet was empty, which is the failure the rule exists to pre-empt. The threshold is deliberately not a ledger entry, because WALLET-24 guarantees a balance can be rebuilt by summing entries and a setting posted to that ledger would poison the sum. The alert reaches agency management as well as the family — the family holds the money but the agency holds the shopping list, and only one of them knows a shop is due on Thursday — with management resolved by wallet:manage rather than a role list, so an agency that delegated its ledger to a custom role has that role told. Building it surfaced a collision the page had never had to resolve, because only one of the two rules had ever fired. WALLET-6 and WALLET-21 both watch a falling balance, and left alone they would both have described the same debit: a request approved against a thin wallet would have sent the same representative three notifications — charged, low, overdrawn — which is how a family learns to ignore all three. The rules are now divided at zero. WALLET-6 owns the band above it: the balance has reached the agreed floor but the agency has not yet had to cover anything, which is the whole window the rule was written for. WALLET-21 owns everything below, where it says the more useful thing and says it with more urgency. WALLET-6 fires on the downward crossing only — a wallet resting under its floor is a standing condition the screens already show, and repeating it every shop trains people to swipe it away. The same work fixed a live behaviour nobody had named. WALLET-21's alert was level-triggered on every ledger movement, and manual credits run through that path — so a family paying $40 against a $100 debt was answered with "your wallet is overdrawn", the one reply guaranteed to discourage the next payment. It now fires when the agency has just fronted more: a movement taking the balance below zero, or deepening a debt already there. A repayment that shrinks a debt without clearing it says nothing, because the position is on the wallet screen at all times and did not need announcing. WALLET-6 moves to ✅ and its who-can-do-what row gains a holder; WALLET-21 is reworded to separate the balance being surfaced (always) from the alert being raised (when the debt grows). Both predicates live in @anaya/shared under test, including a case asserting the two can never both fire for one movement. No rule IDs were renumbered.
• Anaya Wallet had shipped and the handbook still said nothing had. The page carried a Planned badge, a banner reading "specified but not yet built", and all 27 rules marked 🚧 — while the ledger, Stripe Connect onboarding, card top-ups on both the dashboard and the mobile app, drawdown on fund approval, and receipt reconciliation had all been in production. A page that understates what exists invites someone to build a second one beside it, so Anaya Wallet is audited rule by rule against the code. Twenty of the 27 rules are confirmed ✅, including the ones the module's legal design rests on: direct charges settling to the agency's own connected account with the agency as merchant of record (WALLET-12, WALLET-13), one idempotent debit per fund request (WALLET-14), credit only on the partner's own confirmation and never on the paying device's word (WALLET-23), an append-only ledger whose entries each carry the balance they produced and which repairs the cached balance from itself (WALLET-24, WALLET-25), and the platform fee floored to whole cents and stamped onto each transaction when it is raised (WALLET-22). WALLET-27 is ✅ and its own open decision is resolved: the responsible party pays on their own device, in the mobile app, with staff-assisted collection kept as the second route rather than the only one. Four rules become ⚠️ with the missing half named on each — WALLET-2 (offline refusal exists on mobile only), WALLET-4 (a request closes on quantities received, and the receipt photo is optional, so nothing yet requires proof of purchase to exist), WALLET-10 (cards including Apple Pay and Google Pay; no ACH), and WALLET-19. Three remain genuinely 🚧: the low-balance alert (WALLET-6), fund-request expiry (WALLET-8), and the end-of-care close-out (WALLET-11). WALLET-6 deserves its own note, because its notification type is registered and nothing ever sends it: the only balance alert that fires is the one saying the wallet has already gone negative, which is precisely the event the rule was written to get ahead of. WALLET-19 — a care provider must never be asked to spend their own money — is downgraded to ⚠️ for the gap that reaches back to why this module exists. The prohibition is enforced everywhere the platform can enforce it (a care provider holds no wallet permission and sees no balance, payment history, or receivable), but the wallet balance is a ledger figure and the money it stands for sits in the agency's Stripe balance, while the provider is standing in a shop. Nothing in the product says what they pay with, so whether they front the cost is decided off-platform and invisibly. It is added to Decisions needed with three options — record the instrument on the purchase, track a provider reimbursement ledger, or issue per-request spend-limited virtual cards — and until one is chosen the module's founding promise holds by convention rather than by construction. The who-can-do-what table is corrected against the code: connecting and disconnecting the payout account are Owner, not Owner/Admin; the balance minimum and the unused-funds return have no holder because neither exists; and care manager is noted as a custom role that reaches the wallet only where an agency grants it, since nothing about money is delegated by default. Essential Needs rewrites NEED-12 as shipped-but-partial and retires NEED-23, whose whole subject was the interim before the Wallet existed; the glossary drops the Wallet's "Planned" marker and records that a top-up's actual instrument is kept against its ledger entry. No rule IDs were renumbered and no retired IDs were reused.
• A month of assigned shifts can be answered in one action, because the deadline does not wait for thirty separate taps. A care provider's auto-assigned shifts arrive one per day, and the app made them answer one per day: open the schedule, tap the day in the month grid, scroll to the row, tap Accept, confirm. Twelve pending shifts is twelve of those journeys, and every one of them is carrying a response deadline (SCH-9) — so the real cost of the friction was not annoyance, it was shifts lapsing unanswered while the provider fully intended to work them. Scheduling & Shifts adds SCH-66: a care provider may answer many awaiting shifts at once, over their own shifts and only those still open to a response — the batch reaches exactly the shifts they could have reached one at a time, so it grants no new authority and needs no new permission. Three things about the batch are stated rather than left to the implementation. It is never all-or-nothing: every shift reports its own outcome, and a shift reassigned away between the list being read and the button being pressed comes back named instead of quietly dropping the other eleven — the same principle SCH-59 already established for final assignment, where one unstaffable shift must not strand the batch. It is announced once, not once per shift: a care manager learns that a provider answered a run of shifts, and on a decline the care team is told once that a set of shifts is open for pickup (SCH-10), because twelve identical pushes in a row is not twelve times the information — it is one piece of information and eleven reasons to turn notifications off. And each shift still records its own status change and its own audit entry, because the batch is a convenience offered to the person answering and must not become a gap in the record of what was answered: collapsing the announcement is a decision about attention, collapsing the history would be a decision about accountability, and only the first one is ours to make. Declining in bulk is included rather than withheld — a provider who has to refuse a week deserves the same single action as one who accepts it — but it sits behind its own confirmation with a shared reason, since the mass decline is the direction that puts shifts back on the market. The who-can-do-what table gains the matching row.

2026-08-14

• A routine time becomes a window, because nobody wakes at 7:00 exactly. Every routine time — wake, sleep, breakfast, lunch, dinner — was a single clock time, and every part of the platform downstream treated that instant as a fact: the schedule chips positioned a shift against it, and the AI task generator timed meals and pre-wake preparation from it. Real home care does not work that way. A client wakes somewhere in a stretch of morning and breakfast is served somewhere in a half hour, and a data model that can only say 07:00 forces everyone reading it to either over-trust the number or quietly invent their own tolerance around it. The care plan had already noticed: its routine anchors carried a flexibility figure rendered as "08:00 (±30 min)" — but that figure was discarded the moment the plan seeded the client's operational routine times, so the one place the fuzziness was recorded was the one place nothing read it. Routine & Habit Tracking adds ROUT-15: every routine time is a window with an earliest and a latest time, never an instant; both ends are required, they are cleared together, and a window whose latest time precedes its earliest is read as crossing midnight. The half-set window is forbidden outright, because a start with no end is not a tolerance — it is a single time wearing a range's clothes, and every consumer would have to guess what the missing end meant. The flexibility figure is retired into the window rather than kept beside it: two ways to express the same fuzziness is one way too many, and the one that survives is the one a care manager can actually see and edit. PLAN-37 now requires both ends on every care-plan anchor, PLAN-38 seeds both ends together when a published plan fills an empty routine time, and PLAN-39 hands the task generator both edges and lets it place the task inside the window — the generator reasons about when the moment may fall, which is what it needed all along. SCH-47 and SCH-48 pin down the one question a window makes ambiguous and a single time never did: "before wake" is measured against the earliest time the client could be awake, so preparation is finished before the client can wake rather than before they typically do — the safe reading, and the only one that does not occasionally leave a care provider still setting up while the client is getting out of bed. CA-17 gains the matching obligation on the drafting side: the Montessori Profile and Meal Assessment give at best a single narrative time, so the AI must widen it into a defensible pair rather than emitting a zero-width window that reasserts the false precision this change exists to remove. The glossary gains Routine window and rewords Routine times and the Daily Routine section. Worth stating plainly, because the word "range" invites the other reading: a routine window expresses tolerance, not duration — "breakfast 8:00–8:30" means the meal happens somewhere in that half hour, not that eating occupies it. Existing single times are widened on migration rather than left half-set (meals and wake by 30 minutes, sleep by an hour), and existing care-plan anchors that carried a flexibility figure are centred on their old time while bare times are extended forward — the figure already meant "± around this", so centring preserves what its author meant, while a bare time never claimed any slack at all. No rule IDs were renumbered.

2026-08-12

• Report Generation was never unbuilt — most of it has been shipping as the care summary. The page carried a banner saying the module was "specified but not yet built" with all 22 rules marked 🚧, while the assembly half of it — audiences, templates, the content matrix, audience-specific rendering — had been in production for months under a different name. A page that understates what exists is worse than one that overstates it: it invites someone to build a second engine beside the one already running. Report Generation & Audience Management loses its Planned badge and is audited rule by rule against the shipped code. RPT-2 drops from 13 audiences to 11 — DPOA and Conservator were merged into a single Legal Decision-Maker because their content columns differed in exactly one of 42 items and no template ever branched on which was which. RPT-3 drops from six templates to five, because the sixth, the Comparative Period Report, is not audience-driven and ships with Health Readings instead; RPT-16 is reworded onto the merged audience. RPT-1, RPT-5, RPT-6, RPT-7, RPT-10 and RPT-14 become ⚠️ with the specific half that is missing named on each, and RPT-4 and RPT-22 are confirmed ✅ — the latter only because the engine contacts nobody at all. Three rules are added for behaviour that shipped without ever being written down: RPT-23 (the Word document is canonical and every PDF is derived from it, as CP-31 already requires of the care proposal) and RPT-24 (the reporting period is clamped to the client's care episode and the trim is disclosed on the document). The audit also found something the page had no rule for. Generating a report is gated on clients:view:assigned and nothing else, and the requested audience is validated only as a real audience — so a family representative can generate the Care Manager Dashboard for their own client, escalation trail and care-provider notes included, and a care provider can generate the legal-grade Formal Care & Welfare Report. The content matrix decides what each audience may see; nothing decides which audiences a person may ask for, which is the half that makes the matrix an access control rather than a formatting rule. RPT-25 states the requirement and is marked 🚧, and the who-can-do-what table now shows the intended roles beside the ones that actually work today. Two claims the reconciliation falsified are corrected on their own pages: RAC-8 on Reassessment becomes ✅ — the side-by-side two-period report exists — while RAC-10 and RAC-11 become ⚠️ (the care-episode and future-date checks are enforced and name the period that failed; overlap and data sufficiency are not), and RAC-9 and RAC-12 stay 🚧. The matching gap on Care Lifecycle stops saying the module "is not yet built" and says the accurate thing instead: the report exists but is generated by hand for a client rather than pre-filled from the event that triggered the review. What genuinely remains unbuilt is the entire authorization half — no sign-off state, no immutable authorization log, no 48-hour escalation, no delivery gate, and no delivery at all (RPT-12, RPT-15–RPT-21) — and the trajectory indicator (RPT-8, RPT-9), the symptom-log and family-interaction blocks, and the threshold-change annotation (RPT-11). The Welfare Status Banner deserves its own note: RPT-13 wants it drafted from the period's data and approved by a care manager, and what ships is a fixed sentence, identical on every Formal report, asserting no evidence of neglect was observed — drawn from no data and approved by nobody. Whether to build it as specified or retire the rule in favour of the fixed sentence is added to Decisions needed. No rule IDs were renumbered.

• The period health report becomes a Word document, and stops promising a draft it never saved. Every other document this platform produces — care proposal, care plan, shift report, care summary — is built as a Word file with the PDF converted from that same buffer, so the two cannot disagree. The period health report was the last one still rendered directly to PDF by a separate template, which meant a care manager who wanted to annotate one before sending it on had nothing to annotate. Health Readings adds HEALTH-39: the report is built as Word, and any PDF is derived from it. HEALTH-8 is reworded off "the exported PDF" onto the exported document in either form. Because Word has no chart it can be handed, a chart inside the document is a picture — so HEALTH-40 requires every metric's weekly breakdown to be present as text beside it, since a number a reader cannot edit is a number they cannot correct, and the tables are what a correction is made against. HEALTH-41 closes the gap that made the old charts misleading in the other direction: a week with no readings must be reported as absent rather than as a measured zero, because a flat line at zero reads as nothing went wrong when what actually happened was nobody measured. The same distinction is now carried in the data — a week records how many of its readings fell outside the client's range, where before the one chart labelled "alert count" was in fact plotting how many readings were taken. HEALTH-7 is retired: it required a draft to be saved even when the AI summary failed, and was never built that way. The rule is withdrawn rather than implemented, because the written summary is the part of the report that says what the numbers mean — a numbers-only draft sitting in the list looks finished, reads as a report, and is silent on the only question it was generated to answer. A failed summary now fails the generation, out loud. The page also states plainly what the comparative report is for and where it does not overlap the care summary: a care summary narrates one period for a chosen audience, while a comparative report answers what changed and by how much, which is what a reassessment or a change to authorized hours is argued from — the single-period mode is a vitals-only snapshot and overlaps by design. Finally, the mobile app's health-metrics Export button is removed: it called a route that has never existed, so every press ended in "Export failed", and mobile has no way to generate or open a period report for a working export to act on. Reports are generated and exported on the web dashboard, and the Known gaps say so instead of leaving a button that only ever fails. No surviving rule IDs were renumbered and the retired ID was not reused.

• The family funding a request gets a place to do it, and the app stops deciding for itself whether they may. The fund request has been reachable on mobile since the chain shipped, but only down a path that assumed the person walking it was a care provider: home → a client's card → the pantry list → a Funding requests row → three sections of other people's work → the request. The one row where the app said a decision is waiting pointed at the household's grocery inventory rather than the decision, which is a fair description of why those decisions went unanswered. Worse, whether the approval button appeared at all was worked out on the device, from a profile the app fetches only on certain screens — so arriving straight at a request from its own push notification, on a cold start, showed a family member the request and no way to answer it. The button was not refused; it was absent, which reads as a broken app rather than a denied permission, and the failure was silent in the one direction that costs money. Essential Needs adds NEED-29: a responsible party must have one list of every fund request awaiting them across all the households they are responsible for, reachable without first picking a client and showing each estimate beside the wallet balance it would leave — someone caring for two parents answers both in one place instead of remembering to visit each household's shopping screen. The same rule moves the eligibility question to where the answer actually lives: the responsible-party designation is on the client record, so the platform decides and tells the app, and the app never re-derives it. Approving from the list still opens the itemized, priced lines first (NEED-20) — a summary is enough to triage a queue, never enough to commit somebody's money — and a decline needs no account of how it was reached, because it commits nothing and puts the items back on the list. The who-can-do-what table gains the inbox row. Two gaps are corrected rather than left flattering: NEED-22's "a request notifies nobody" was already untrue — agency approval does push a deep-linked fund request — while submission, decline and completion still send nothing, so a care provider learns of a decline by going to look; and the web dashboard has no funding inbox, so management recording answers on behalf still works one household at a time.

• Essential needs become real inventory, and asking to buy something stops being a property of the thing itself. An item's status was its stock: adding one marked it Needed, which meant both "the household is out of this" and "somebody please buy it," and the two are not the same claim. A household that already had four packs of diapers had nowhere to say so, and an item entered on a quiet Tuesday to get it on the record went straight onto the next shopping list. Essential Needs separates them. Every item now carries an on-hand count and an optional par level, and NEED-6 and NEED-7 — specified since this page was written and never built — are activated and rewritten around them: Out of stock, Low and In stock are derived from the numbers rather than set by hand, and an item with no par level is never Low, which is the escape hatch for anything a household stocks irregularly. Being low is now a signal, not an order: it offers the item first when someone builds a request, with the gap between on-hand and par pre-filled as a suggested quantity, and a person still decides. NEED-1 drops "always starts as Needed" and says the opposite — adding an item records that the household uses it and never asks anyone to buy anything. The request becomes a genuine purchase order: NEED-18 lets any item be bundled with its own quantity to buy rather than only the currently-Needed ones, and records what the household had on hand at the moment it was bundled so a reviewer can see the gap they are approving; NEED-21 closes a request when every line is received rather than when every item is Purchased, and allows a line to be received in part, so the record reflects what was actually bought instead of what was asked for. Three new rules carry the count: NEED-26 makes the stock ledger append-only — a wrong count is fixed by recording a correction, never by editing history, so what a household believed it had stays legible beside what it actually had; NEED-27 fixes the only three ways the count may move (receiving a line, a care provider logging use on a shift, a hand adjustment) and forbids it going negative; NEED-28 requires that shift-side logging to exist, because the person who opens the last pack is the only person who knows it was the last pack — and it is marked 🚧 Spec only, since it is the one path not yet built. NEED-24 is superseded and kept in place rather than renumbered: restock existed only because a status was the sole record of whether the household had something, and running out is now a count reaching zero. The old Needed | Purchased status is deleted outright, with no compatibility mirror on either the item or the API — a derived field that exists only to keep an older client working is a second source of truth for the same question, and the one thing this change is for is having a single one. Because the essential-needs data on every environment was test data, it was deleted rather than backfilled: a migration that invents an opening count and a par level would produce a stock ledger that reads exactly like a real one, and NEED-26 exists precisely so an agency can tell what a household actually had from what somebody assumed. NEED-2, NEED-3, NEED-4, NEED-9 and NEED-11 are reworded off the retired status, and the open question of how thresholds get set closes — a single per-item par level, no category defaults, because a par level is a property of one household's consumption rather than of a product class, and a default would be wrong for two clients using the same product weekly and hourly while looking authoritative. The who-can-do-what table gains adjusting a count and logging use on a shift.

• Reading a task's instructions stops being optional. The instruction steps a care provider is meant to internalize before performing a task were sitting in an expandable card that nobody had to open: Start Task was live from the moment the sheet opened, so the steps could be — and were — skipped entirely, which quietly made the whole generation pipeline behind them decorative. AI-Generated Task Instruction Steps adds STEP-19: a scheduled task cannot be started until every one of its steps is ticked off, and the start control refuses out loud rather than sitting inert, because an unexplained dead button reads as a fault rather than a rule. A step marked optional never gates — a step the care provider may legitimately skip for this client must not be something they are made to affirm — and a task carrying no steps, or only optional ones, starts freely, so the gate can never strand a task behind a bar it has no way to clear. STEP-20 ends the gate where it should end: starting the task closes the steps so the documentation form is what's in view, they stay one tap away as a reference, and submitting the documentation is never blocked by an unticked step — withholding the record punishes the wrong thing, losing the account of the care instead of improving the reading of the instructions. Together these are the enforcement point for STEP-12's intent while no pre-shift reading surface exists: the steps get read at the last moment they can still change what happens. The who-can-do-what table gains the care provider's new obligation.

• A representative's Care Feed is now only their own client. FEED-18 narrowed who can see a post about a client, but it left the rest of the feed alone — so a representative still opened the app to the agency talking to itself: general staff posts, and a birthday notification for a care provider they had never met. Care Feed adds FEED-21: a representative sees posts linked to the clients they represent and nothing else, through every door into the feed — the feed itself, bookmarks, notifications, and direct links — and no permission an agency can grant widens that, because the narrowing follows from a representative being a member of the household rather than of the agency. FEED-22 completes the loop for what they write: a representative's post must name one of their clients, since an agency-wide post from them would be visible to the agency but not to its own author. FEED-9 and FEED-10 are amended to match — birthdays are celebrated among staff, and representatives are neither celebrated in the agency's feed nor notified of a staff birthday.

• A mis-connected payment account can now be undone — until money moves. Setting up the agency's payment account is one click, and clicking it while signed into the wrong Stripe account left no way back: the link was written once and never cleared. Anaya Wallet adds WALLET-26: an agency may disconnect its payment account and run setup again from nothing, but only while no payment has ever settled on it — once real money has moved, the ledger's reconcilability against the partner's own record of that account (WALLET-17) pins the connection permanently. Disconnecting removes the platform's link only — the Stripe account itself stays the agency's — and any payment still open on the account is canceled there first rather than left collectable against a connection the platform has forgotten. The who-can-do-what table gains the matching row: disconnecting sits with the Owner, beside the stakes it shares with connecting in the first place.

2026-08-11

• The Wallet becomes a real per-client balance, because the money never touches the platform. Anaya Wallet forbade a stored balance outright — WALLET-12 ruled it out and the revolving fund was parked as a "Stage 2 / Future" behind money-transmitter licensing — and the reasoning was sound but rested on one assumption: that the platform would be the one holding the money. It will not be. Each agency is onboarded as its own merchant at the fintech partner (Stripe, now selected), and every top-up is a direct charge settling into that agency's own account and its own bank details in a single hop. Anaya never takes custody of a cent: Stripe is the money transmitter, the agency is the merchant of record and owns its refunds and chargebacks, and the balance the platform shows is a ledger of a prepayment the agency holds on the client's behalf — the obligation an agency would otherwise keep in a spreadsheet. So WALLET-12's prohibition survives intact in spirit — the platform must never hold client funds — and what is revised is only the conclusion that had been drawn from it, that no balance may therefore exist. The two-stage framing is gone with it: there is one model, and fund-on-approval is now simply a top-up sized to a single request. The page adds WALLET-20 – WALLET-25: one wallet per client, scoped to the agency that serves them (WALLET-20); approving a fund request draws the balance down even past zero, and the resulting negative balance is an agency receivable that must be shown to agency management and the responsible party rather than hidden, netted away, or clamped (WALLET-21) — which adds no new risk, it writes down the fronting that already happens off-platform today; a percentage platform fee taken as Stripe's application fee, configured platform-wide in basis points (default zero) and snapshotted onto each transaction when its payment is raised, so a later rate change can never reach money already in flight (WALLET-22); a credit applied only on Stripe's own asynchronous webhook and never on the paying browser's report of success, processed idempotently per event so a redelivered confirmation credits exactly once (WALLET-23); whole cents only, with every ledger entry carrying the balance it produced (WALLET-24); and a correction as a new entry with a reason rather than an edit (WALLET-25, restating WALLET-17 for a ledger that now carries a balance). WALLET-6 (low-balance alert) and WALLET-11 (return unused funds when care ends) lose their Stage 2 / Future markers and apply to a real balance now, and WALLET-11 additionally requires a negative balance to be settled explicitly rather than silently zeroed. WALLET-7 is reversed: exceeding the balance no longer refuses a request — it takes the balance negative, says so, and prompts a top-up. The charge-and-settle rules are reworded around a wallet instead of a single request — WALLET-1, WALLET-5, WALLET-9, WALLET-10, WALLET-13, WALLET-14, WALLET-15, WALLET-16 (an underspend now restores to the balance rather than refunding a card) and WALLET-19 (a request reaches a care provider only when the money is with the agency, whether from the wallet or from the agency knowingly carrying the receivable). Top-ups are collected on an embedded Stripe Payment Element in the web dashboard, card only in v1 and staff-assisted, because representatives are served only by the mobile app and the app has no essential-needs surface yet — recorded as a limitation rather than a preference. The cost of the reversal is stated on the page instead of glossed: a family's money can now sit with an agency for weeks, and Anaya cannot refund what it never held, so a family's recourse runs through their agency or their card issuer. Three decisions close (which fintech partner — Stripe; who pays the processing fee — a percentage platform fee on top-ups; does the revolving fund ever happen — yes, it is the model) and three open (bank transfer alongside cards, a self-serve top-up surface for representatives on mobile, and how far negative a wallet may go). The glossary rewrites the Anaya Wallet section, adding Wallet balance, Receivable, Top-up, Application fee, and Connected account, and rewrites Revolving fund from a deferred future concept into the balance itself. Every rule stays 🚧 Spec only — nothing has shipped. No rule IDs were renumbered and none were reused.

• The fund-request chain gets a screen, and a bought-out item can be asked for again. The chain that decides how a client's essential needs get paid for — provider asks the agency, agency asks the family — has existed in the system since it was specified, and none of it was reachable: a request could be raised, reviewed, funded, and closed through the API while nobody could do any of it from a page. The client's Essential Needs page now has a second tab where a request is built by ticking needed items and watching the itemized estimate add up, sent for review, approved or declined with a reason, and closed against receipts with estimated and actual spend side by side. The actions a request offers are derived from the state machine itself rather than written out per status, so the page can never present a move the server would refuse. Approving is deliberately not called approval where a family is concerned: because the dashboard does not serve representatives at all, the funding step is labelled record the family's answer, warns that it is being recorded on their behalf, and carries that fact — and the name of whoever recorded it — onto the request (NEED-20). The same change closes the loop the standing library was rebuilt for: a Purchased item can now be marked needed again from the list, which opens a new cycle and leaves the purchase history untouched, and the button is hidden on an item still bundled into an open request because restocking it would leave that request unable to close (NEED-24). Essential Needs marks NEED-21, NEED-23, NEED-24, and the retailer-snapshot rules NEED-14, NEED-16, and NEED-25 built, and narrows the rest to what is honestly true rather than dropping their badges: NEED-13, NEED-15, and NEED-18 are the dashboard only — the care provider who knows what the household is out of still cannot search a retailer or raise a request from the app they actually use. Three gaps are stated plainly instead of implied: a request notifies nobody (NEED-22 — every step is logged and none of it is sent), a reviewer can approve or decline a bundle but cannot adjust it (NEED-19), so one over-priced line costs the whole request, and a representative still has nowhere to answer for themselves.

• Recording a family's approval now has to say how you reached them; recording their refusal does not. Marking a request funded on a responsible party's behalf commits money they were never shown a screen to approve, and the record left behind was a name and a timestamp — which does not assert anybody was actually asked, and is what the agency would have to stand on if a family later said they never agreed. NEED-20 now requires an account of how an off-platform approval was obtained: who gave the answer and how they were reached. A decline deliberately requires nothing, because it commits no money and returns the items to the list — the same asymmetry the handbook already accepts in NEED-19, where declining is the direction that must be explained. The known gap is recorded with it rather than papered over: the account is free text with a minimum length, which stops a reflexive "ok" but is a speed bump, not evidence. The structural fix — a required channel (phone, email, in person) beside an optional note, one click and impossible to pad — needs a field on the fund decision and is not built.

2026-08-08

• The catalog is gone: products are looked up live, and a client's list becomes a standing library. A stored catalog of items — even one curated from a real feed — was solving the wrong problem. What a household needs is not a shared library of everything an agency might ever buy; it is this household's own repeating list. So there is no catalog at all now: adding an item searches the retailer live, and only a product snapshot is kept on that client's item — what the retailer said, and when. Anything the feed does not carry is still typed by hand. Two consequences follow, and both were the point. Prices are quoted from a store resolved from the client's own address rather than one platform-wide setting, because the care provider shops near the client's home; the same product can therefore be priced differently for two clients, which is correct, and where no store can be resolved the search returns photos with no prices and says so instead of showing $0. And a client's list is now a standing library: an item stays on it after being bought and is restocked when the household runs out again, so every purchase is appended to a permanent history rather than overwriting the last one — which is what finally makes NEED-10 real rather than specified. Essential Needs rewrites NEED-2 (a recorded purchase is permanent; the item restocks), NEED-13–NEED-16, NEED-24 and NEED-25, marks NEED-10 built, and replaces its catalog terms with Standing library, Retailer lookup, Product snapshot, Reference store, and Restock. The platform catalog page and the override catalog prices permission are both removed — the catalogue drops from 100 to 99 — and Identity & Access loses that entry. Three gaps are recorded rather than glossed: the fund-request chain still has no interface on web or mobile, retailer search and restocking are absent from the app care providers actually use, and no representative can yet approve a request themselves, so every funding decision is recorded on their behalf.

• One feed covers the whole catalog; the second, paid one is dropped. The plan assumed a grocery feed for food and household items and a separate commercial feed for the medical half — incontinence, wound care, mobility aids — on the assumption a supermarket API would not carry them. Checked against a real Los Angeles store rather than assumed, the free feed returned photos and shelf prices for incontinence underwear, gauze pads, nitrile exam gloves, disposable bed pads, and cane tips. The second feed is therefore not needed, which removes a monthly cost and a blocking vendor decision, and the enrichment sweep now covers both item types instead of groceries alone. The same check surfaced why the confident-match rule matters: searching a grocery feed for "walker" returns shortbread and beer long before a mobility aid, so the threshold that refuses a weak match is what keeps a wrong photo off a care provider's shopping list. Essential Needs rewrites the feed decision and replaces the untested-coverage gap with the naming risk that survives it.

• The catalog is curated from the live feed, not shipped as a list. A hand-authored seed list was the wrong shape twice over: it had no pictures, and it made a JSON file in the repository the source of truth for data that lives in the database — the same split that already lets the task-template catalogue drift. Catalog items are now added by Anaya through the platform dashboard, searching the live retailer feed and picking real products: the retailer supplies the name, photo, size, and price, and Anaya assigns the item type, category, and unit, because no retailer feed knows this catalog's eldercare classification. Adding the same retailer product twice is refused, and an item is never deleted — it is retired, which hides it from every agency's picker while the essential needs and requests that reference it keep pointing at it. NEED-13 is rewritten from "must ship a starter catalog" to "must maintain a curated catalog"; NEED-14 gains the retire rule.

• Catalog photos and prices come from the retailer feed, and say so. The seeded catalog shipped with real names and estimate prices but no pictures — deliberately, because inventing retailer image URLs would have been fiction. Photos and prices are now pulled from the feeds instead, and each item records which feed, that feed's own product reference, and when it was taken, so an agency looking at a price can see who said so. Two rules keep the pull honest: an item the feed cannot confidently match keeps its placeholder rather than a plausible-but-wrong picture, and the price taken is always the shelf price, never a promotional one — a promotion expires, and a budget approved against one understates the real shop a week later. NEED-13 gains the provenance requirement.

• The catalog belongs to the platform; an agency's only lever is its price — in the open. The same-day design pass sharpened the catalog model three ways. First, catalog items are platform-level only: seeded or feed-synced once and shared by every agency, with no agency able to add, edit, or remove them — an agency's sole customization is a price override, and even that never hides the platform's number, which stays visible beside the override to agency staff and representatives alike, so a family always sees the retailer reference price next to what their agency expects to pay. Second, an essential need created from the catalog keeps a permanent reference to its catalog item alongside the priced snapshot it was added with. Third, the existing essential-need record — a free-typed name and a hand-guessed cost, acknowledged as a temporary minimal design — is being rebuilt rather than migrated: the stored records are cleared and the schema redesigned around the catalog. Essential Needs rewrites NEED-14 and adds NEED-24–NEED-25; the glossary gains Price override. Three permissions enter the catalogue with the feature (ACCESS-37): override catalog prices and review essential-needs requests for agency management, and approve fund requests, which joins the Representative's role-inherent responsibilities on Identity & Access (ACCESS-35 updated) under the same hybrid model as meal approval — management may record the family's off-platform answer on their behalf.

• The family's money now arrives before anyone shops, and the platform deliberately never holds it. Anaya Wallet was specified as a revolving fund — the family loads a pot of money, the agency draws against it — which is the version that requires the platform to hold other people's money and therefore money-transmitter licensing in nearly every state, an unresolved blocker that had the whole module parked as Future indefinitely. The real problem it was meant to solve is narrower and more urgent: today the agency buys a client's essential needs out of its own pocket and chases the family for reimbursement, and where the agency does not front it, the care provider standing in the store does. The Wallet is therefore redefined as the payment rail underneath the fund-request flow, not a replacement for it — Essential Needs still owns the conversation (provider asks the agency, agency asks the family), and the Wallet owns only the money — and it now ships in two stages. Stage 1, fund-on-approval, stores no balance at all: approving an itemized fund request charges the responsible party for that request and settles the funds to the agency's verified payout account before shopping begins, so money passes payer → fintech partner → agency and never rests with the platform. Because the charge is an estimate and receipts are the truth, every closed request reconciles — an underspend is refunded to the card it came from, an overspend raises a small top-up, and a difference is never quietly kept as a credit, because a retained credit is a stored balance and would undo the whole design. Stage 2, the revolving fund, is kept but explicitly deferred behind licensing, per-state coverage, and KYC on every responsible party. Anaya Wallet moves from Future to Planned, rescopes WALLET-6, WALLET-7, and WALLET-11 as Stage 2 only, rewrites WALLET-1, WALLET-4, WALLET-8, WALLET-9, and WALLET-10 around a fund request rather than a balance draw, and adds WALLET-12–WALLET-19: no resting client balance and custody with the partner (WALLET-12), charge-and-settle on approval (WALLET-13), one idempotent charge per request so a retry can never double-charge a family (WALLET-14), a failed payment leaving a request unfunded rather than funded-but-unpaid (WALLET-15), reconciliation of actual against charged (WALLET-16), an append-only ledger reconcilable to the partner's record (WALLET-17), settlement only to an agency account and never a care provider's personal one (WALLET-18), and the promise the module exists for — a care provider must never be asked to spend their own money (WALLET-19). The page's standing conflict over who raises a request is resolved by deferring to the Essential Needs chain: providers raise, agency management approves, and only the responsible party funds — care providers hold no Wallet permission and never touch money. Essential Needs rewrites NEED-12 and NEED-23 so the Wallet slots beneath the existing flow instead of replacing it with a "purchase request". The glossary rewrites the Anaya Wallet section, adding Fund-on-approval, Revolving fund, Payment method, Payout account, Settlement, Reconciliation, and Ledger, and retiring Purchase request. Settlement timing — immediate on approval, a held reversal window, or escrow until receipts — is the one open Stage 1 decision, because escrow would reintroduce the very fronting the module exists to remove. No rule IDs were renumbered and retired IDs were not reused.

• Buying for a client now starts from a picture and a price, and the money is asked for before anyone shops. An essential need was a free-typed name with a hand-guessed cost, so a household's budget was only as accurate as whoever typed fastest — and the care provider in the home, the one person who actually knows what the household is out of, had no sanctioned way to get it paid for short of fronting their own money or chatting the family. The page now specifies a platform starter item catalog — the everyday consumables an elderly household runs out of, each with a photo, a category, a default unit, and a reference price an agency can adjust to its local stores, extend with items of its own, or hide from — so picking an item fills in its details and its estimated cost, and the budget estimates itself. A reference price is an estimate, never a quote, and an item keeps the estimated cost it was added with: re-pricing the catalog never rewrites an existing item or a request the family already signed off on. On top of the catalog sits the fund-request chain — the provider asks the agency, and the agency asks the family: the provider bundles needed items into an essential-needs request whose itemized, priced total is visible before it is sent; agency management reviews, adjusts, and approves it; approval becomes a fund request the client's responsible party explicitly approves or declines; and receipts close the request with estimated and actual spend side by side. Until Anaya Wallet ships no money moves through the platform — the fund request records the ask, the sign-off, and the reconciliation while payment happens outside, and it becomes the Wallet purchase request when the Wallet arrives. Essential Needs adds NEED-13–NEED-23 (all 🚧 spec ahead of code), folds its Wallet-future section into the new fund-request flow, and adds four open decisions. Two were settled the same day: the catalog's products, photos, and prices are sourced from external retailer feeds — the Kroger Products API for groceries, whose prices are keyed to an agency-chosen reference store, plus a commercial product-data feed for medical supplies, with Amazon's PA-API ruled out by its 2026 deprecation and affiliate-sales floor — and a responsible party's off-platform answer may be recorded on their behalf by agency management, clearly marked as recorded-on-behalf (NEED-20), so a family that never opens the portal can never stall a purchase. The glossary gains Item catalog, Reference price, Essential-needs request, and Fund request; Anaya Wallet now points at the interim flow. No rule IDs were renumbered.

2026-08-07

• A care proposal can now be handed to whoever actually writes proposals, not just to an Admin. Transferring authorship offered only staff holding the built-in Owner, Admin, or SuperAdmin role, and refused anyone else outright. But a custom role is a separate thing from a base role rather than a variety of Admin, so an agency that had moved its senior staff onto a custom role like Care Manager could not hand a proposal to the very people writing them — they were missing from the picker and rejected by the transfer. Eligibility is now stated as what a person is trusted to do rather than what their role is called: anyone active in the proposal's own agency who is allowed to create and edit care proposals can take authorship, which is the Admins by default plus any custom role granted that ability. The names offered and the check enforced now come from that one rule, so the list can never show somebody the transfer would then refuse. Two narrower corrections come with it: a proposal can no longer be handed to someone in a different agency, which nothing previously prevented, and platform-level accounts are no longer eligible to author an individual agency's proposal. Who may perform a transfer is unchanged. Care Proposals rewrites CP-22 and its permissions row.

2026-08-06

• A care document can now be opened in Google Docs, not just downloaded as Word. Every care document the platform produces — the care plan, the care proposal, the care summary, the shift report — could only leave the platform as a file on someone's laptop, which is where collaborative editing stopped: two people reviewing the same care plan meant two copies and a reconciliation. Each of those documents now also offers Open with Google Docs, which puts the same Word document the platform would have downloaded into that person's own Google account, converted, and opens it. Connecting is asked for at the moment it is first needed rather than on a settings page beforehand, and the platform asks only for permission to manage files it created itself — it can never read the rest of that person's Drive. Opening the same document twice reopens the same Doc so edits survive, while a republished care plan or an amended shift report produces a new one, so republishing can never overwrite what somebody wrote. Access deliberately gets no permission of its own: whoever may download a document as Word may open it, and nobody else, so the two can never drift apart. The signed care proposal stays PDF-only exactly as it already was. Integrations & API adds INT-16–INT-19, a Google Drive row in the integration register, two permission rows, and moves off "nothing on this page is implemented".
• Exporting a care document to Google is recorded, but nothing after it is. The same change writes down a consequence worth stating plainly rather than discovering later: once a care document has been converted into someone's Google account it is theirs, and the agency can no longer recall it, see who it was shared with, or follow it in the activity log. That is why the connection is per-person and per-document rather than an agency-wide sync. INT-19 requires the platform not to present this as equivalent to an in-platform download and never to export on someone's behalf unasked. Two gaps are recorded rather than papered over: the activity log stops at the export, and nothing yet restricts which Google account a document may land in — including a personal one, which carries no business agreement with Google covering client information. Whether an agency should be able to confine exports to Google accounts it controls is now an open decision on that page.

2026-08-03

• Reviewing a shift now starts with what went wrong, and a shift will have an address of its own. A care manager opening one shift could land in any of four different views of it — an assignment sheet with no tasks or reflection, a narrow scorecard, a wide report with no management actions, or a thin calendar dialog that could only link back to a list — and which one they got depended on where they clicked rather than on what they wanted to know. None of them could be bookmarked, shared with a colleague, or linked from a notification, and a shift outside the currently loaded page of results silently opened nothing at all. Shift review is now defined as one ranked list of exceptions shown before any other detail, covering the whole span from nobody assigned through to a missing reflection, with each entry naming the part of the record that answers it and a clean shift saying so plainly. Exceptions are graded: critical means a care obligation went unmet or care was delivered without a required safeguard, warning means care happened and the deviation deserves review. Two gradings follow from rules already on this page rather than from preference — a missing reflection is a warning, because SCH-27 already closes such a shift as completed without reflection and the client still received care; and a clock-in later than the agency's no-show window is critical, because by SCH-25 that shift should already have been marked a no-show. The same signal is required on every shift list, computed only from what a list row already knows, and a row may under-report but may never claim a shift is clear. Scheduling & Shifts adds SCH-60–SCH-63, a "Reviewing a worked shift" section, a permissions row, and a note on the lapsed-unstaffed-shift known gap. Every shift now has its own page under its client, opening on that ranked list, and the four overlapping views are gone — the calendar keeps a peek whose job is to hand off to the page rather than dead-end on a list, and a bare shift id resolves to the right place for notification and email links. Both shift lists carry the same badge, computed from what the list already knows so no row costs an extra lookup, and All Shifts gained a "Needs attention" filter that states plainly it only covers the loaded page. SCH-60, SCH-62 and SCH-63 are all in code.
• Reading a shift by its id now checks who is asking. Giving shifts their own addresses turned a route nobody called into one that gets bookmarked and shared, and it carried no row-level check — every care provider could read every colleague's shift, including the clock-in and clock-out record. A care provider may now read a shift they are assigned to, or one that needs coverage (because the pickup flow legitimately opens an available shift before they have any claim on it); care managers and admins continue to read any shift in their agency, which was never in question. The clock record itself is also trimmed to the timing and geofence facts a reviewer needs, leaving raw coordinates and internal admin notes to the location view that has always been gated more tightly. The handover list route was gated to match — it enforced the same scope in its own code but never declared it, which is why the platform's route-coverage check had been failing. New SCH-64.

2026-07-29

• An accepted care provider is told they were hired, and their app now knows it. Accepting an applicant looked up their details with a query scoped to the reviewer's own agency — but the marketplace's whole point is applicants who belong to no agency yet, or to a different one. For those applicants the lookup came back empty and, worse, discarded the reference to the person entirely. Everything downstream then acted on nobody: the applicant received no in-app notification, no push and no email; they were never added to the hiring agency; and they were never put on the client's care team, so their phone kept showing the "no client yet" home screen indefinitely. The same empty lookup is why some applicants showed with blank details in the review list. The applicant is now identified before any of that work begins, so a filtered lookup cannot break it. Two ordering and reliability faults are fixed alongside: the acceptance notification was sent before the care-team record was written, so the phone's refresh could read "still no client" and cache that answer — it is now sent last; and a notification addressed to nobody used to be recorded as delivered, which is why none of this left a trace, so it now fails loudly and is retried. A care-team add that fails during acceptance now notifies the agency staff who can fix it, rather than only appearing in a server log. Job Postings marks JOB-18 and the surfacing clause of JOB-22 as in code, and drops the blank-provider-details known gap.

2026-07-28

• An audit entry can no longer vanish, and the log always reads in true order. The activity log was written inline and its failures were swallowed twice over, so a failed write disappeared without trace — the entries most likely to be lost were exactly the ones written while the platform was struggling. Entries are now queued the moment an action completes and written by a background worker that retries with increasing delays, parks an entry an operator can re-run rather than dropping it, and falls back to writing directly if the queue itself is unavailable, so queuing can never be less reliable than not queuing. Because a retried write can land late, every entry now also records when the action happened rather than only when it was written, and the log orders by that. The audit queue is visible on the system health dashboard like every other background queue. SEC-6 (tamper-proof audit log) remains 🚧 — retryable is not tamper-proof. Platform Operations rewrites OPS-22, adds OPS-35 and the Parked entry term.
• A proposal's status and its history can no longer disagree. Status was stored only as the newest entry of a history array read newest-first, so every guard, filter, and sort re-derived it by indexing into that array — and one write path that appended without the others' assumptions would have left the record quietly wrong, with nothing to catch it. Care proposals, clients, and initial assessments now each carry their current status as its own field, written in the same atomic update as the history entry and refused outright if the two would disagree; the history reads oldest-first like an ordinary timeline, and a rolled-back transition removes both halves together. Two long-standing consequences are fixed along the way: editing a completed initial assessment no longer silently reverts it to draft (and so no longer blocks converting it to a proposal), and creating a client from a proposal can no longer be recorded twice by two people acting at once. Separately, a proposal's own timeline is now stated to be distinct from the platform activity log: the log is a compliance record with its own retention, never read to build a proposal screen. Care Proposals adds CP-35 and updates CP-13.

2026-07-26

• One shift nobody could work no longer strands a client's whole setup. Shift generation starts its window at the earliest schedule date rather than at today, so a batch is routinely created already containing shifts whose start time has passed — and nothing ever retires them, because the no-show sweep deliberately ignores shifts with no care provider. Final assignment demanded coverage for every shift in the batch, so a single lapsed shift blocked the commit permanently: it could not be staffed, cancelling it did not help, and deleting it left the batch referring to a shift that no longer existed and failed the same check. Both governing rules were already written as "every upcoming shift" (SCH-56, LIFE-13) — the code was simply stricter than the rule it claimed to implement. A shift that ends without a committed provider, or that was cancelled, is now excluded from the coverage requirement and kept as a historical record, never retroactively assigned; the refusal names the shifts still genuinely outstanding instead of only counting them. Scheduling & Shifts adds SCH-59 and two Known-gaps notes.
• A published posting now reaches care providers by email too, and publishing can be kept quiet. A new posting alerted providers in the app and by push, but never by email — the channel a care provider between shifts is most likely to actually read — so postings sat unseen. Publishing now also sends email, using the same branded notification layout as every other alert. Publishing had no off switch either: any correction, test, or backfilled posting re-announced itself to every provider, which taught staff to avoid the feature. Publish now offers a choice to alert providers, on by default, that suppresses in-app, push, and email for that publish alone without changing the posting's visibility. A provider's own opt-out still wins over an agency choosing to alert. The audience is now taken from the posting's agency rather than the publisher's, so a platform administrator publishing on an agency's behalf no longer reaches every provider on the platform. Job Postings rewrites JOB-5 and adds JOB-38.
• Screening an applicant no longer means opening their profile. An application card showed a name, an email, a distance and a hidden menu — everything that decides a hire (do they have the skills we asked for? can they actually work the shifts they picked?) was one or two clicks away, so reviewers accepted on gut feel and discovered conflicts at the acceptance gate. Each application now carries its own screening summary — required skills tagged held or missing, distance from the work, and how many requested shifts their declared availability allows with the first blocking reason named — computed from the same evaluation the acceptance gate uses. Mark as Reviewed, Reject, and Accept are now visible buttons on each card rather than menu items. Job Postings adds JOB-37.
• Job postings now say when the work is in the same vocabulary care providers use for availability. A posting's schedule was an iCal recurrence rule with a duration, which nothing could compare against a provider's declared weekday-and-clock-time availability. Every posting now carries a shift pattern — weekday plus clock times in one timezone — derived from the selected shifts on a coverage bundle and entered directly on a generic posting, so what is advertised can never drift from the work on offer. Matching is a direct comparison instead of a recurrence simulation, and the schedule is finally shown on posting cards and detail pages. Job Postings rewrites JOB-3, JOB-4, JOB-10, JOB-20, JOB-22, JOB-24, JOB-26, JOB-28 and adds the Shift pattern term; Scheduling & Shifts updates SCH-12 and SCH-16; ARMI Marketplace updates MAP-7 and MAP-17; Glossary gains the same term.
• Overnight shifts can be covered. A provider could not declare availability that crossed midnight, and the matcher rejected any shift whose start and end fell on different local dates, so every night shift was unfillable for everyone. A shift is now evaluated as one segment per local calendar day and matched against that day's declared availability, and 24:00 is accepted as an exclusive end-of-day sentinel so the two halves of an overnight stretch meet exactly. Both availability editors offer overnight entry and write the two segments themselves. New SCH-58; MAP-7 and MAP-17 state the segment model.
• Coverage bundles are a chosen subset, and a drifted posting stays readable. A bundle previously had to contain every shift in the batch while every shift also had to be unassigned — two conditions that could not both hold once Shift Assignment began, which blocked creating, viewing, applying to, or accepting any posting for that client. Staff now select which uncovered shifts to advertise, defaulting to all of them, with covered shifts shown alongside and the reason given. Coverage health is reported on read rather than enforced, so a posting whose shifts were regenerated can still be opened and closed. JOB-4, JOB-10, SCH-12.
• Acceptance reliably puts the provider on the care team. The workflow gate that governs manual care-team additions was also being applied to job-application acceptance, and its failure was logged as "already assigned" — leaving the provider off the team and blocking final Shift Assignment with an unrelated message. Acceptance now bypasses that ordering gate, reactivates a previously removed membership instead of failing on the duplicate, and surfaces genuine failures. The care-team matching view also ranks by declared availability, as it always claimed to. JOB-22, CL-33.
• Postings are no longer hidden for being a poor fit. Marketplace lists filtered out postings a provider could not fully take, contradicting the requirement to show the reason instead. Fit is now annotated rather than filtered. JOB-10, JOB-26.

2026-07-24

• Made care-provider work availability mobile-first while implementing the coverage workflow. Care providers can now edit weekly windows and date exceptions from Me → Work Availability in the mobile app; assigned and unassigned home screens show a setup banner until the record is complete, and coverage applications show only concrete eligible shifts. The web profile remains a secondary editor. Backend scenarios cover invalid windows, effective ranges, overrides, conflicts, reservations, hour limits, stale generation, and final commitment; mobile scenarios cover API, query, banner, and editor-navigation states. ARMI Marketplace updates MAP-7–MAP-10 and MAP-17–MAP-20 from specification to their current implementation status, with MAP-19 explicitly making mobile the primary provider surface.
• Rebuilt client setup as a strict, coverage-first Care Operations workflow. The canonical sequence is now Schedule → Shift Generation → Care Plan → Care Team → Shift Assignment → Meal Plan → Engagement Bank → Care Task List → Meal Assignment → Engagement Assignment. Care Lifecycle adds the ordered backend and interface gates, record-derived progress, and dependency invalidation (LIFE-8–LIFE-15). Scheduling & Shifts separates unassigned 45-day generation batches from final staffing, introduces schedule revisions and staged coverage, and requires complete coverage before later steps unlock (SCH-6, SCH-8, SCH-12–SCH-16, new SCH-50–SCH-57). Care Plans records the generation batch and schedule revisions that ground a plan (PLAN-41–PLAN-43). Clients separates care-team membership from shift assignment (CL-32–CL-33). Job Postings replaces single-shift conversion with multi-shift coverage bundles: applicants select eligible shifts, reviewers approve a subset, acceptance stages coverage, and a posting closes when every bundled shift is staged (JOB-1, JOB-4, JOB-10, JOB-16, JOB-20, JOB-22–JOB-24, JOB-28, new JOB-29–JOB-36). ARMI Marketplace replaces vague preference availability with timezone-aware weekly windows, effective dates, date overrides, commitments, and staged reservations (MAP-7–MAP-10, new MAP-17–MAP-20). A dry-run-by-default reset migration is included for the one-time cutover; the remaining non-atomic reservation-release and regeneration-reconciliation gaps stay called out on their owning pages. No surviving rule IDs were renumbered and retired IDs were not reused.

2026-07-18

• Reconciled the Initial Assessment and Care Proposal pages with the shipped shared-intake / Care Circle / GCS code (docs catching up to code). The initial assessment and care proposal now embed one shared client intake, so initial assessment → care proposal → client is a lossless clone with nothing re-entered. On Initial Assessments: re-scoped the page to the pre-client funnel entity, pointed the embedded inventory at Care Assessments as its single owner, replaced "contact person" with the Care Circle and a resolved responsible party (AS-2, AS-6), corrected the lock model — a Completed assessment reopens to Draft when edited and the only hard lock is "already converted" (AS-3; AS-25 retired), documented durable clarification-only AI generation and the Guided Narrative (AS-27 reworded; new AS-29–AS-36), and retired the Independent/Set-up/Partial/Full + RTI-E/ACL/ADM inputs (AS-26, AS-28). On Care Proposals: replaced "family contacts" with Care Circle / responsible party / addressees (CP-15, CP-16, CP-17; new CP-32), documented AI generation of the cover letter / care goal / care areas with clarification-only HITL (new CP-28–CP-30), the derived cover-letter tone (new CP-33), the canonical Word document with every PDF derived via Gotenberg (new CP-31; CP-17/CP-18 updated), the assessment-score rate formula (new CP-34), the lossless convert clone (CP-1, CP-3), and client activation carrying the Care Circle and seeding the inventory (CP-19), plus the permission precedence on CP-4. New rule IDs were appended; none renumbered.
• Adopted "Care Circle" as the canonical model for a client's people, and flipped Assessment Mode from Planned to shipped. Clients now owns the Care Circle definition (aligned with the care-proposal model): a Representative is a thin portal-access link keyed to a Care Circle member, the responsible party is a resolved-not-invented pointer, and new rules CL-28–CL-31 cover the roster (the client is never a member), carry-over on convert with automatic portal provisioning, and the fixed six-value role set (CL-14, CL-16, CL-19 updated). Care Assessments gained a dated audit banner and reworded CA-8 to the GCS Capacity / Support now / Risk completion model (retiring the "independence score" term). Assessment Mode is no longer "Planned": it documents the shipped Guided Narrative intake over the seven gated topics (care setting + the six Life's Milestones), re-auditing AMODE-1–AMODE-14 (clarification-only HITL replaced the old review gate; agency-configurable domains AMODE-7 and the disclaimer footer AMODE-14 stay 🚧). The glossary gained Care Circle (with member and role), Capacity / Support now / Risk, cover-letter tone, and proposal addressee, broadened Responsible party into one authoritative entry, and rewrote the Simplified Routine Task Inventory and Initial assessment entries; Base Rates now notes the initial assessment also prices from the catalog (cross-referencing CP-34). No surviving rule IDs were renumbered.

2026-07-15

• Reverted the routine-anchored scheduling epic (docs-first — matching the code rollback). Removed the 24-hour split coverage pairs, the paid handover overlap window, the co-present handover checklist (distinct from the async handover notes, which stay), the prep-window / prep-lead settings, the stored task phases (prep/routine/handover) and anchor reference, and the stale-schedule review flow (schedules flagged stale by a plan publish). Scheduling & Shifts lost SCH-43–SCH-46 and SCH-49, and the coverage-pair clauses on SCH-7, SCH-13, SCH-14, and SCH-15 were reverted to their single-provider meaning; SCH-47 and SCH-48 now describe positioning a schedule from the client's routine times (a start before the wake time is preparation) with no agency prep-lead setting. Care Plans & Care Provider Tasks lost PLAN-40, and PLAN-37 / PLAN-38 / PLAN-39 were rewritten: the care plan's Daily Routine section proposes the client's routine time anchors, publishing seeds the client's routine-times record (fill-if-empty), and task times come from the routine anchors with preparation inferred from the wake time and the shift start (no stored phase or anchor reference). Routine & Habit Tracking ROUT-13 / ROUT-14 and Care Assessments CA-17 now point at the client's schedule-page routine times rather than a Daily Routine & Coverage section. The Care Lifecycle connective-trigger matrix lost row 9 (PLAN-38 → SCH-49 / PLAN-40). The glossary dropped Coverage pattern, Coverage pair, Handover overlap window, Handover checklist, Prep window, Task phase, and Anchor reference, generalized Routine anchor into Routine times, renamed Daily Routine & Coverage section to Daily Routine section, and restored the Handover entry to the async notes only. Routine times remain the schedule-page source of truth; the care plan proposes/seeds them; the AI task generator infers preparation from the wake time and shift start. Removed rule IDs: SCH-43, SCH-44, SCH-45, SCH-46, SCH-49, PLAN-40. No surviving rule IDs were renumbered.

• A client's routine times move to the schedule page as the operational source of truth (docs-first — spec ahead of code). A care manager sets a client's routine times — wake, sleep, and meal times — directly on the client schedule page, with no published care plan required; these drive shift start (the prep window), the coverage-pair day/night split, and AI task timing. SCH-47/SCH-48 were reworded so anchored-schedule defaults come from the client's routine times (not "published routine anchors"), and SCH-49 now flags dependent schedules stale when the routine times change from either a direct edit or a care-plan publish. PLAN-38 now frames the care plan's Daily Routine & Coverage section as a proposer that seeds empty routine-time fields on publish (fill-if-empty, never overwriting a set value), and PLAN-39 reads task times from the routine times. ROUT-13/ROUT-14 were reworded from "routine anchors owned by the care plan" to the client's schedule-page routine times as the single source a tracked habit reads. The glossary replaced Routine anchor with Routine times and reworded the Daily Routine & Coverage section entry. No rule IDs were renumbered.

• Routine-anchored scheduling and 24-hour split coverage pairs (docs-first — spec ahead of code). The care plan gains a structured Daily Routine & Coverage section — routine anchors (wake, breakfast, lunch, dinner, nap, bedtime, or custom, each a client-local time plus care guidance) and a coverage recommendation — as the only place in the plan where clock times belong (PLAN-37); publishing denormalizes the anchors and coverage onto the client record, stamped with the source plan version (PLAN-38); every Care Task List task carries a phase (prep, routine, or handover) and may carry an anchor reference recording how its time was derived (PLAN-39); and a plan version that changes the anchors a task's time came from flags the dependent published Care Task List stale, extending PLAN-34 (PLAN-40). Scheduling & Shifts gains the 24-hour split coverage pair — two linked 12-hour day/night shifts, always two different care providers, overlapping by the agency-configurable paid handover overlap window (default 30 minutes, 0 allowed) with a structured co-present handover checklist and its block-or-flag clock-out setting — plus the pre-wake prep window and anchor-based schedule defaults with a recorded anchor context, and the stale-for-review flag on anchor-linked schedules (SCH-43 – SCH-49, all 🚧); SCH-7, SCH-13, SCH-14, and SCH-15 were amended with coverage-pair clauses (duplicate-skip, sanctioned overlap vs. double-booking, paid overlap hours, per-provider counting). Routine & Habit Tracking gains ROUT-13/ROUT-14 (anchors are owned by the plan's section and a corresponding habit's expected schedule must never diverge from them; an anchor is not itself a logged habit — anchors drive scheduling, routines drive logging), and Care Assessments gains CA-17 (the Montessori Profile's Daily routine area and the Meal Assessment's meal timing preferences are the AI's source signals for drafting the anchors — the assessments stay narrative). The Care Lifecycle connective-trigger matrix gained row 9 (PLAN-38 → SCH-49 / PLAN-40, 🚧): anchor or coverage changes flag dependent schedules and Care Task Lists stale for review — nothing auto-cascades. The glossary gained Coverage pattern, Coverage pair, Handover overlap window, Handover checklist, Prep window, Routine anchor, Daily Routine & Coverage section, Task phase, and Anchor reference, and the Handover entry now notes the co-present checklist handover inside a pair's overlap window. No rule IDs were renumbered.

2026-07-10

• Care assessments become versioned, and reassessment becomes a pure suggestion engine (docs-first — spec ahead of code). Care Assessments gains in-record versioning — every save keeps the prior content in the record's own history and increments a version, still one record per client per assessment (CA-15; CA-1 was clarified to say so) — and a client-level assessment generation: applying accepted reassessment suggestions writes the changes and cuts a synchronized generation across all six assessments, each bumping a version and keeping its status (Completed stays Completed — the documented exception to CA-2, which was reworded to name it) (CA-16). Reassessment is redefined as a suggestion engine: the agent proposes per-assessment, per-field changes — assessment, field, current value, suggested value, rationale — and never applies anything (RAC-16); while AwaitingReview the care manager unticks what they reject and applies the rest in one action before recording the outcome, recomputing materiality (RAC-17; RAC-13 was reworded from "changes a client's scores" to "finds that a client's scores have changed", gaining recompute-on-apply and moving ✅ → ⚠️). Care Plans & Care Provider Tasks closes the provenance chain: a post-outcome plan draft records the assessment generation that grounded it (PLAN-36), chaining generation → plan version → Care Task List (PLAN-34). The Care Lifecycle connective-trigger matrix gained row 8 (RAC-17 → CA-16 → PLAN-36, 🚧) and the reassessment cascade diagram now shows the Apply leg; the glossary gained Assessment version and Assessment generation, and the Reassessment loop entry was reworded (suggest → apply → generation). Two Care Assessments decisions were resolved: #1 (editing a Completed assessment — manual saves keep the Draft revert, history preserves the record, the Apply path is the sign-off exception) and #4 (assessments don't expire on a timer; every reassessment now re-reviews them field by field). No rule IDs were renumbered.
• Catch-up entry: docs reconciled to shipped code (change made 2026-07-10, missed its changelog line). Reassessment RAC-4 moved ✅ → ⚠️ — the standalone hospitalization/ER trigger is not yet wired as its own signal (the hospital round-trip is reached through the return-from-discharge path); a Known-gaps bullet says so. Transition of Care TOC-4/TOC-15 wording was corrected to match the shipped gate: the first post-discharge shift is hard-blocked until the updated plan and its regenerated Care Task List are published — the gate releases on the task-list republish (which necessarily post-dates the plan publish), not on the plan publish itself; the hospital-to-home diagrams on both pages now show that leg. No rule IDs were renumbered.

2026-07-09

• Care lifecycle is now documented as built, not planned. The Care Lifecycle page was rewritten for readability and re-audited against the shipped code: it lost its "Planned" badge and gained a plain-language "loop at a glance", a "what the platform does vs. what you decide" split (LIFE-5), two simplified journey diagrams, and pointers to the real screens (the Reassessments queue and the client Change of Conditions / Transition of Care tabs). All seven rows of the connective-trigger matrix now read ✅ — the contracts fire in the backend — and LIFE-1, LIFE-2, LIFE-4, LIFE-5, LIFE-6 moved 🚧 → ✅ (LIFE-3 is a reference rule; LIFE-7 was already ✅). The stale "one review object?" and "how automatic should triggers be?" decisions were marked resolved (one reassessment record; human-gated). No rule IDs were renumbered.
• Re-audited the two hub pages behind the loop. Reassessment & Care Plan Review Cycle lost its "Planned" badge: RAC-1 – RAC-7 and RAC-13 – RAC-15 are now ✅ (routine scheduling, event triggers, review-and-record-outcome, the materiality-driven regeneration link); RAC-3 is ⚠️ (the due date is scheduled but the calendar marker is a pending web surface); and the comparative-period report RAC-8 – RAC-12 stays 🚧 pending Report Generation. Transition of Care lost its badge too: the hospital-to-home round-trip TOC-2 / TOC-4 / TOC-10 – TOC-15 is ✅ (discharge notes open a review; the first post-discharge shift is hard-blocked until the updated plan is published, enforced at shift creation and again at clock-in); TOC-1 is ⚠️ (all four transition types are defined but only hospital-to-home is wired); and agency-to-agency, home-to-facility, the within-agency provider change, and the transition checklist (TOC-3, TOC-5 – TOC-9) stay 🚧.
• Fixed handbook rule-ID popovers. Bare rule IDs in prose (e.g. LIFE-2, RAC-13, TOC-4, STEP-16) are meant to become clickable definition popovers, but the recognizer's prefix list had drifted behind the content — 28 in-use prefixes (LIFE, RAC, TOC, STEP, HOSP, MEM, PERSONA, CREQ, ESM, SEC, RPT, INT, AMODE, GAME, EVAL, COORD, WALK, TELE, ROUT, OFF, HEAL, WALLET, DATA, LANG, FB, AX, EVV, ADAPT) were unregistered and rendered as plain text. They are now recognized, so those IDs pop over across every page.

2026-07-07

• Change-of-condition significance can now be set in the dashboard, and the care plan page prompts when a plan may be out of date (COC-8, LIFE-2/LIFE-5). The change-of-condition review dialog gained a Routine / Significant judgment (COC-8); marking a change significant fires the existing signal that flags the client's Care Task Lists for regeneration review and notifies managers — previously that path existed in the backend but had no way to trigger it from the UI. A new plan-currency notice on the care plan page (Care Lifecycle LIFE-2) surfaces, in plain language, why the live plan may no longer match the client's condition — a stale Care Task List (condition change, plan update, or assessment change) or an unaddressed significant change of condition — with actions to generate an updated plan or review the change(s). Consistent with LIFE-5, it only prompts: nothing is regenerated automatically. This partly realizes the reconciliation loop's first legs; a formal reassessment (RAC) that re-scores the assessments, and a distinct care-plan-review object (LIFE-4), remain spec only. Statuses moved: COC-8 🚧 → ⚠️, and the connective-trigger matrix row 1. No rule IDs were renumbered.

2026-07-04

• Replaced the client profile summary with Client Memory. Added a new page Client Memory (new prefix MEM, rules MEM-1 – MEM-9) defining an evolving, AI-maintained per-client narrative that is revised in place over time — carrying forward what is still true, updating what changed, adding new observations, dropping the obsolete — rather than the old one-shot blurb regenerated from scratch. It runs on the durable AI-generation framework (background job, generation dock, one run per client), updates manually and automatically when new signals land (shift note/observation, change of condition, incident, care-plan publish; automatic updates are debounced and never block on a human — MEM-9), draws on the client's static profile and ongoing record (MEM-3), is versioned and correctable (MEM-6), and grounds other AI generation for the client (MEM-7). The client profile summary term is retired (glossary + AI Features), and a note on Anaya — the AI Persona reconciles PERSONA-5's "no memory across conversations" (the chat persona) with the persistent per-client memory store. Care-feed posts are not yet a signal source (business-scoped, no client link — Known gaps). No existing rule IDs were renumbered.
• Enforced the business-active block (ACCESS-11) and the idle sign-out (ACCESS-10). Both rules had a mechanism that never ran: they lived in global guards that execute before sign-in is resolved, so they always deferred (the same latent-guard bug fixed for permissions in July 2026). The two checks moved to the single point every authenticated request passes through, where they cannot be bypassed: a person whose business is suspended or inactive is now blocked everywhere — including the Owner, until a platform operator reactivates it — with a typed "account inactive" response the apps show as a friendly screen; and a session with no activity for 15 minutes is signed out. Independent (business-less) providers and platform operators are unaffected. No rule IDs changed; the matching Known gaps on the identity page were removed.

2026-07-03 (later)

• Closed the permission alias window. The capability catalogue (ACCESS-31 – ACCESS-37) is now the only catalogue: the 64 superseded permission slugs were deleted from the platform's enum, resolution no longer emits legacy aliases, and stored role configurations were migrated on staging and production (with pre-migration backups). Legacy slugs arriving from any remaining stale data still upgrade transparently at read time — that normalization is permanent. The identity page's Known gaps were narrowed accordingly (the "documented ahead of code" and "role editor locked rows" gaps are resolved); the appendix stays as the historical mapping record. No rule IDs changed.

2026-07-03

• Redesigned the permission catalogue around capabilities on Identity, Access & the Business. New rules ACCESS-31 – ACCESS-37 define the convention: every permission is feature : verb (: scope); the only verbs are view, manage (create + edit + delete + duplicate + AI-generate, at most one per feature, bounded by the holder's view scope), and a closed list of justified workflow verbs (ACCESS-34); scoped view only where visibility genuinely differs (ACCESS-32); a separate delete only for initial assessments, care proposals, job postings, and users (ACCESS-36); and no permission may exist without gating something real (ACCESS-37). A new appendix on the page is the authoritative migration contract for all 147 previous permissions: 79 unchanged, 42 folded or renamed (e.g. chat:access + calls:initiate → communication:access), 4 role-inherent, 22 removed (the unshipped appointments, emergency-response, and audit-log families — they return with their features). ACCESS-23 was corrected to the real default scopes.
• Introduced role-inherent permissions (ACCESS-35). Responsibilities that define a base role can no longer be revoked by configuration: a Representative always holds respond to care proposals, sign home inventories, approve meal plans, and approve engagement plans. The role editor will show these locked; they stay grantable to other roles. Cross-referenced from CP-16, MEAL-5, ENG-2, and INV-6. Documented ahead of code (docs-first) — the Known gaps on the identity page track the distance.
• Resolved the eight-verb reconciliation decision (old Decision 7 on the identity page): the PRD's View/Create/Edit/Delete/Approve/Assign/Configure/Export grid is the catalogue, folded — Create/Edit/Delete are manage, the rest survive as workflow verbs where a distinct actor performs them. Remaining decisions renumbered 7–9.
• Repaired permission enforcement product-wide. Every action that declares a required permission now actually checks it — previously the check was silently skipped across large parts of the product (clients, shifts, care proposals, chat, posts, and more), because the permission gate only ran on surfaces that wired it explicitly. The repair kept real workflows working: representative proposal responses, the care feed, caregiver health observations and document uploads, and Care Manager supervision flows were re-floored to the permissions those people actually hold, and Care Manager roles gained the five operational permissions their daily flows require (task comments and concern triage, observation review, Care Lock access). A burn-down snapshot in code now guards against new unenforced actions; the identity page's first Known gap was narrowed accordingly.

2026-06-24

• Care-plan generation can now be grounded in agency policy (PERSONA-8). When a business opts in (settings.aiPolicyGroundingEnabled, default off), AI care-plan generation retrieves the agency's policy/procedure/clinical-guidance documents (those marked useForRetrieval, Published) and adds them as guarded context before drafting — so the plan reflects the agency's rules. Default-off and best-effort (a knowledge-base outage never blocks generation). Task, meal, and summary generation are not yet grounded.
• Defined Anaya as a persona, not just a feature. Added a new page Anaya — the AI Persona (new prefix PERSONA, rules PERSONA-1 – PERSONA-10) that defines the single AI character shared across every AI surface — its role, four-word character (Grounded, Warm, Precise, Unhurried), honesty-first guardrail (PERSONA-3: warmth as acknowledgment, never sycophancy), and self-awareness. The character is authored once as a shared character constitution and loaded first into the AI chat assistant's system prompt. PERSONA-7 reconciles the two ways Anaya answers: the anonymous general helper that CHAT-3 keeps away from all business data, versus the permission-gated grounded assistant that may use a business's retrieval-eligible knowledge base and cite it. Also added knowledge-base tagging (category, audience, sensitivity, status, and the useForRetrieval switch) as the agency's control over the policy/knowledge Anaya consults; useForRetrieval and Published status now gate AI chat grounding, with existing documents backfilled to today's behavior. (Training-content generation stays driven by explicit document selection at generation time — TRAIN-11 — not a tag.) No rule IDs were renumbered.
• Connected the client care lifecycle into one flow. Added a new spine page Care Lifecycle (End-to-End) (new prefix LIFE, rules LIFE-1 – LIFE-7) with a master state machine and a connective-trigger matrix that turns the previously-siloed client-care modules into one loop. The six broken links between them are now explicit rule contracts: CA-14 (a changed RTI/ACL assessment flags instruction-step regeneration via STEP-5); COC-8 (a significant change of condition triggers a reassessment via RAC-4) and COC-9 (a discharge hands off to transition of care via TOC-2); PLAN-34 (publishing a new care plan version flags dependent Care Task Lists stale) and PLAN-35 (change-of-condition, discharge, and reassessment converge on one care-plan review); TOC-15 (the hospitalization round-trip — OnHold → transition → reassessment → resume — with the first post-discharge shift hard-blocked until the plan is updated); and HOSP-11 (a hospice client's change of condition uses a comfort-care review). RAC-4's trigger list was extended (pattern-analysis via STEP-16), and RAC-13 was reworded so the regeneration link is mandatory while the materiality threshold is agency-configurable with a default; STEP-5/16/17 ↔ CA/RAC cross-references were added both directions. No rule IDs were renumbered.
• Renamed "task plan" → "Care Task List" across the handbook (page Care Plans & the Care Task List, the glossary, the index rule table, and cross-references) to end the constant confusion with "care plan", which now always means the narrative document. The PLAN prefix and rules are unchanged, and the in-code entity stays CareProviderTasks. This resolves the long-standing PLAN naming decision.
• Corrected the status of AI-Generated Task Instruction Steps. Basic AI generation of a task's instruction steps is actually in code; the page's blanket "Spec only" banner was narrowed and STEP-1 re-tagged ⚠️ Partial, while the approval/versioning/flagging/pattern-analysis loop stays 🚧 Spec only.
• Resolved "Decisions needed" into rules on Change of Conditions (significance → reassessment; discharge → transition), Care Plans (stale-task flag; the two-"care-plan" naming), Reassessment (materiality threshold default), and Transition of Care (hard-block the first post-discharge shift; discharge keeps its own track but shares the common review). The glossary gained a Care lifecycle section plus RTI-E, Significant change of condition, and Materiality threshold.
• Third low-risk known-gaps sweep (backend + web + mobile). Eleven resolved gaps removed or narrowed; no rule IDs were renumbered. The backend fixes are small, localized, and each carries a unit test, and the frontends were aligned so the resolutions are actually usable.
• Frontend alignment: CREQ-6 is now fully resolved on both clients — the web and mobile request-status controls resolve a custom role's allowed transitions from its permissions (previously they keyed off the role string, so a custom role holding the manage-requests permission saw no status buttons). The web reviews list also gained an "Unverified Only" filter option, exercising the both-directions verification filter the prior sweep added on the backend.
• Resolved (removed): on Job Postings, a Closed posting could be quietly reverted to Draft and republished (JOB-6 — publish/unpublish/update now refuse a Closed posting) and the always-zero per-status application counts (the aggregation now casts the posting id to an ObjectId); on Incident Reports, a resolved report could be reopened or re-resolved with stale resolution details (INC-7 — Resolved is now terminal server-side); on Medications, the server-side "discontinued" filter never worked (a boolean query param was mis-coerced), medication file attachments recorded the client instead of the uploading staff member, and adding a medication left no activity-log entry (MED-22 now fully met); on Engagement Activities, unapproved activities could still be scheduled into shifts (ENG-2 — single, bulk, and dropdown paths are now approval-gated); on Client Requests, a custom role holding the manage-requests permission could not change a request's status (CREQ-6 — status transitions are now permission-based for custom roles); on Blog, agency administrators could manage the platform-wide blog (BLOG-5 — the admin endpoints are now SuperAdmin-only); on Care Proposals, an incomplete submitted proposal could not be withdrawn for editing (CP-24 now ✅ In code — the Pending Approval → Draft withdrawal is exempt from the completeness check, and CP-6's note was updated to match); and on Platform Operations, a malformed Care Lock vault search returned a generic 500 instead of a clear 400.
• Reconciled a stale gap: on Emergency Alerts, the SOS-5 note claiming emergency-alert recipients were chosen by a fixed role list was already out of date — the emergency-alert listener selects recipients by permission (so custom roles with full emergency permissions are notified); the stale bullet was removed.

2026-06-23

• Reconciled the Known gaps against code fixes that shipped in the app (the "small known-gaps sweep" across backend/web/mobile). Resolved gaps were removed and partially-addressed ones narrowed; no rule IDs were renumbered.
• Resolved (removed): the cross-agency caregiver-map leak on ARMI Marketplace (MAP-1 — the map is now scoped to the caller's business); care assessments editable by any signed-in user on Care Assessments (CA-6); the 5000% care-summary metric on Clients; unit-blind weight/blood-sugar abnormal checks on Health Readings (HEALTH-4); the "first ten" pending-meals cap on Meals; the unsanitized SOS device timestamp on Emergency Alerts; the no-top-up daily-motivation batch on Daily Motivations; and on Client Requests the missing "Other" label (CREQ-3), the zeroed per-status counts, and the Cancel button shown to non-creators.
• Narrowed (partially resolved): caregiver assignment status changes are now permission-checked but still lack lifecycle checks on Clients (CL-11); the proposal Cancel action is now gated to viewers with cancel rights, leaving only the older status-move screens on Care Proposals (CP-21 done, CP-4 remains); the special-character count/row mismatch is fixed, leaving only status sorting unreliable (Care Proposals); and body temperature & respiratory rate now appear in health-metric averages and trends but not yet in the abnormal-reading list on Health Readings (HEALTH-5).
• Removed a stray tool-output artifact (</content></invoke>) accidentally committed at the end of the ARMI Marketplace page.
• Second low-risk known-gaps sweep (backend). Nine resolved gaps removed or narrowed; no rule IDs renumbered. Resolved (removed): the ineffective "show my birthday in the feed" toggle on Care Feed (FEED-13 — opt-out is now honored); the non-working "send a greeting" button on the Celebrations page (greetings are now delivered as a comment on the celebrant's birthday post and notify them); any-user-can-be-rated on Skills, Ratings & Feature Requests (SKILL-2 — ratings are now restricted to care providers) and the missing unverified-only ratings filter (the verification filter now works in both directions); the abnormal-reading list omitting body temperature & respiratory rate on Health Readings (HEALTH-5 now fully resolved, completing the partial note above) and the always-zero wound per-status counts (Health Monitoring); the never-persisted "active" marker on task plans on Care Plans & Tasks; and on Meals the unscoped agency-wide meal bank (MEAL-1) and the rejected meal still appearing on already-assigned shift tasks (MEAL-9).

2026-06-19

• Reconciled the handbook against the Developer Reference v4.2. A second gap pass against the latest reference: terms were renamed to the canonical product vocabulary, new feature pages were captured as Planned or Future stubs, the existing infrastructure stubs were extended, and the glossary grew to match.
• Three renames. Social Feed is now Care Feed, with its page slug moved to /docs/15-care-feed; Lock Care vault is now Care Lock wherever it appears, including Platform Operations; and Caregiver Map is now the ARMI Marketplace (/docs/11-armi-marketplace), a slug move plus a major expansion into a vetted independent-provider marketplace (ARMI = Above and Beyond, Respect, Mission, Integrity). The index rule table and glossary were repointed; the FEED and MAP rule prefixes are unchanged.
• New Planned pages added (marked Planned in the sidebar, rules tagged 🚧 Spec only) with their own rule prefixes: AI-Generated Task Instruction Steps (STEP), Assessment Mode (AMODE), Reassessment & Care Plan Review Cycle (RAC), Transition of Care (TOC), Routine & Habit Tracking (ROUT), Telehealth Services (TELE), Care Coordination & Provider Integration (COORD), Report Generation & Audience Management (RPT), Anaya Walk (WALK), Elder Services Marketplace (ESM), Feedback & Improvement System (FB), Multi-Language Support (LANG), and Accessibility (AX).
• New Future stub pages added (marked Future): Anaya Healing Ally (HEAL), Hospice Care Support (HOSP), and Adaptive Technology Integration (ADAPT).
• The PRD's "Clinical Snapshot" report template is documented non-clinically as the Health Snapshot. Anaya Care delivers non-skilled home care, so the report on Report Generation keeps a plain-language, non-clinical name.
• The PRD's "Daily Login Quiz" is the existing Care Readiness Quiz. Confirmed again as the same pre-shift gate owned by Scheduling & Shifts; the glossary now carries the alias term.
• The eight infrastructure stubs were re-badged and extended. The earlier "Not built yet" pages were re-badged Planned or Future to match the new status legend and had their rules and decisions extended during this reconciliation.
• Glossary grew with the renamed entries plus new terms (ARMI, ARMI Marketplace, Elder Services Marketplace, Caregiver Level Badge, Anaya Walk, Assessment Mode, AI-Generated Task Instruction Steps, recurring time-anchored task, Time Performed, Methodology Configuration, Life's Milestones, Reassessment, Transition of Care, Discharge note, Routine & Habit Tracking, Telehealth, Care Coordination, Report Generation, report audience, content block, Health Snapshot, Welfare Status Banner, Wellbeing Summary, Professional Statement, Comparative Period Report, Tier 1 / Tier 2 family, Background check, Daily Login Quiz, and EVV data points).

2026-06-18

• "Clinical Assessments" renamed to "Care Assessments". Anaya Care provides non-skilled home care, so the handbook drops the medical-sounding word clinical. The page is now Care Assessments, its slug moved from /docs/02-clinical-assessments to /docs/02-care-assessments, and the feature name, the glossary, the index rule table, and the sidebar were repointed. Cross-references to the page were updated on Clients, Initial Assessments, Change of Conditions, and Meals; separately, the standalone word clinical was removed in unrelated contexts on Care Plans & Tasks (care-plan narrative), Health Readings (wound analysis), Platform Operations (PDF reports and PHI audit), and Integrations & API (FHIR export). The CA rule prefix and CA-1 – CA-13 are unchanged — only the wording moved; the "clinician / Medical Professional" role term is kept.

• "Requests" renamed to "Client Requests". The operational service-ticket feature is now called Client Requests everywhere (page title, glossary, index rule table, and cross-references on Communication and Skills, Ratings & Feature Requests). The new name disambiguates it from platform feature requests and account-deletion requests, which are separate features. Because the feature was not yet live, the page slug moved from /docs/13-requests to /docs/13-client-requests and the rule prefix changed: REQ-1 – REQ-17 → CREQ-1 – CREQ-17 (same rules, re-prefixed; nothing renumbered). "Request" remains the in-page shorthand.

2026-06-17

• Care readiness quiz removed from the client assessment catalog for good. Resolved the Known gap where the quiz shared the six clinical assessments' status list and errored when its status was managed there. It is now structurally excluded from the client assessment types (only the six clinical assessments remain) and stays owned by Scheduling & Shifts (SCH-37, SCH-38). No rule IDs changed.
• Healing Ally removed from the clinical-assessment placeholders. Decision 3 on Clinical Assessments now lists three "coming soon" placeholders (Caring Touch, Always Fresh, Care Bliss); wound-care collaboration is delivered by Health Readings, not a clinical assessment.
• The three remaining placeholder assessments now open a labeled "coming soon" page instead of leading nowhere; whether to build or remove them stays open under Decision 3.

2026-06-16

• Reconciled the handbook against the PRD (Developer Reference Summary, PRD v4.1). A gap pass comparing the reference PRD with the handbook: missing modules were captured as stub pages, and partially-covered modules had the PRD's requirements folded into their Decisions needed / Known gaps. No existing rules were renumbered.
• Eight "Planned modules" stub pages added, each marked Not built yet in the sidebar, with all rules tagged 🚧 Spec only: Offline Mode (OFF-1 – OFF-12), Anaya Wallet (WALLET-1 – WALLET-9), EVV Compliance Reporting (EVV-1 – EVV-8), Security & Compliance (SEC-1 – SEC-30, the §4 non-functional requirements), Data Ownership & Retention (DATA-1 – DATA-7), Integrations & API (INT-1 – INT-12), Performance Evaluation (EVAL-1 – EVAL-6), and Gamification (GAME-1 – GAME-5).
• Sidebar status badges added. Pages can now declare a status in frontmatter (e.g. status: "Not built yet") which renders as a small pill beside the sidebar item. Driven by a page-tree transformer in lib/source.ts; built pages omit status and show no badge.
• PRD requirements folded into existing pages (Decisions needed / Known gaps only — no rule changes): clock-in hard-block + 15-minute no-show alert and the shift-reflection privacy/wellbeing model (SCH); ARMI availability/booking lifecycle (MAP, JOB); AI severity, family notification, and escalation on incidents (INC); the non-dismissible DNR/advance-directive banner and acknowledge-before-first-shift (HEALTH); Care Feed camera-only/no-download/face-opt-in controls (FEED); Home Inventory acknowledge-before-shift, PDF export, and audit trail (INV); the daily-motivation display/sourcing rules (MOT); the 30-day meal-plan → grocery-list flow (MEAL); the four-tier subscriber model and company-configured roles (ACCESS); and the §7 error/edge-case behaviours plus links to the new compliance pages (OPS).
• The PRD's "Daily Login Quiz" is the existing Care Readiness Quiz. Identified as the same feature — the care readiness quiz (SCH-21, SCH-37, SCH-38), not a new module. Its remaining gaps — care-manager-visible scores, a link to the Performance Evaluation record (EVAL-5), and fresh non-repeating daily questions — are recorded on Scheduling & Shifts and Performance Evaluation; the glossary now notes the PRD name.
• Glossary expanded with terms for the new modules (offline mode & sync, Anaya Wallet & responsible party, EVV, RTO/RPO, SOC 2, data owner/processor/custodian, webhooks, HL7 FHIR, and more).

2026-06-12

• New Base Rates page. The pricing catalog behind proposal rate calculations (one base rate plus per-city overrides, with the six value-added service rates) documented for the first time: new rules RATE-1 – RATE-5. Known gap recorded: rates are stored globally with no agency scoping. Decisions raised: per-agency pricing, and whether rate changes reprice existing proposals.
• New Caregiver Map (ARMI) page. The dashboard caregiver map documented for the first time: new rules MAP-1 – MAP-2. Known gap recorded: the map endpoint skips permission and agency-scoping checks and can expose every provider's home coordinates platform-wide. Decisions raised: cross-agency intent, location precision, gating permission, and the planned Directory.
• Planned Survey feature noted on Skills, Ratings & Feature Requests as a decision to make when it is built.
• Content & Community dissolved into four module pages. The page was retired into Trainings, Social Feed, Blog, and Skills, Ratings & Feature Requests. Rules CONTENT-1 – CONTENT-14 retired → FEED-1 – FEED-14; CONTENT-15 – CONTENT-20 → BLOG-1 – BLOG-6; CONTENT-21 – CONTENT-30 → TRAIN-1 – TRAIN-10; CONTENT-31 – CONTENT-35 → SKILL-1 – SKILL-5.
• AI Chat Assistant and Knowledge Base got their own pages. Split out of AI Features, which now covers only the generation framework, writing helpers, and shift summaries. Rules AI-10 – AI-13 retired → CHAT-1 – CHAT-4; AI-14 → KB-1; AI-15 → TRAIN-11; new rule KB-2 (a document must finish processing before use; failed processing is retryable).
• Platform group moved to the top. The sidebar and index now read Platform → Intake & onboarding → Client care, putting platform-wide concepts (identity, communication, AI, trainings) before the care journey.
• Renamed "Bible" to "Handbook". No rules changed — the document is now called the Anaya Care Handbook everywhere (page taglines, index, glossary, changelog, and homepage). Same source of truth, friendlier name.
• New Client Calendar page. The per-client calendar (meals, engagement activities, doctor's appointments) documented for the first time: new rules CAL-1 – CAL-5. New decisions raised: what else should the calendar show (shifts, task occurrences, medication doses, birthdays), and should family representatives see it.
• Daily Motivations moved to the Platform group. The feature is agency-level (one quote per agency per day, no client scoping), so its page moved out of Client care to sit beside Content & Community. Rules MOT-1 – MOT-3 unchanged.
• Daily Living split into Meals, Engagement Activities, and Daily Motivations. The Daily Living page was retired. Rules DAILY-1 – DAILY-11 retired → MEAL-1 – MEAL-11 (the meal halves of DAILY-7 and DAILY-10); DAILY-12 – DAILY-14 retired → ENG-1 – ENG-3 plus ENG-4 – ENG-5 (the activity halves of DAILY-7 and DAILY-10); DAILY-25 – DAILY-26 retired → MOT-1 – MOT-2; DAILY-27 retired → per-page visibility rules MEAL-12, ENG-6, MOT-3.
• Emergency Alerts (SOS) got its own page. Split out of the incidents page, which was retitled to "Incident Reports". Rules INC-16 – INC-22 retired → SOS-1 – SOS-7; new rule SOS-8 (every alert belongs to one agency and one client); INC-3 reworded to cover reports only.
• Essential Needs and Home Inventory got their own pages. Split out of Daily Living. Rules DAILY-15 – DAILY-18 retired → NEED-1 – NEED-4; DAILY-19 – DAILY-24 retired → INV-1 – INV-6; new rules NEED-5 and INV-7 (per-page visibility and agency scoping, formerly covered by DAILY-27).
• Sidebar regrouped again. Client care lifecycle and Clinical & daily care merged into a single Client care group covering everything from Clients through Home Inventory.
• Known gaps became internal. "Known gaps" sections are now shown only when the docs run locally — they are stripped from the published site, its search, the Ask AI corpus, and machine-readable exports.
• Care readiness quiz moved to Scheduling & Shifts. The quiz is a pre-shift gate, not an intake step. Rules AS-23, AS-24 retired → SCH-37, SCH-38; the intake page was retitled to "Initial Assessments".
• Sidebar regrouped. New groups: Intake & onboarding (Initial Assessments, Care Proposals) and Client care lifecycle (Clients, Clinical Assessments, Change of Conditions, Care Plans & Tasks, Scheduling & Shifts, Job Postings).
• Change of Conditions got its own page. Split out of the assessments page. Rules AS-18 – AS-22 retired → COC-1 – COC-5; new rules COC-6 (every submitted note is evaluated for a handover exactly once) and COC-7 (a note belongs to one client, one shift, one author).
• New Clinical Assessments page. The six client assessments (Simplified & full Routine Task Inventory, Montessori Profile, Allen Cognitive Level, Home Safety, Meal Assessment) documented in detail — purpose, contents, scoring, and use. Rules AS-12 – AS-17 retired → CA-1 – CA-6; new rules CA-7 – CA-13. New decision raised: should assessments expire / require reassessment after a change of conditions?
• The handbook replaced the technical wiki. All 16 module pages rewritten as plain-language requirements: 419 numbered rules with stable IDs, per-page Decisions needed and Known gaps lists, and a platform-wide Glossary. The docs-first rule took effect: change the doc first, then the code.

2026-06-11

• Documentation site created. Initial release of the docs site with the as-built product wiki, reverse-engineered from the codebase.