You Version the Model Weights. The Prompt Still Lives in a Wiki.

The model promotion checklist is tight. Weights are hashed. Containers are signed. Staging looks like production. Then someone pastes a "quick prompt tweak" from a Confluence page that last changed during a Friday firefight, and that is what customers actually hear.

That split is everywhere in Australian enterprise AI programmes. Model artefacts get change control. Prompts, system messages, tool instructions, and few-shot packs often live in a wiki, a shared drive, or a Slack bookmark. The runtime treats them as code. The organisation still treats them as notes.

The prompt is production behaviour

A system prompt is not decoration. It sets tone, refusal rules, escalation paths, citation habits, and which tools the model is allowed to consider. Change one paragraph and you can change who gets refunded, what gets disclosed, or whether a claims note sounds authoritative when it should sound provisional.

Yet the artefact that encodes that behaviour rarely sits next to the model version. Teams will refuse to "hot swap" a checkpoint without a ticket. The same teams will hot swap the instructions that steer the checkpoint because editing a wiki feels harmless.

If your release notes list the model ID and omit the prompt hash, you are only versioning half the product.

If you cannot roll the prompt back to last Tuesday in one click, you do not have prompt management. You have folklore with formatting.

Where the wiki habit breaks

Loose prompt storage fails in quiet, expensive ways:

• Silent drift between environments when staging still points at an older page revision
• Unreviewed tone changes that land in production because "it was just copy"
• Missing ownership when legal, risk, and product each assume someone else approved the wording
• Broken evals because the golden set was scored against a prompt that no longer exists
• Incident blindness when nobody can say which instruction pack was live at 14:03

Model registries will not save you here. The model can be perfect and still ship the wrong behaviour if the instruction layer is unmanaged.

A pattern we keep seeing

Picture a Melbourne insurer with a claims assistant. The foundation model sits behind a proper promotion gate. The system prompt lives in a Notion page titled "Final (use this)". Three teams edit it. One rewrite softens the escalation language during a spike. Customer complaints rise. The model version on the dashboard never moved. The wiki history shows the change, but ops was watching the wrong artefact.

Or take a bank ops agent whose tool-use instructions were pasted into a GitHub wiki during a pilot. Six months later, engineering versions the container carefully. The wiki page still has an old tool name that no longer exists, plus a new paragraph nobody reviewed that encourages the model to "be helpful and complete the request". The agent starts improvising around missing tools. The incident ticket blames the model. The prompt page was the real release.

Neither case is a research problem. Both are release engineering problems wearing a chat UI.

Treat prompts like packaged config

Give the instruction layer the same seriousness you give model weights.

• Store prompts as versioned artefacts. Prefer a repo, registry, or config service with immutable versions, not a page that mutates in place.
• Hash what runs. Log model ID, prompt version, tool schema version, and retrieval pack version on every production turn.
• Promote as a bundle. Staging and production should receive a known combination of model plus prompt plus tools, not mix-and-match leftovers.
• Review the words. Risk and product sign off on instruction changes that affect customers, money, or regulated advice, the same way they review UI copy that does.
• Bind evals to prompt versions. A golden set without a pinned prompt is a story about a moment that no longer exists.
• Make rollback boring. Reverting a bad prompt should be as dull as reverting a bad feature flag.

If your MLOps board only shows model cards and deployment status, add a second column for instruction packs. Make it mandatory, not optional hygiene.

What to do before the next release

Before you promote the next assistant:

1. List every prompt, system message, and tool-instruction block that can reach production today.
2. Move each into a versioned store with an owner and a review path.
3. Pin the live version in config and write that pin into your traces.
4. Re-run your core eval suite against the exact prompt version you plan to ship.
5. Agree who can change a prompt in an incident, and how that change is recorded.

Model versioning still matters. It is just not the whole release. Customers experience the prompt. If that still lives in a wiki, your change control is theatre around the wrong file.