diff --git a/ops/backend-release-dispatch.md b/ops/backend-release-dispatch.md
index aeb700fa..3f57538f 100644
--- a/ops/backend-release-dispatch.md
+++ b/ops/backend-release-dispatch.md
@@ -105,6 +105,7 @@ The frontend workflow that receives this event is:
 
 - `summary`
 - `metadata.previous_deploy_image` - backend Jenkins resolves the image behind the registry `latest-prod`/`prod` pointer before the new deploy
+- When the registry pointer is missing or no canonical digest match exists, backend deployment must stop or require explicit bootstrap approval.
 - `metadata.pull_request_number`
 - `metadata.pull_request_labels`
 
diff --git a/ops/release-record-shared-contract.md b/ops/release-record-shared-contract.md
index 4ce73efc..e15a4010 100644
--- a/ops/release-record-shared-contract.md
+++ b/ops/release-record-shared-contract.md
@@ -2,6 +2,8 @@
 
 This is the shared production release-record contract between `study-platform-mvp` backend and `study-platform-client` frontend.
 
+Direct pushes to `main` without a PR and its `release:major|minor|patch` label are not valid production release inputs.
+
 It fixes two schemas:
 
 1. the backend-to-frontend release payload schema, and
@@ -132,6 +134,7 @@ The frontend script also accepts the inner `client_payload` object directly when
 
 - `summary`
 - `metadata.previous_deploy_image` - backend Jenkins resolves the image behind the registry `latest-prod`/`prod` pointer before the new deploy
+- The release record is still the audit trail; the registry pointer only helps backend Jenkins recover the previous immutable backend image before dispatch.
 - `metadata.pull_request_number`
 - `metadata.pull_request_labels`
 
diff --git a/ops/version-management.md b/ops/version-management.md
index 7e02bc72..02c43bef 100644
--- a/ops/version-management.md
+++ b/ops/version-management.md
@@ -4,6 +4,8 @@ This document is the frontend repository source of truth for ZERO-ONE production
 
 This document follows the shared FE/BE contract in `ops/release-record-shared-contract.md`.
 
+- Do not direct-push commits to `main` or bypass the PR path. Production deploy/release recording depends on the PR and its `release:major|minor|patch` label.
+
 ## Responsibility
 
 - `study-platform-client` owns the final production release record because it is the user-facing application and the running product depends on a compatible frontend/backend/database combination.