← Back to Concept Contrast

Concept Contrast Fable

Prompt management and prompt version management: one governs process, the other governs history

Conclusion first:When teams discuss prompt engineering, they often conflate management and version control—after all, both are about managing prompts. Management answers who can change it, who reviews it, and how it goes live; version control answers what a given version looks like, when it was changed, and whether it can be rolled back. The two share the same set of files, but they keep two different sets of books.

When teams discuss prompt engineering, they often conflate management and version control—after all, both are about managing prompts. Management answers who can change it, who reviews it, and how it goes live; version control answers what a given version looks like, when it was changed, and whether it can be rolled back. The two share the same set of files, but they keep two different sets of books.

Fable

The editorial department’s two ledgers

A newspaper's editorial department had to produce more than a dozen headlines and leads every day. In the early years, only one old editor managed everything. He kept a large notebook, writing today's headlines on the left and noting on the right who changed them and when. By the end of the month, he could always find a few headlines that differed from last week's but no one knew when they had changed.

After the newspaper expanded its pages, it hired four young editors, and the big notebook became a shared document. Four people edited the same headline area at once—you'd change half, I'd change it back—and the headline flipped back and forth five times in a single day. When the editor-in-chief wanted to review, he found the headline had been overwritten three times, and couldn't even find what was written at first review.

The editor-in-chief's office simply split the notebook into two. The first was called the assignment log, recording who drafted each version of a headline, who reviewed it, and who signed it off for publication, governing the process of a headline from idea to print. The second was called the revision record, recording only snapshots of successive changes to headline content, without caring who approved them.

The New Year's special issue had an incident once. The title of an editorial was changed at the last minute by the editor-in-chief before publication, but after making the change, the editor-in-chief forgot to notify the layout team. The layout team still used the previous version of the title. The next day, readers found that the print and digital versions had different titles, and complaints flooded the hotline. Checking the workflow log, the editor-in-chief's sign-off was on record; checking the revision history, the snapshot the layout team received was two hours earlier than the signed version.

In the postmortem, neither ledger was wrong—the job log recorded who approved which version, and the revision record faithfully stored the content of each version. The problem was that there was no linking mark between the two ledgers: no one recorded which revision snapshot the editor-in-chief's signature actually pointed to. The job log had a signature, but the signature did not match any revision timestamp.

The newspaper later added a line between the two systems: each time a sign-off occurred, the job log automatically recorded the corresponding revision snapshot number. From then on, when investigating a headline incident, they'd first check the job log to find the sign-off decision, then jump to the revision record to confirm which content was actually signed off. The two ledgers each kept their own records, but the threads were connected.

At the year-end review, the editor-in-chief wrote a line in the summary: the process governs people's actions and decision points, while the history governs the time series of content states. The two records can live in the same toolset, but don't expect one record to answer both who approved it and when the content became this way. The query directions of these two things are orthogonal.

Prompt management

A collaborative process around prompts: who drafts, who reviews, who publishes, and how to move from development to production. It governs a group of people's actions and decisions.

Prompt version management

Tracking changes to prompt content: snapshots, version numbers, timestamps and diffs for each edit. It manages the time series of content states.

Story Mapping

  • The job log records who drafted, who reviewed and who signed: prompt management governs the human collaboration process
  • Revision records store a snapshot of every content change: prompt version management, managing the time series of content
  • Two ledgers not linked, causing a title incident: a typical failure when management and version systems lack integration
  • Automatically record the revision snapshot number at signing: management actions and version snapshots are linked by identifier
  • When investigating an incident, check the operation log first, then jump to the revision history: troubleshooting approach—locate the process node first, then check the status

Applying it to an Agent project

Prompt management tools and version management tools can choose the same platform, but internally they must be split into two views. The management view answers: which version is currently running in production, who approved it, and when is the next review. The version view answers: what was the previous version's content, what changed and when, and which lines the diff is on. During evaluation or troubleshooting, first go through the management view to locate the decision chain, then switch to the version view to compare content differences.

京ICP备2026014272号