Recovery is part of trust

The household rejects Wednesday's meal. Effort exceeds the busy-evening budget for a now-heavier week. A brittle system regenerates the entire week from scratch, losing accepted Monday and Tuesday plans. Shopping-list checks restart from zero. The user learns that correction is dangerous.

A trustworthy system patches Wednesday via RecommendMealSubstitution, preserves accepted days, shows what changed and why, and re-runs exact checks on the shopping list. Same correction request. One response teaches users to dread edits. The other strengthens trust across time.

Recovery is trust design in the same sense as refusal, memory discipline, and visible assumptions, not an ops afterthought bolted on after launch. Users remember how correction felt long after they forget whether the first draft was elegant.

Helpful context: Cognitive posture includes recovery as a conduct dimension. Persistence before regeneration covers patch-first policy. Collaboration contract specifies preserve-on-correction behaviour.

Recovery is trust design

Operations teams know how to roll back deployments and restore databases. Product recovery is different. It is the experience of partial failure inside a workflow the user was already trusting. Recovery belongs in architecture alongside happy-path loops: plan versioning and transactional patching name how accepted work survives edits, named local repair cognitive units such as RecommendMealSubstitution and JudgeLocalRepairQuality own proportional judgment, visible diffs and rationale connect UI to architecture, and re-runs of exact checks after patch prevent silent constraint drift. If recovery exists only in runbooks, users experience product caprice. If recovery exists in specs and tests, users learn correction is safe.

A successful recovery may strengthen trust more than an unexamined success.

Introduction to Thoughtware · Ch. 15

Good recovery has testable elements, and missing any one erodes trust quickly. Specific acknowledgment means "Wednesday's meal exceeded the busy-evening effort budget" names the failure class, while "sorry about that" performs empathy without information. Preservation means accepted meals stay accepted unless material assumptions change, so Monday and Tuesday do not move because Wednesday failed. Proportional repair means one-day weakness triggers local substitution, not full replan. Dependency check means shopping list, allergy enforcement, spinach deadline, and portion calculations are re-validated after patch, because skipping dependents is how recovery looks successful while failing silently. Contestability means the user can see why Tuesday stayed and Wednesday changed, since hidden rewrites destroy trust even when outcomes improve. And visible state, whether through version numbers, diff panels, or change summaries, connects the user's mental model to system state.

Recovery versus regeneration

Full regeneration is a legitimate tool when assumptions changed materially. If the household adds a guest, changes allergy status, or rejects the whole planning frame, replanning may be correct. Regeneration as default correction policy is different. It optimises engineering convenience over user expectation. Persistence before regeneration states the policy default: patch first, regenerate only when scope demands it.

Recovery fails when accepted work is discarded silently. It fails when apologies replace diffs. It fails when checks are not re-run after patch. It fails when users cannot tell what the system believes changed. Each failure teaches users to re-verify entire outputs themselves, negating the point of cognitive assistance. The household stops editing and starts regenerating externally or abandoning the product.

Failed recovery also damages organisational trust. Support hears "I fixed one meal and lost the week" while engineering insists regeneration is easier to implement. That gap between user experience and engineering justification is exactly the kind of disconnect that erodes reliance on the whole category, not one product.

What this looks like in the Meal Companion

Critique identifies Wednesday as weak. RecommendMealSubstitution proposes a traybake swap. JudgeLocalRepairQuality assesses the patch. The deterministic shell applies a versioned plan update. The UI shows a diff: Wednesday moved from thirty-five minutes to twenty minutes active effort, other days unchanged. Shopping list updates only affected items. Allergy check re-runs.

The failure mode to avoid: the model silently rewrites the entire JSON plan, the user cannot tell what drifted, allergy check is skipped because prose still mentions cashew-free, and spinach timing is violated on Thursday without notice. Enterprise parallels follow the same shape. Invoice line correction does not re-extract the whole document without diff. Policy exception does not discard approved clauses unrelated to the dispute. Medical intake correction preserves verified demographics while revising the contested section.

Repeated recovery on the same weakness signals a missing cognitive unit, guard, or closing candidate, not more apology text. If Wednesday effort fails every busy week, the suite needs cases for that shape or the expertise guard is wrong. Recovery logs feed experience becomes expertise and suite extension. They are training data for architecture, not shame metrics to hide.

Recovery in architecture and operations

Cognitive posture lists recovery among conduct dimensions alongside restraint and memory discipline. Posture without recovery specification is incomplete. Conduct specs answer what is preserved on correction, what diff format appears, what checks re-run, and what happens when patch fails twice. Those answers are versioned when tools change.

When local patch fails twice on the same weakness, recovery conduct escalates visibly: offer replan with assumption review, ask targeted question, or defer if frontier expanded. Silent third regeneration repeats the brittle pattern users already fear. Patch failure logs feed evaluation the same way success logs do. A cognitive unit that cannot repair busy Wednesday under guard conditions needs suite cases, not a larger apology model. Shopping-list dependent checks deserve explicit mention in recovery specs, because users forgive meal change but do not forgive cart errors that waste money or time.

Auditors and security reviewers ask what happens when automation errs. Recovery architecture answers with versioning, audit trails, and deterministic re-checks. Apology-only policies do not satisfy scrutiny. Organisations that deploy meal planning, finance, or policy assistants at scale need recovery stories that match collaboration contracts, where "preserve governed work" is a common clause for good reason.

Recovery drills work the same way disaster recovery drills do. Injecting a bad plan, a wrong memory write, or a premature purchase proposal and verifying the product offers patch, undo, and explicit correction paths without full regeneration reveals gaps before users find them. Recovery metrics belong beside reliability metrics. Mean time to local repair and percent of accepted work preserved after correction predict retention better than first-session delight. Recovery specs name owner teams: product for diff UX, engineering for versioning, evaluation for recurring weakness suites. Shared ownership prevents recovery from living only in ops runbooks.

What to do next

The most common user correction in a product is the starting point. Drawing the current architecture path and highlighting where accepted work is destroyed reveals whether recovery is designed or accidental. Implementing preservation and diff before adding new generation features, adding a regression test that rejects one day and asserts other days unchanged, and logging patch failures separately from abstentions turns recovery from an ops afterthought into a trust asset.

See persistence before regeneration, point and fix, and trust across time.

Read next: Adaptability without unpredictability.