Enforce signed backup evidence before migrations

docs/INSTALLATION_AND_DEPLOYMENT_ARCHITECTURE.md

@@ -97,6 +97,9 @@ The private installation directory contains:
 | `receipt.json` | Last successfully applied immutable identities |
 | `distribution-manifest.json` | Canonical signed runtime/image selection adopted by the installer |
 | `distribution-keyring.json` | Explicitly installed public trust anchor for runtime releases |
+| `backup-evidence.json` | Signed provider-neutral coordinated backup and isolated-restore receipt |
+| `backup-keyring.json` | Explicit public trust anchor for backup evidence authorities |
+| `backup-verification.json` | Sanitized local verification/adoption receipt |
 | `applied-state/` | Checksum-verified snapshot of the last healthy deployment bundle |
 | `operations/<id>/` | Private hash-chained deployment progress and recovery evidence |
 | `kubernetes.json` | Optional stateless multi-host Kubernetes export |
@@ -369,10 +372,12 @@ starts, recovery is forward-only unless an independently verified database
 backup is restored. See
 [Recovery And Rollback Guarantees](RECOVERY_AND_ROLLBACK_GUARANTEES.md).
 
-Production updates still need an operator-provided database backup/restore
-gate, database compatibility declaration, image signature verification, and
-deployment-specific drain policy. The deployment journal proves its own
-actions; it does not manufacture backup evidence.
+Production updates still need operator/provider-created coordinated backup and
+restore evidence, a database compatibility declaration, and a
+deployment-specific drain policy. The deployer now verifies and enforces the
+signed evidence before migration, but does not manufacture backups or receive
+provider administration credentials. See
+[Backup And Restore Evidence](BACKUP_AND_RESTORE_EVIDENCE.md).
 
 ## Stateless Kubernetes Runtime
 
@@ -391,7 +396,9 @@ The output includes a release-specific migration Job, database-head wait init
 containers, API readiness/liveness probes, rolling Deployments, Services, Pod
 disruption budgets, a tokenless ServiceAccount, and one fenced scheduler. Apply
 the named Secret through the cluster's secret manager and review ingress proxy
-CIDRs before deployment. Detailed rollout and scaling rules live in
+CIDRs before deployment. A release-changing export requires adopted backup
+evidence and carries only its sanitized digest and identifiers as Job
+annotations. Detailed rollout and scaling rules live in
 [Scaling And Multi-Host Deployment](SCALING_AND_MULTI_HOST_DEPLOYMENT.md).
 
 ## Recovery Commands