How to Revise One Section of an AI Answer Without Changing Approved Text

An AI assistant can handle the first draft of a support summary, checklist, or internal memo well. The next request is often harder: “Change the last part, but leave everything already approved alone.” A broad rewrite prompt can improve the requested section while quietly changing a number, weakening a fact, renaming a heading, or adding a promise.

This guide introduces a scoped revision contract. It identifies the exact part that may change, treats everything else as immutable, and checks the finished output against the approved version. You will work with three fictional support-note bullets, a copyable follow-up prompt, a reference output, and a small Python guard. The example is an editorial fixture, not a report of a live AI-model experiment.

When a normal rewrite prompt is too broad

“Make this better” gives the assistant permission to reconsider the whole answer. That may be useful when the entire response is a draft. It is inappropriate when a reviewer has already approved factual statements, labels, or legally sensitive wording.

Imagine a team that approved the first two bullets of a support case and only wants the third bullet rewritten as questions. A useful result must satisfy both goals: improve the selected bullet and preserve the protected bullets exactly. A more elegant paraphrase of the first bullet is still a failure.

The distinction is between semantic preservation (roughly the same meaning) and exact preservation (identical text). If names, citations, numbers, or approved language matter, ask for exact preservation and verify it with a text comparison.

Step 1: Mark the text that is frozen

Our fictional source note reads:

A customer cannot open the report download link.
They have tried twice. The note does not provide
an error code or a browser version. No repair,
refund, or delivery promise has been confirmed.

The already approved three-bullet answer is:

- Problem: The customer cannot open the report download link.
- Confirmed facts: They tried twice; the note provides no error code or browser version.
- Missing details: Error code and browser version were not provided.

A reviewer now wants only the Missing details bullet changed into two questions. The first two lines are frozen. They may not be shortened, rephrased, reordered, or corrected opportunistically. Even replacing “cannot” with “can’t” would violate exact preservation.

Before prompting, save this approved version in a durable location. It becomes the comparison baseline. Do not rely on the assistant’s memory of a previous answer if you have an exact copy available.

Step 2: Write a four-part revision contract

A scoped revision prompt needs more than “only change bullet three.” Make four constraints visible.

1. Editable scope: Name the specific line, field, heading, or paragraph that may change.
2. Frozen scope: Name what must remain byte-for-byte or character-for-character identical. For ordinary text review, say “character-for-character” unless you truly need to check encoded file bytes.
3. Target behavior: Describe what a successful replacement contains and what it must not assert.
4. Output boundary: State whether to return the whole revised artifact or only a replacement fragment, and disallow extra commentary.

For this example, returning the complete answer is useful because a person can copy it directly. In a document editor with a reliable patch operation, generating only the replacement text may be safer: unchanged sections can be retained by software instead of regenerated by a model.

Step 3: Copy this targeted follow-up prompt

Use the following with the approved answer pasted in full, not a paraphrase of it.

Task: Revise only the third bullet of APPROVED ANSWER.

Allowed edit:
- Replace the text after "- Missing details: " with
  exactly two questions.
- Question 1 must ask for the error code.
- Question 2 must ask for the browser and version.

Frozen content:
- Keep the "- Problem: " bullet exactly unchanged.
- Keep the "- Confirmed facts: " bullet exactly unchanged.
- Preserve all three labels, their order, and their
  punctuation character-for-character.
- Do not add or remove bullets.

Evidence limits:
- Use only facts from SOURCE NOTE and APPROVED ANSWER.
- Do not imply the download was repaired.
- Do not invent a refund, ETA, fix, or diagnosis.

Output:
- Return the complete revised three-bullet answer.
- One bullet per line; no heading or commentary.
- If the requested edit conflicts with the facts,
  explain the conflict instead of changing frozen text.

SOURCE NOTE:
[PASTE THE ORIGINAL SOURCE NOTE]

APPROVED ANSWER:
[PASTE THE THREE APPROVED BULLETS]

The explicit exception for an impossible request is deliberate. A forced, plausible-looking edit should not override a contradictory source. For a production workflow, choose a separate error channel rather than mixing a refusal into a file that requires exactly three lines.

Step 4: Compare with the expected answer

For the fictional note, this is a valid human-authored reference output:

- Problem: The customer cannot open the report download link.
- Confirmed facts: They tried twice; the note provides no error code or browser version.
- Missing details: What error code appears? Which browser and version are you using?

Notice what did not change. The first line still says only that the link cannot be opened. The second still reports two attempts and missing technical details. The third asks for information without claiming it was supplied or that the issue is fixed.

This is the target against which you would evaluate model output. It is not a claimed screenshot, an observed ChatGPT answer, or evidence that every model will obey the instructions. OpenAI’s prompt engineering guidance describes clear boundaries, examples, and model variability; it does not promise that ordinary prompt wording guarantees exact copying.

Step 5: Verify invariants separately from the edited content

A successful answer has two types of checks. Invariants are conditions that must not change. Requested edits are the new conditions that must be satisfied.

Check structural and exact-text conditions with software where practical. Review factual meaning manually against the source. A program that sees two question marks cannot prove the questions are sensible; a model saying “I kept it unchanged” cannot prove text identity.

Step 6: Run this local Python preservation check

For a repeatable check, store the approved and revised text as Python strings and run this script locally with Python 3. It uses only the standard library and does not upload the note anywhere.

