Governance & Audit
Version Control for Prompts and Policies
· 10 minute read
The prompt is part of the decision rule. If you cannot say which prompt wrote Tuesday's rejection, you cannot reconstruct the file. Version it like a standing order.
On a Friday at 18:10 a vendor engineer, still on the war-room call, pasted a 'friendlier' system prompt into production because a collector had complained that the bot sounded stiff. The new text dropped the sentence that forced citation of a circular. Over the weekend the agent wrote three rejection drafts with invented paragraph numbers. On Monday the original prompt could not be found. The engineer had edited in the console. The console had no history the department owned.
A prompt is not a joke in a slack thread. For an agent that drafts official text, the prompt plus the policy plus the corpus manifest are the rule the machine used. Version them as you would a standing order: identity, diff, owner, time, rollback. Put the identity on every case packet. If you cannot, you are running folklore.
Guide for integrators and SDC leads. 16 August 2026. Not legal advice.
The controlled set
| Object | Version identity | Who signs a change |
|---|---|---|
| System prompt | Hash + monotonic ID | Workflow owner; second person if citizen-facing |
| Refusal policy / allow-list | Hash + ID | CIO + DPO for class upgrades |
| Corpus manifest | List of document IDs and hashes | Content owner |
| Decoding settings | Recorded in the same ticket | Workflow owner |
| Model weights | [Card + file hash](/blog/model-cards-for-government-deployments) | CAB as for any production binary |
| Tool schemas | ICD version | Integrator + application owner |
Hot-edit consoles are a finding. If the product cannot load a prompt except from the controlled store, good. If it can, turn that path off in production and prove it with a failed-edit test.
Diffs people can read
A hash without a human-readable diff is a lock without a window. The change ticket should show the sentences added and removed in language a section officer can understand: 'removed the duty to quote a circular; added a friendlier greeting'. The DPO is looking for purpose drift. The auditor is looking for the Tuesday version. Both need the window.
Rollback is a named previous ID, tested once in staging, not a hope that someone remembers the old paste. Friday's edit should be reversible on Saturday without the vendor.
Packets carry the ID
The reconstructable packet from the CAG article must name prompt ID, policy ID, corpus manifest ID and model hash. RTI about 'what rule did the machine apply to me in June' is otherwise unanswerable. Logs without version IDs are diaries of moods.
Two Fridays
Objections
Engineers say this is ceremony. Answer: so is a noting sheet. The prompt is a noting sheet that runs at machine speed.
The vendor says their console is audited. Answer: show the export the department will still have when the tenant dies. If they cannot, it is not our audit.
A scientist wants to A/B test live on citizens. Answer: not on rights or money. Staging and a dated eval pack. Live A/B on a widow is an experiment without ethics.
Leadership wants faster tweaks before a launch. Answer: freeze. Launch on a tagged ID. Tweak next week.
A four-week playbook
- Week 1: inventory live prompts and policies. If they live only in a console, copy them out under an owner.
- Week 2: turn off production hot-edit. Prove the failed-edit test.
- Week 3: put version IDs into the action log and the case packet.
- Week 4: rehearse a rollback and a 'what rule in June' export for the PIO.
File note you can paste
Subject: Version control of prompts, refusal policies and corpus manifests.
These objects are controlled documents. Production shall load them only from the departmental store. Each change requires a ticket, a readable diff, an owner, and, for citizen-facing or money-class workflows, a second signature. Case packets will record the IDs in force. Hot-edit consoles are prohibited in production.
Retention of historical versions will follow the reconstructability need of the decisions they influenced, not only the CERT-In 180-day floor. This note is not legal advice.
What a CAB ticket must contain before production moves
Identity of the object (prompt, policy, corpus manifest, decoding, tool schema). The readable diff in one screen. The eval subset you re-ran, with the one failure you still accept. The rollback ID, tested. The register row it attaches to. The second signature if the class is citizen-facing or money. Without those, the ticket is a chat message with a number.
Integrators should deny themselves console write in production the way they deny themselves SSH as root on a treasury box. If the product cannot operate that way, the product is not a government runtime. It is a demo that happens to have a purchase order.
Keep a monthly 'what changed' folio for the DPO and IA: IDs promoted, IDs rolled back, eval deltas. That folio is how you notice that friendlier tone deleted a citation duty. It is also how you answer the PIO who asks what rule applied in June without archaeology.
Air-gapped sites version on media the same way they version weights. A prompt that travelled on a stick needs a hash on the manifest. Otherwise the coastal district is running 0.17 while HQ believes 0.19, and both will swear they are in production.
- Tag releases; do not rely on 'latest'.
- Forbid live A/B on rights or money.
- If two officers can edit the same production prompt, you do not have version control. You have a wiki.
Informational field guidance. Confirm record-retention schedules and your change-advisory rules before you freeze a store.
How this survives CAG, RTI or the Board
“Version Control for Prompts and Policies” is not a workshop slide. A P4 System Integrator will have to reconstruct a decision after the officer who clicked approve has been transferred. Write the artefact that lets a stranger replay the case: the log fields, the approval, the override, the register row.
The prompt is part of the decision rule. If you cannot say which prompt wrote Tuesday's rejection, you cannot reconstruct the file. Version it like a standing order. India AI Governance Guidelines (November 2025) are guidelines, not a statute. DPDP still allocates fiduciary duty. Delegation of Financial Powers still allocates who may spend. Do not hide those instruments behind the word governance.
If you cannot show who acted, on which purpose, with which data class, and who could have refused, you do not have accountability. You have a chatbot with a charter PDF.
- Name the owner of “prompt version control” inside the department, not the vendor.
- Keep CERT-In-relevant logs in India for the required period.
- Store overrides with a reason an auditor can read.
- Put the workflow on the AI register before it touches a citizen.
Close this loop before the next CAB
Put “Version Control for Prompts and Policies” on the next change-advisory or bid-opening agenda as a single line item with an owner. If it cannot earn a line item, it will not earn a control. The owner should be a P4 System Integrator, not “the vendor.”
Revisit the item when the model, the GeM term, the region, or the SI changes. “prompt version control” is not a one-time workshop. It is a watch item. Date the last check. Unsigned watch items are souvenirs.
What the next noting must contain
“Version Control for Prompts and Policies” belongs in a file, not only in a search result. A P4 System Integrator should be able to point at one artefact that proves “prompt version control”: a packet capture, a processing schedule, a scored evaluation row, a dated notice, or a refusal rule. If the only evidence is a slide, you have a heading.
The prompt is part of the decision rule. If you cannot say which prompt wrote Tuesday's rejection, you cannot reconstruct the file. Version it like a standing order. DPDP 2023 does not define sovereign AI and does not write a blanket localisation rule for every model hop. CERT-In’s 28 April 2022 directions still set specified incident clocks and 180-day log retention in India for in-scope events. The November 2025 AI governance text is guidance, not a statute. A Proprietary Article Certificate, when it is lawful, lives in GFR Rule 166 — not Rule 161.
Write three dated sentences under C6 Governance & Audit: what was decided, which designation owns it after the next posting order, and when it will be re-checked. Unsigned sentences are souvenirs. Dated sentences are controls.
- Name the designation that owns “prompt version control”, plus a deputy.
- Attach one artefact a stranger can open next year.
- Name the instrument you are actually using — Act, direction, GFR clause, GeM term, or guideline paragraph.
- Leave unsourced percentages, GMV slides and house forecasts out of the noting.
- Revisit when the model, the SI, the notice, the region or the posting changes.
Questions this usually raises
- Is a Git repo enough?
- A repo with reviews, signed tags, and a production pointer is a good engine. It is not enough if officers cannot name the production hash, if anyone can hot-edit the live prompt, or if the case packet does not record the version.
- What counts as a versioned object?
- System prompts, tool allow-lists, refusal policies, retrieval corpus manifests, and temperature or decoding settings that change behaviour. Weights have their own hash on the model card. Do not version only the chat text.
- Who may change a production prompt?
- A named owner on the register, through a change ticket, with a second person for citizen-facing or money-class workflows. Not a vendor engineer on a Friday because a demo went badly.
- How long do old prompts need to live?
- At least as long as the decisions they influenced must remain reconstructable, subject to purpose limitation and the record schedule. A 180-day CERT-In floor is not long enough for a speaking order you must defend for years.