A courts clerk assistant may only run prompts that auditors can prove were approved. What Git practice supports that?

Requiring signed-off Git tags on prompt releases used in production gives a courts clerk assistant an auditable, immutable pointer to the exact prompt bundle auditors can prove was approved. Tags (ideally signed) bind a release identity to a commit SHA, reviewer attestations, and often a change ticket. Production Foundry then deploys from tagged releases only, so clerks and auditors can answer which prompt ran on a given date without reconstructing portal history or laptop checkouts.

Using unsigned Git tags that anyone with repo write access can create or move fails because a movable, unsigned tag cannot prove which specific reviewer-approved commit auditors are looking at, which is exactly what the courts' proof-of-approval requirement needs. Letting production pull whatever commit happens to be on a personal laptop fails integrity and reproducibility; personal branches are not controlled releases. Deploying from the latest commit on main without creating a release tag at all fails because a floating branch tip keeps changing, so there is no fixed, approved release identifier auditors can point to for a given production date.

Exam caveat: Signed tags prove which artifact was approved; they do not by themselves prove the live Foundry resource still matches that tag—runtime configuration drift checks remain required. Also align tagging with judicial or court IT change-management policies for systems that touch case-adjacent text.

Operational check: Verify production deploys reference a signed tag, not a floating branch tip; store tag verification in the release record; periodically hash-compare live prompt text to the tagged files; restrict who can create release tags; and include tag IDs in audit evidence packages for clerk-assistant reviews.