Persistence before regeneration

The household accepts Monday through Wednesday. They reject Thursday's meal. Too much active effort for an evening that became busier since the plan was composed. The developer's instinct: call the model again on the full week. Regenerate everything. Hope the new pass is better. The trustworthy architecture does something different. RecommendMealSubstitution patches Thursday. Accepted days stay accepted. Dependent checks rerun on shopping list and allergy enforcement. Plan version increments. UI shows a diff: "Thursday: 35 min to 20 min active. Other days unchanged."

Helpful context: Recovery is part of trust frames the trust arc when things go wrong. Collaboration contract specifies preserve-on-correction behaviour. Point and fix is the designing analogue in interaction patterns.

Why regeneration erodes trust

Full regeneration on every correction destroys visible progress users already approved, hides what changed and why, re-introduces risk on previously accepted days, teaches users that corrections are expensive lottery tickets, burns tokens and latency on stable work, and re-opens seams where least trustworthy input wins. Users stop saying "fix Thursday." They say "try again" or abandon the product. Precision feedback requires persistence architecture, because without it the product trains users to treat correction as gambling rather than collaboration.

Preserve what users already approved. Change only what the correction requires.

Introduction to Thoughtware Ch. 13

When local patch suffices

Local patch is correct when weakness is confined to a single day after critique, when substitution stays within the same constraints, when shopping list delta is computable from one meal change, when allergy and portion checks are re-runnable locally, and when material assumptions remain unchanged. RecommendMealSubstitution proposes. JudgeLocalRepairQuality assesses patch quality. The deterministic shell applies a transactional update with plan versioning. UI shows the diff. Recovery is part of trust owns the user-visible arc. This page owns the policy: patch first.

Consider the practical arcs. In a patch path, Thursday has too much effort for a busy evening. The system substitutes a traybake, producing version 1.3 of the plan. Monday through Wednesday remain unchanged in the diff view. Shopping list delta is computed. Spinach deadline is re-checked. In a partial accept path, the household accepts Monday through Wednesday and wants Thursday and Friday revised. Persistence preserves the accepted days while targeting repair scope. The anti-pattern is a model that silently rewrites entire JSON plan. The user cannot tell what drifted. Allergy check re-runs are skipped. Trust collapses.

When full replan is warranted

Full replan is correct when material assumptions change (leftovers now unacceptable), when guard failure reveals wrong strategy class (Busy Week Pattern invalid), when multiple linked days become invalid under new context, when authority or medical frontier newly opens, or when local repair fails evaluation twice on the same weakness. Even then, showing why replan triggered versus patch is part of the conduct. Contestability requires users to see the assumption change, not surprise regeneration.

A replan example: the user adds a guest with severe shellfish allergy mid-week. Material assumption changed. Compose new week with visible rationale. Still preserve non-conflicting preferences where possible. Naming the tradeoff before discarding accepted variety goals is part of the conduct. The anti-pattern is a "Regenerate plan" button with no persistence policy, where default destruction replaces diffs with apologies.

Low cognitive first draft expects provisional plans users will correct. Persistence makes correction cheap. Without it, first draft becomes a trap: users accept to avoid regeneration pain. Keep full regeneration available for material assumption changes, but demote it in UI hierarchy. Primary actions are patch, swap, and revise assumption. Regenerate remains escape hatch, not default correction path.

Architecture and UX

Persistence is not a prompt instruction. It requires plan versioning with immutable versions and visible history, transactional updates where patch applies atomically or rolls back, named repair cognitive units for substitution and local critique and repair quality judgment, dependency re-check on shopping list and allergy code and inventory deadlines after patch, and UI diffs showing what changed, what stayed, and why. Without versioning, contest and recovery collapse because users cannot dispute what they cannot see stable.

Point-and-fix UX depends on persistence architecture. If the UI offers only "Regenerate," persistence policy is undermined no matter what the backend supports. Surface patch-level actions tied to named weaknesses: "Fix Thursday effort," "Swap Wednesday meal," "Update busy flag and replan affected days." Not "Try again" as the primary action. Point and fix describes the interaction pattern. Users see version numbers or diffs. Accepted days look stable in the interface during patch. Shock regeneration trains distrust.

When the system must stop on budget returns partial accepted state, not blank slate. Persistence policy applies to stops as well as corrections. In multi-user households, one member's patch does not silently overwrite another's accept without diff. Version history supports contest about who accepted what and when.

Common patterns

Accepted plan versions survive session boundaries. Users who return tomorrow see yesterday's accepts unless material context changed. Session-scoped state that forgets accepts forces regeneration and reintroduces trust erosion. Patching one meal may require shopping list delta, prep notes, or nutrition summaries to update. Persistence policy includes dependents, because patching Thursday without re-running shopping list checks leaves inconsistent artifacts users discover at store time.

Log patch versus replan decisions with reason codes. Rising replan rate may signal missing persistence architecture or users changing material assumptions often. Rising patch rate with low accept may signal weak repair cognitive units rather than policy failure. Public APIs expose patch endpoints alongside regenerate endpoints, and SDK defaults prefer patch. Developer docs show diff-based correction flows, because API shape trains client behaviour the same way UI buttons do.

Model upgrades do not force full regeneration of accepted plans. Versioned plans pin accepted judgments to plan versions, not model versions. Material replan triggers on assumption change, not on deploy day. Undo reverts patches transactionally across plan and dependents, because undo that only reverts meal text but leaves shopping list stale breaks persistence promises. Patch paths complete within the same latency budget users expect from single-meal edits, not full-week generation.

Offline clients queue patches with version vectors and replay on sync, because offline regen-first clients destroy accepts when connectivity returns. Notifications describe patches, not implied full new plans unless replan occurred. Notification copy trains persistence expectations the same way UI buttons do. Rolling back a bad deploy does not discard user accepts stored in plan versions, because plan versions are user data, not cache. Set internal SLAs that patch paths complete within tight latency budgets, reinforcing that persistence is the expected correction path.

Add evaluation cases: patch preserves accepted days, replan triggers only on material assumption change, dependency checks rerun after patch, version increments on each correction. Teams that eval only full-plan quality miss persistence regressions users feel immediately. Collaborative editors need operational transforms or locks on accepted days while one member patches Thursday, because persistence without concurrency control creates forked plans users cannot reconcile.

What to do next

Persistence before regeneration converts correction from lottery into collaboration. The policy, patch first and replan only on material assumption change, applies uniformly across household planners, enterprise workflows, and any domain where users approve partial work and expect it to survive feedback. Versioning, transactional updates, named repair cognitive units, dependency re-checks, and UI diffs together make the architecture real.

Read recovery is part of trust, point and fix, and contestability.

Read next: What a name buys begins the cognitive units track with naming judgments explicitly.