Edit-Preservation: Apply Only the Requested Change

You spend ten minutes generating a 12-shot list. Three shots land — they're close to what you wanted. You ask the LLM to "improve the framing on shot 4." It rewrites the entire shot list. The two good shots are gone, replaced with slight variations that miss what made the originals work. The choice is now between the partial improvement on shot 4 and the loss of two approved shots. You revert and lose the improvement entirely. The iteration loop costs more than the original generation.

The way out is to instruct the LLM, in the strongest possible terms, to apply only the requested change and preserve the rest verbatim. Editing becomes surgical instead of full-replace.

This is the edit-preservation pattern: a prompt architecture for iterative LLM refinement where the system prompt's primary instruction is "apply only the requested change; preserve everything else verbatim." The baseline exists (a shot list, a prompt, a document); the edit is surgical. The economics flip — refinement becomes cheaper than re-generation, and iteration replaces commit-early-and-pray.

The shape

Inputs to the editing LLM:
  1. The existing artifact (current prompt, current shot list, current document)
  2. The user's edit instruction (free-form natural language)

System prompt (core):
  "Apply ONLY the requested change. Preserve all other fields, phrasing,
   structure, and formatting verbatim. Do not rewrite what was not asked
   to be changed."

Output:
  The edited artifact in the same format as the input.

Why it's a distinct architecture, not just "editing"

Ask an LLM to "improve this prompt" and it rewrites the whole thing — because rewriting feels like the productive default. The pattern explicitly reverses that default.

Three specific properties:

1. The baseline is the authority. The existing artifact is not a suggestion to be improved; it's the source of truth for everything the user didn't mention.
2. Change scope is bounded by the instruction. "Add a close-up before scene 2" changes exactly one thing. Not "and while I'm at it, tighten scene 1's framing."
3. Format is preserved. A JSON shot list in must come out as the same JSON shot list with the same keys and ordering. A prompt paragraph in must come out as a paragraph with unchanged sentence structure where unchanged.

Why it's valuable

• Refinement becomes economically viable. When the baseline doesn't have to be re-generated, the LLM call is small and fast. A full-rewrite approach costs as much as the original generation; refine costs a fraction. Cheap refinement changes user behavior — iteration becomes the default mode.
• Output stability. Users edit prompts because they got close to what they wanted. A full rewrite throws away the close-to-correct parts. Edit-preservation keeps them.
• Diffable iteration. The output can be meaningfully diffed against the input — the change is small and visible, not a complete rewrite.

Where it shows up

| Artifact edited | Instruction example | Output discipline | |---|---|---| | Shot list | "Add a close-up of the product box before scene 2" | Re-index only the affected letters; preserve all other shots verbatim | | Storyboard prompt | "Make this a wider shot" | Change framing; preserve style prefix, subject, location | | Image prompt | "Emphasize the subject's expression" | Change the relevant clause; preserve everything else | | Video prompt | "Less camera movement — hold static" | Swap motion descriptor; preserve pacing and subject-action language |

The brief-to-scenario-pipeline uses this pattern at the shot-list level — the third stage in that cascade (edit scenario) is edit-preservation applied to an entire structured artifact.

Failure modes

• Instruction under-specification. "Make it better" gives the LLM no basis for preservation — it rewrites. Counter: reject vague instructions at UI time, or prompt the user to specify.
• Scope creep in the output. LLM "fixes" unrelated things it thinks are mistakes. Counter: include an explicit anti-example in the system prompt — "DO NOT change phrasing of fields unrelated to the edit. Leave typos and awkwardness alone unless asked."
• Format drift. Output JSON fields reordered, prompt paragraph reflowed. Counter: instruct explicit format preservation and validate against the input schema after.
• Silent loss of content. The LLM drops a field it "thought" was redundant. Counter: treat any field-count mismatch as an error and retry.

Generalises broadly

• Code editing. The canonical surgical-diff pattern: "rename this variable, don't touch anything else."
• Document editing. Track-changes style: apply this edit, leave the rest of the document alone.
• Config / schema editing. Add this field, preserve all comments, ordering, formatting.
• Prompt-on-prompt iteration. The pattern is used recursively — refining prompts that produce prompts.

Economic property worth naming

Edit-preservation makes single-shot refinement cheaper than batch re-generation. Combined with an interface that exposes single-shot editing as a first-class button, it changes the user's default behavior: iteration replaces commit-early-and-pray. A small architectural choice with large UX consequences.