Point and fix

Tuesday's stir-fry is too long for a busy evening. The household does not want to rebuild the entire week. They tap Tuesday's meal and say: "too much active time, something under twenty minutes."

That is point and fix. Selection plus utterance, aimed at one weakness. The product invokes something like RecommendMealSubstitution, proposes a local repair, preserves accepted meals on other days, and shows a diff before apply. If the system regenerates all seven dinners because one slot failed, it punished correction. The household learns that editing is expensive and stops trusting the draft.

Helpful context: Low-cognitive first draft supplies work worth preserving. Persistence before regeneration is the posture requirement underneath. Recommend, don't only respond names the proactive repair move.

Patches, not wholesale regeneration

Pointing becomes a command language beyond text. A meal on a plan. A clause in a contract. A chart region. A step in a workflow. The system returns a targeted change, and untouched work stays untouched. Patches are reviewable, revertible, and cheap to verify. Local repair takes precedence over a new document. Diff appears before applying so content outside the selection remains unchanged. The neighbourhood around the selection travels with the request so the repair fits context. Provenance marks changes from the system so they can be reviewed as a set and undone cheaply. When every change carries provenance, the household can distinguish between their own edits and system-proposed repairs at a glance. That visibility lowers the cost of review and raises confidence that accepted work was not altered behind the scenes.

Full regeneration became the default because it is easier to build: one prompt, one response, no diff engine, no provenance. That path trains users to accept wholesale replacement and erodes trust in drafts. Point and fix requires working state, patch objects, and evaluation of local repair quality. The engineering cost buys retention. Households who can fix Tuesday without losing Thursday stay for week three. Retention data from products that support local correction consistently shows that the first successful patch predicts long-term engagement more reliably than the quality of the initial draft.

Increasingly, users expect to simply point at something and describe what should change.

Thoughtware: Designing in the Intelligence Age · Ch. 6

Without decision locality underneath, surgical edit becomes theatre. The product looks editable while rewriting more than the person asked for. Selection capture, patch generation, diff before apply, and provenance for undo form the minimum viable correction experience.

A full correction beat in the Meal Companion

The household accepts Monday through Sunday except Tuesday. They tap Tuesday's stir-fry. The product shows forty-five minutes active time against a twenty-five minute busy rule. They say "too long." RecommendMealSubstitution returns quick pasta with twenty minutes active time. The diff shows Tuesday changed, other days unchanged. They apply. Working state version increments. Shopping list updates for Tuesday ingredients only.

That beat requires ComposeWeek to hold accepted meals, AssessMealPracticality to flag the weakness, and deterministic code to apply the patch transactionally. UX without that architecture looks like point and fix while behaving like regenerate.

Selection affordances make the weakness obvious: highlight the meal, clause, or chart region. Repair utterance accepts domain language: "too long," "swap protein," "soften tone." Diff appears before apply by default. Undo reverts the patch set, not requiring manual reconstruction. Products that apply patches silently train households to distrust drafts. Products that show diff but hide provenance make contest harder than it needs to be.

Neighbourhood context matters for substitutions. RecommendMealSubstitution needs accepted plan, day constraints, pantry hints, and allergy rules in the neighbourhood around Tuesday. Patch without neighbourhood produces a valid single meal that breaks week coherence.

Beyond meal planning

Contract redlines, schedule adjustments, and dashboard corrections follow the same pattern. Selection names the weakness. Utterance names the repair. The system returns a patch with scope confirmation. Lawyers select a clause, say "soften indemnity," and receive a patch against the accepted document. Operations teams point at schedule blocks. Finance teams point at forecast lines. The grammar stays constant: selection, utterance, patch, diff, apply.

Products that offer only "regenerate" or "start over" force users back into high-cognitive invention. Point and fix keeps the person in review mode, which is where Intelligence Age effort already lives.

Tooling investments in diff engines and provenance pay across domains once locality is real. Teams that share patch infrastructure across features ship correction faster than teams that rebuild regenerate per surface. Regression tests include untouched-content assertions for every patch type the product claims to support.

Measuring patch fidelity

Tracking how often a local correction triggers full regeneration produces a point-and-fix score. That ratio reveals whether locality is real or theatrical. Bytes or fields changed versus fields requested shows repair precision. Undo rate after apply reveals substitution quality: high undo may mean poor neighbourhood context or overconfident substitution.

JudgeLocalRepairQuality grades whether the substitution respects busy rules, allergies, and neighbourhood fit. Offline eval includes held-out Tuesday-too-long cases. Online metrics track patch acceptance and undo rate. Full-plan fluency benchmarks miss the correction path households use most after week one.

Patch latency also matters as a UX metric. Time from utterance to visible diff predicts correction satisfaction. Slow patch feels like regeneration. Fast diff feels like collaboration. Products that return a visible diff within two seconds of the correction utterance preserve the feeling of a live conversation rather than a batch job.

Provenance and undo as trust mechanics

Patches arrive as a named set: apply all, undo all, review each. Provenance marks which changes came from RecommendMealSubstitution versus manual edit. When something goes wrong, the household rolls back one patch set instead of rebuilding the week.

Undo cheaply is part of recovery is part of trust. Point and fix without undo is edit theatre. The household applies Tuesday's patch, notices a shopping list conflict, undoes the patch set. Undo restores prior plan version and list. Point and fix without versioned undo forces manual recovery and feels expensive.

Keyboard and screen reader paths to select Tuesday's meal must exist. Point and fix cannot be pointer-only and remain inclusive. Mobile selection, whether tap, long-press, or explicit edit handle, makes selection obvious. Hidden selection forces descriptive utterance only, and selection plus utterance beats utterance alone for low-cognitive correction.

The common failures cluster around provenance and scope. Surgical edit theatre looks editable while rewriting more than asked. Missing provenance makes undo expensive. Scope confusion replaces one day and accidentally changes shopping lists for the whole week. These failures erode trust because the household cannot verify the boundary of what changed. The deeper failure is treating point and fix as a UI pattern without the architecture to support it. Selection capture without working state, patch generation without diff engine, and visual polish without provenance produce a product that looks correctable and behaves like regenerate. The retention cost arrives on week two, when the household's first local correction erases accepted work the product promised to preserve.

What to do next

The correction path households use most after week one is the path that determines retention. Measuring how often a small correction triggers full regeneration reveals the point-and-fix score for any artifact, and that score connects directly to the intent-capture question: intent over instructions describes how the originating sentence compiles without a feature map, and point and fix ensures that subsequent corrections stay in the same domain language.

See recovery is part of trust and persistence before regeneration.

Read next: Intent over instructions.