approved = (
    "- Problem: The customer cannot open the report download link.\n"
    "- Confirmed facts: They tried twice; the note provides no error code or browser version.\n"
    "- Missing details: Error code and browser version were not provided."
)
revised = (
    "- Problem: The customer cannot open the report download link.\n"
    "- Confirmed facts: They tried twice; the note provides no error code or browser version.\n"
    "- Missing details: What error code appears? Which browser and version are you using?"
)

def assert_scoped_edit(old, new):
    a, b = old.splitlines(), new.splitlines()
    prefixes = ("- Problem: ", "- Confirmed facts: ", "- Missing details: ")
    assert len(a) == len(b) == 3, "Expected exactly three lines"
    assert all(line.startswith(prefix) for line, prefix in zip(b, prefixes)), "Wrong labels or order"
    assert a[:2] == b[:2], "Approved lines were modified"
    assert b[2].count("?") == 2, "Expected two questions"
    print("PASS: original two lines preserved; two questions present")

assert_scoped_edit(approved, revised)

Executed editorial check: Using Python 3, this exact fixture printed PASS: original two lines preserved; two questions present. When “tried twice” in the revised text was deliberately changed to “tried three times,” the comparison raised AssertionError: Approved lines were modified. That is a test of the checker and reference strings, not a test of an AI model.

The script checks line count, labels, frozen content, and question-mark count. It does not check whether the new questions are relevant, whether the original approved bullets are factually correct, or whether a browser/version answer is obtainable. Those require human review. For exact file-level validation, also consider newline style, Unicode normalization, and whitespace handling; splitlines() intentionally abstracts away line separators.

Step 7: Handle conflicts without silently rewriting approved text

Suppose the new request says, “Change the Missing details bullet to say the download works now.” The original source has no confirmation of a fix. A responsible assistant should flag the contradiction rather than slipping a false claim into an approved record.

There are three legitimate next actions depending on the workflow: request a new evidence source, ask a reviewer to authorize revising the frozen facts, or leave the requested change unresolved. None permits an unsupported repair claim.

Likewise, suppose the protected text itself contains an error discovered later. Treat that as a separate change request. First obtain approval to unlock the inaccurate line, then update the baseline and record the revision. “Frozen” is a workflow state, not a declaration that old text is eternally correct.

Step 8: Choose between full-response and patch-only generation

In chat, returning all three bullets can be the most convenient option. But it forces the model to reproduce unchanged content. That creates an avoidable opportunity for drift.

For a repeatable application, consider a patch-only response: ask the model for exactly the replacement content of Missing details, validate the replacement, and let your software attach it to the two existing immutable lines. In that design, the model never gets the chance to rewrite frozen lines. The application still must check evidence and formatting.

A minimal patch-only prompt would say: “Return only the text that follows the third bullet label; write two questions about the error code and browser/version; use no other content.” Your application then combines that text with the approved labels and lines. Use this only when you control how the final artifact is assembled.

Step 9: Test four failure-oriented cases

One happy-path output is not enough. Run the same revision contract against a small set of cases you understand in advance:

1. Ordinary input: Both technical details are absent. Expect two questions and unchanged frozen lines.
2. Partially specified input: An error code is already given, but browser information is missing. A rigid “ask for the error code” template is now inappropriate; review or revise the task rather than ask for known information.
3. Contradictory request: A reviewer asks to declare a fix that the note does not confirm. Expect a conflict or escalation, never an invented repair.
4. Formatting pressure: The request also says to “make everything friendlier.” Expect the scoped editing rules to win over broad stylistic rewriting.

For each run, keep the full prompt, exact input, raw response, model or product identifier when available, settings, and review decision. Repeat representative cases because generation can vary. The OpenAI evaluation best-practices guide discusses task-specific tests and combining machine checks with human judgment.

Frequent mistakes to avoid

Using “keep the rest basically the same.” This asks for semantic similarity, not exact text. Say which lines are frozen and check them after generation.

Asking for the full rewrite when only a patch is needed. If you control a document system, prefer to replace the smallest approved span. There is less to compare and less opportunity for accidental changes.

Relying on the model to certify its own accuracy. “No changes were made” is an assertion, not a diff. Compare text directly and trace each substantive claim to the underlying source.

Letting a revised question introduce an answer. “Which error code E42 did you see?” invents E42 if the code was not provided. The question should request unknown information without suggesting unsupported specifics.

Ignoring approval boundaries. A new request can be inconsistent with previously approved wording. Escalate it rather than silently expanding what the editor is permitted to change.

A practical acceptance checklist

• The latest approved original is stored separately.
• The editable span is identified exactly.
• Unchanged spans match the baseline character-for-character.
• Number, labels, and order of output items match the contract.
• The replacement satisfies the new requirement.
• Every factual assertion is supported by the source note.
• Any conflict is recorded for review, not resolved by guessing.
• Automated checks and human checks are documented separately.

This workflow is especially useful for regulated wording, approved customer replies, internal knowledge-base edits, and repeated structured reports. It is not a security boundary or an authorization system: model instructions alone cannot prevent unauthorized changes to external files. Keep access controls, approval history, and final verification in the surrounding workflow.

Sources and limits

• OpenAI: Prompt engineering — using precise instructions, content boundaries, examples, and prompt tests.
• OpenAI: Evaluation best practices — task-specific quality checks and human review.
• Python documentation: str.splitlines — behavior of the line-splitting method used in the local check.

Verification scope: The guide’s source notes and reference answer are fictional and editorially authored. The short Python comparison was executed locally on those strings, including one deliberately failing mutation. No AI-model revision run, cross-model reliability test, real customer support resolution, or production deployment is claimed.