Keep a Prompt Version Log That Explains What Changed

Three prompt-version cards beside a pencil and laptop
AI-generated illustration; not evidence of a real document, venue, product test or result.

A folder full of prompts named final and final-new does not explain why one version works better. Keep a small version log beside a repeatable task. Each entry needs the input example, the changed instruction and the observed result.

Set up the example

Start with one fictional task, such as extracting owner and deadline from a meeting note. Save the first prompt exactly as used. Record its output and one concrete failure: perhaps a proposed date became a firm deadline. Do not replace the old result when you revise the instructions.

Change only the instruction responsible for the failure. Add “Keep proposed dates tentative” and rerun the same input. Include an ordinary example and a missing-date example so the fix is checked against more than one sentence.

Review before using the result

Write the result plainly: version two preserved the tentative date in these three examples. Avoid “100 percent accurate” unless that statement is explicitly restricted to the small checks you actually performed. Record product settings only when you can observe them; do not guess hidden model parameters.

When a new version fails an old example, keep that regression in the log. Choose a version based on the task's acceptance criteria rather than how polished the prose sounds. Retire redundant copies only after preserving the evidence needed to reproduce the decision. The log is a record of your workflow, not a universal performance benchmark.

Comments