Reconcile Sponsor CRM table ownership with CloudFormation

[alexeygrigorev]

Reconcile Sponsor CRM table ownership with CloudFormation

Status: blocked — route B selected; waiting for a HUMAN AWS operator to obtain AWS Support guidance and the review team to approve a mutation-free remediation design
Tags: bug, infra, data, migration, testing, P1
Depends on: None — the route-B decision is already recorded in #140 and #141; #141 is not a blocker
Blocks: #136
Next owner: HUMAN AWS operator
Resume condition: sanitized confirmation that AWS Support guidance and authentic private diagnostics are available for Architecture/Security review; no production action is implied

Decision and objective

#140 and #141 found one historical table-creation event, but no trusted record cryptographically links its historical table identifier to the exact CloudFormation stack incarnation. Architecture and Security therefore classified the evidence as insufficient, rejected route A, and selected route B.

This issue designs, rehearses, approves, and—only after fresh explicit gates—coordinates a supported ownership reconciliation. It does not authorize a tagless exception or weaken #136.

Grooming this issue authorizes no AWS call, Support disclosure, backup, export, restore, import, replacement, tag, change set, deployment, migration, environment, repository, workflow, or data mutation. Every later AWS action must be enumerated in the accepted runbook and separately approved at the required gate.

Repository and template change lifecycle

If the selected supported path requires any repository, workflow, SAM/CloudFormation, infrastructure-template, validation, or operator-facing implementation change, that change must follow the full repository lifecycle before the related HUMAN AWS phase: Product Manager confirms the exact scope and repository, Software Engineer implements without committing, Architecture/Security re-review the frozen candidate where required, Tester runs the full affected verification, Product Manager performs final acceptance, Software Engineer commits with Refs #143, the orchestrator merges and pushes through the repository's approved path, and On-Call verifies CI/CD. A credentialed HUMAN apply for infrastructure that is not self-deployed remains a separate digest-bound gate and does not replace those stages.

If Support-backed reconciliation requires no repository change, PM must record that explicit no-change disposition and why; Tester and PM still verify the exact private-plan digest and sanitized evidence at the phase gates defined below. No Support response, runbook draft, or HUMAN approval retroactively authorizes an unreviewed file, workflow, template, deployment, or AWS mutation.

Public/private evidence boundary

Keep raw resource/account/principal identifiers, stack and table identifiers, events, item data, Support correspondence/case details, screenshots, commands containing identifiers, private locations/links, and credentials-adjacent material outside this public repository in the approved private knowledge/evidence system.

The public issue may contain only sanitized source classes, UTC bounds, counts, digests, state transitions, decisions, and PASS/FAIL/ABORT results. No raw operational document or evidence artifact is committed here.

Global security contract — applies to every phase

These three non-waivable controls apply to Support disclosure, baseline reads, backup/export, isolated rehearsal/restore, the selected ownership path, cutover, rollback, and cleanup. They supplement the Architecture-approved sequence and constraints; they do not replace any phase gate. Every mutation and rollback remains a separately named, frozen-runbook-digest-bound HUMAN approval.

1. Phase-scoped least privilege, session provenance, and operation reconciliation

Before each phase, the frozen private runbook must define a phase-specific access/session matrix containing the exact private account, region, resources, actor, expected principal, role/session source, issuance and expiry, MFA and approval provenance, and minimum API action/resource set. Read-only and mutation sessions must be separated where practical. The matrix must explicitly exclude shared/static credentials, production credentials in rehearsal, broad administrator sessions, and any broadening or reuse of the deployment OIDC role. Any IAM change requires a separately groomed Architecture/Security review and is not authorized by this issue.

Credentials must be short-lived, uniquely attributable, and scoped only to the approved phase. Entry and immediately pre-mutation checks must prove principal, account, region, resources, session validity, and frozen inputs. The runbook must retain privately both the exact allowed API/action/resource inventory and the exact observed operation inventory and reconcile them before the next mutation. Any extra permission, unexpected or missing API, unapproved principal/session, account/region/resource drift, expired session, or other mismatch causes ABORT before the next call.

At phase exit, capture session expiry or explicit revocation and prove that temporary access is no longer usable. Missing issuance, provenance, allowed/observed inventory, expiry, or revocation evidence fails closed. Enumerating calls never makes a broad administrator session acceptable.

2. Production-equivalent confidentiality for export and restored Sponsor data

Every backup, export, restored table, item, key, and derived integrity artifact retains the production Sponsor CRM classification in non-production for its entire lifetime. Use only approved isolated accounts/environments and principals, approved KMS keys, encryption in transit and at rest, private access paths, and controls that prevent public or unintended cross-account access. The target must have no external event source, webhook, mail/social/Telegram integration, scheduled writer, stream consumer, production credential, or uncontrolled integration/egress path; prove those exclusions before data is introduced and throughout rehearsal.

Item bodies, keys, per-item hashes, raw command output, and identifiers stay in the private evidence boundary and must not enter public CI/console logs, issues, screenshots, or routine Support material. Integrity evidence is private and access-controlled. Any digest that leaves the private boundary must use a Security-reviewed keyed or equivalently disclosure-resistant construction so low-entropy records cannot be guessed from fingerprints.

The private runbook must set a retention deadline, cleanup owner, inventory of data-bearing resources/artifacts/logs, rollback/incident-evidence hold, verified deletion procedure, and KMS/access revocation proof. Cleanup is blocked while an approved rollback or incident hold remains, then separately HUMAN-approved and verified complete. AWS Support receives only the minimum ownership diagnostics; production item data is excluded unless Security and an authorized HUMAN explicitly approve that specific disclosure.

3. Private audit/redaction execution and enforceable deploy/change/write freeze

Every phase must use a Security-reviewed execution mechanism that records UTC actor, session, action, result, state transition, and allowed-versus-observed operation evidence directly into the private evidence store. It must suppress shell tracing and verbose output that could expose credential material, item data, raw identifiers, private paths/links, or unredacted command output to public logs. Redaction and destination checks occur before any sanitized publication. An evidence mismatch or leak is an immediate ABORT and security-containment event; continuation requires a fresh Security decision.

Before snapshot or integrity comparison, detach/import, restore, or cutover, the runbook must enforce a deploy/change/write freeze with technical controls and captured proof; a procedural promise is insufficient. It must inventory every writer and mutator, including application writes, retries, TTL, streams, scheduled and asynchronous consumers, operators, deployment workflows, event-source mappings, integrations, and the #136 migration. For each one, define the enforced quiescence mechanism or complete ordered change-capture method, owner, start/end boundary, and verification.

Where complete quiescence is not possible, reconcile every captured mutation between equivalent logical points through cutover and throughout the rollback window. Abort before the next mutation on an unknown writer, reactivated workflow/integration, missing or unordered change, reconciliation mismatch, or unenforceable freeze. Freeze release is an explicit post-verification step and cannot silently occur during rollback or cleanup.

Phase 1 — AWS Support and read-only diagnosis

• [HUMAN] Open or update an AWS Support case through an approved identity and disclose only the minimum private evidence needed.
• Ask Support to determine whether the current table is associated with this stack or any other stack and why the canonical ownership marker is absent.
• Obtain written guidance for the supported choices: association/ownership repair, retain-and-import of the existing table, or restore/replacement under a new physical name.
• Ask Support to identify unsupported or destructive steps, import prerequisites, named-resource constraints, and whether any proposed sequence could delete or replace the production table.
• Record privately the authenticated response, retrieval time, source, scope, and digest. Post only a sanitized summary here.
• Architecture and Security classify the guidance as sufficient for design, ambiguous, or requiring escalation. Ambiguous guidance fails closed.

Do not manually create reserved aws: tags. Do not treat a same-name ARN, current mapping, current schema, or current table identifier as historical ownership proof. If Support unexpectedly supplies an authoritative exact historical stack↔table binding, stop route B and request a fresh independent #140 route review; route A does not become authorized automatically.

Phase 2 — immutable pre-change baseline and recoverability design

Before requesting approval for any backup/export action, the runbook must define the exact private baseline and evidence manifest:

• Current stack/resource association, table identity, schema, keys, indexes, billing/capacity, encryption, TTL, streams, PITR, deletion protection, replicas, tags, alarms, application dependencies, and relevant deployment state.
• Sanitized UTC capture time, retrieval principal/session provenance, API/command inventory, artifact sizes/digests, and complete-pagination proof.
• A deterministic data-integrity method that covers every key/item, uses stable canonical serialization and paginated manifests/hashes, and does not rely on approximate item count alone.
• Expected schema/configuration equality checks, exact item/key count checks, duplicate/missing-key checks, and separately identified settings that restore/import does not preserve automatically.
• Private evidence retention, encryption, access, and deletion/retention owners.

The reviewed runbook must require a verified recovery source before any ownership mutation:

• [HUMAN approval required] Create the selected on-demand backup and/or export only after Architecture, Security, Tester, and PM accept the backup plan and cost.
• Verify terminal successful state, exact private source identity, UTC creation point, encryption/KMS access, retention, restore eligibility, size, and digest/manifest linkage.
• Record how backup/export completeness will be independently checked and how recovery remains available throughout rollback.
• Abort if the recovery artifact is incomplete, inaccessible, associated with a different source, not restorable, or cannot be retained through the rollback window.

Phase 3 — isolated restore rehearsal

The first restore is an explicitly approved non-production rehearsal, never an implicit production repair.

• [HUMAN approval required] Use an approved isolated account/environment and a unique non-production name that cannot receive production traffic or collide with the retained production name.
• Pin source recovery artifact, target region/account, encryption, capacity/load limits, network/access boundaries, timeout, cleanup owner, and maximum cost.
• Restore and reconstruct all non-data configuration that the selected recovery mechanism does not preserve, following current official AWS guidance and the accepted runbook.
• Run the full deterministic key/item manifest comparison plus exact schema/index/configuration checks. Approximate service-reported item counts are corroboration only.
• Exercise the ownership/import/replacement sequence against the isolated target, including a reviewed CloudFormation change-set preview and proof of the final managed association.
• Prove application compatibility without production traffic, write amplification, or destructive test data.
• Preserve private evidence and publish only sanitized PASS/FAIL counts, digests, duration, load, and cost.
• [HUMAN approval required] Clean up rehearsal resources only after evidence retention is confirmed.

Any mismatch, unexpected replacement/delete action, throttling risk, permission expansion, evidence leak, or inability to restore causes ABORT. A failed rehearsal must not advance to production.

Phase 4 — choose one supported CloudFormation path

Architecture and Security must select exactly one Support-backed path and reject the others in writing. Confirm every constraint against current official AWS documentation and Support guidance rather than assuming behavior.

Candidate A: retain/detach and import the existing table

• Prove whether the resource is currently associated with this or another stack and whether import is supported in that state.
• Define template/import identifiers, drift expectations, resource-policy/tag behavior, and the exact safe transition.
• Apply both DeletionPolicy: Retain and UpdateReplacePolicy: Retain wherever the accepted design requires them, and prove their effective template/change-set state before removal or import.
• Abort if import would require deleting the table, fabricating reserved tags, accepting ambiguous ownership, or bypassing CloudFormation validation.

Candidate B: restore/rebuild under a new physical name and cut over

• Treat the named-table collision as a hard constraint: never plan an in-place replacement that requires two resources with the same custom name.
• Define the new managed name, restore/copy method, full configuration reconstruction, deterministic integrity proof, application cutover, write-consistency strategy, downtime, and rollback window.
• Keep the old table retained and isolated until post-cutover integrity and rollback gates pass.
• Abort if concurrent writes cannot be reconciled, application configuration cannot be rolled back, or the expected change set includes an unapproved delete/replacement.

Candidate C: AWS-supported association repair

• Use only a procedure explicitly supplied and confirmed by AWS Support for this exact private case.
• Require the same backup, rehearsal, integrity, change preview, rollback, and approval gates as every other path.
• Never simulate the outcome by manually writing reserved ownership tags.

Phase 5 — production runbook and explicit gates

Before any production action, publish a sanitized frozen runbook digest and retain the exact private runbook. It must enumerate:

• ordered actor/action/API/console steps, immutable inputs, expected outputs, and approver for every step;
• explicit separation of read-only checks, reversible mutations, cutover, irreversible actions, and cleanup;
• preflight and repeated identity/configuration/integrity checks before and after every wait or state transition;
• capacity, throttling, write-consistency, downtime, maintenance window, monitoring, alarms, owner coverage, duration, and cost ceiling;
• rollback for pre-cutover and post-cutover failures, including retained recovery assets and application reversion;
• hard abort criteria for identity/configuration drift, unexpected change-set replacement/deletion, integrity mismatch, Support ambiguity, access/session drift, cost/load threshold, unavailable rollback, or missing approver;
• proof that Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 migration, normal app deployment, flags, production smoke/seed, and retained-queue cleanup remain prohibited until ownership is independently re-proved.

Fresh gates are required in this order:

1. Architecture accepts the selected supported path and CloudFormation ownership end state.
2. Security accepts evidence handling, access, backup/restore, destructive-action boundaries, rollback, and abort criteria.
3. Tester accepts the rehearsal and exact integrity test plan/results.
4. PM accepts scope, operator clarity, downtime/cost, owners, and user impact.
5. [HUMAN] An authorized operator explicitly approves the named production phase and exact frozen runbook digest immediately before it begins.
6. On-Call verifies the finished ownership state and the normal CI/CD path. No manual app deploy substitutes for CI/CD.

An approval for one phase does not authorize a later phase or any extra API/action. Material drift invalidates the frozen runbook and returns to review.

Required production verification

• CloudFormation reports the intended logical↔physical association and expected resource status through read-only checks.
• Canonical ownership evidence is present and exactly consistent; no generic tagless exception is introduced.
• Full schema/configuration and deterministic key/item integrity checks pass against the frozen baseline and recovery/rehearsal expectations.
• No unapproved delete, replacement, retag, permission expansion, workflow dispatch, deployment, environment change, flag enablement, migration, or queue action occurred.
• Rollback assets remain available for the accepted observation window; their later cleanup receives separate HUMAN approval.
• Sanitized operation inventory, state transitions, counts, digests, downtime/load/cost, and PASS/FAIL verdicts are posted without private identifiers.
• Architecture, Security, Tester, PM, HUMAN, and On-Call record final decisions before Reconcile missing CloudFormation ownership provenance for Sponsor CRM table #140 or Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 can advance.

Test scenarios

Support cannot determine ownership or proposes an unsupported shortcut

The design fails closed. No tag repair, import, replacement, or migration occurs; escalate for clearer Support guidance.

Backup/export is incomplete or cannot be restored

Abort before ownership work. Preserve the original table and obtain a newly reviewed recovery design.

Rehearsal restores but integrity/configuration differs

Abort. Approximate counts or sampled reads cannot waive deterministic mismatch.

Import preview reports existing ownership, replacement, or deletion

Abort and return to Architecture/AWS Support. Do not execute or manually detach/retag.

Named-table replacement collides

Use a reviewed new-name/cutover design or stop. Never delete the production table merely to free its name.

Production identity, writes, load, cost, or change set drifts

Abort before the next mutation, preserve recovery assets, and execute only the already approved rollback boundary.

Support later proves the exact historical pair

Stop route B and request fresh Architecture/Security review in #140. Do not revive route A by inference.

Private evidence appears in a public artifact

Stop, contain through the approved security process, and do not continue until Security records a new decision.

Acceptance criteria

• AWS Support guidance and authentic diagnostics are retained privately with sanitized public provenance and decision.
• One supported CloudFormation path is selected with import/replacement/Retain/named-resource constraints explicitly resolved.
• A verified recovery artifact and successful isolated restore rehearsal precede any production ownership mutation.
• Exact deterministic data and configuration integrity tests pass; approximate counts alone are never accepted.
• The frozen production runbook includes actors, actions, APIs, immutable inputs, expected states, downtime/load/cost, rollback, cleanup, and hard abort criteria.
• Every backup, restore, import, detach, replacement, cutover, cleanup, and other mutation receives the required explicit HUMAN approval; no approval is inferred from issue grooming.
• Every phase uses the approved least-privilege short-lived session matrix, credential exclusions, entry/pre-mutation identity checks, exact allowed/observed operation reconciliation, and verified expiry/revocation; any access or operation drift aborts.
• Every export/restore and derived Sponsor integrity artifact keeps production-equivalent confidentiality in isolated non-production, including approved KMS/access/egress controls, private keyed integrity evidence where required, minimal Support disclosure, retention holds, separately approved cleanup, verified deletion, and KMS/access revocation.
• Every phase uses the reviewed private audit/redaction mechanism, and snapshot/integrity, ownership, restore, cutover, and rollback work is protected by an enforceable deploy/change/write freeze plus complete mutator inventory and ordered reconciliation.
• Fresh Architecture, Security, Tester, PM, HUMAN, and On-Call gates pass with sanitized public decisions.
• The final table is demonstrably CloudFormation-owned without manual reserved-tag creation or a generic tagless exception.
• Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 remains blocked until final ownership and integrity evidence is independently accepted.
• No private operational knowledge or raw identifier is added to this public repository.

Out of scope

• Recollecting Provide one short-lived CloudTrail Event History audit session #141 CloudTrail Event History without a newly identified exact-pair source.
• A tagless migration exception or weakening Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 checks.
• Manual reserved-tag creation.
• Unreviewed IAM/support/deploy/workflow/environment changes.
• Running the Sponsor GSI migration, normal deployment, flags, production smoke/seed, or retained-queue cleanup.
• Publishing raw SOPs, prompts, Support correspondence, evidence, identifiers, paths, or generated operational artifacts in this public repo.

[alexeygrigorev]

PM grooming complete. Route B is now a design-and-approval-first HUMAN/AWS remediation: Support guidance, private baseline evidence, verified recovery, isolated restore/ownership rehearsal, deterministic integrity checks, one explicitly selected CloudFormation path, rollback/abort/downtime/load/cost controls, and fresh Architecture/Security/Tester/PM/HUMAN/On-Call gates. Grooming authorizes no AWS or repository mutation. Next owner: authorized HUMAN AWS operator; resume with sanitized confirmation that Support guidance and authentic private diagnostics are ready for review.

[alexeygrigorev]

ARCHITECTURE PASS — design gate only; no AWS action authorized

The route-B plan is implementable and safely ordered: authenticated Support guidance → immutable baseline → approved recovery artifact → isolated restore/ownership rehearsal → one selected supported path → frozen production runbook → per-phase approvals → production verification. This PASS approves the groomed design framework only. It does not select a candidate path, accept evidence not yet supplied, or authorize a Support disclosure or AWS mutation.

The frozen runbook must make these proofs explicit before later Architecture approval:

• Point-in-time integrity and writes: pin one recovery/snapshot time and define quiescence or complete change capture/reconciliation through cutover. A paginated live scan—even with consistent reads—is not a table-wide snapshot. TTL expiry, stream consumers, scheduled writers, retries, and all application writers must be covered. Exact key/item hashes must compare equivalent logical points, not a restore with a later moving source.
• Import/detach sequencing: if retain-and-import is selected, use separately approved operations for (1) proving effective DeletionPolicy: Retain and UpdateReplacePolicy: Retain, (2) removing/detaching while retaining the table, and (3) a distinct IMPORT change set describing the actual configuration. Import cannot create/delete/update other resources, and the resource must not belong to another stack. Preview, execute, wait, verify, and abort gates must be enumerated for each operation. See manual import constraints and AWS's retain/remove/re-import sequence.
• Restore/new-name path: DynamoDB restore creates a new table, and settings including streams, TTL, PITR, deletion protection, tags, alarms, IAM integration, and related configuration require explicit reconstruction and verification. The new-name cutover must enumerate every application, event-source, permission, alarm, and scheduled/async consumer, plus rollback behavior. A custom-named resource cannot be replaced in place without a new name. See DynamoDB restore behavior and custom-name replacement constraints.
• Approvals and recovery: each backup/export, rehearsal restore, detach, import, replacement, configuration reconstruction, traffic/write cutover, rollback mutation, and cleanup is a separately named HUMAN-approved phase with cost/load/time ceilings and a still-valid recovery asset. Approval must identify the frozen private runbook digest; material drift returns to review.

Dependency direction is correct: #143 remains independent to avoid a #140↔#143 cycle; #140 remains blocked on #143. #141's remaining access-session/provenance cleanup does not block route B and must not be recollected. If Support supplies an authoritative exact historical binding, stop and return to fresh #140 Architecture/Security review as specified.

Verdict: ARCHITECTURE PASS for the groomed remediation plan. The issue correctly remains blocked on authorized HUMAN Support guidance and private diagnostics; no production or rehearsal mutation may begin from this verdict.

[alexeygrigorev]

SECURITY BLOCK — add an explicit access and production-data contract

The route-B sequence, CloudFormation choices, recovery ordering, deterministic integrity standard, per-mutation HUMAN gates, abort/rollback structure, and downtime/load/cost requirements are sound. I agree with the Architecture constraints, including point-in-time write reconciliation, separate retain/detach/import operations, new-name restore configuration reconstruction, and digest-bound approval for every mutation and rollback.

I cannot yet approve the groomed security design because three controls are implicit or deferred rather than required for every phase, including Support disclosure, baseline reads, backup/export, rehearsal, and cleanup.

1. Phase-scoped least privilege and session provenance

“Approved identity” is too broad. Add a global access contract requiring the frozen private runbook to define, before each phase:

• exact private account, region, resources, actor, role/session source, issuance/expiry, MFA/approval provenance, and expected principal;
• the minimum API/action/resource set for that phase, separated into read-only and mutation sessions where practical;
• short-lived credentials, no shared/static credentials, no deploy-OIDC broadening, and a separately groomed review for any IAM change;
• entry and pre-mutation identity/account/region/resource checks, followed by session expiry/revocation evidence;
• an exact allowed/observed operation inventory. Any extra permission, unexpected API, principal drift, or unapproved session fails closed.

A broad administrator session must not become acceptable merely because the runbook enumerates calls.

2. Production-data controls for exports and rehearsal

A restore into a “non-production” target still contains production Sponsor CRM data and is not declassified. Require production-equivalent confidentiality controls throughout its lifetime:

• approved isolated account/environment and principals; approved KMS keys; encryption in transit and at rest; no public or unintended cross-account access;
• no external event source, webhook, mail/social/Telegram integration, scheduled writer, stream consumer, production credential, or uncontrolled egress;
• no item bodies, keys, per-item hashes, raw command output, or identifiers in public CI/console logs, issues, screenshots, or Support material unless an authorized disclosure is explicitly approved;
• private per-item/key integrity evidence. If a digest could leave the private boundary, use a keyed construction or another reviewed disclosure-resistant design rather than exposing low-entropy record fingerprints;
• retention deadline, cleanup owner, deletion verification, KMS/access revocation, and a hold that prevents cleanup while rollback or incident evidence is required.

Support receives only the minimum ownership diagnostics; production item data is excluded unless Security and an authorized HUMAN explicitly approve that disclosure.

3. Enforced audit, redaction, and change/write freeze

Require a reviewed execution mechanism for every phase that captures UTC actor/session/action/result evidence directly into the private evidence store while suppressing shell tracing, credential material, item data, and raw identifiers from public logs. An evidence leak or mismatch is an immediate ABORT and security-containment event.

Before snapshot/integrity comparison, detach/import, restore, or cutover, require an enforceable deployment/change freeze and an explicit inventory of all writers and mutators: application writes, retries, TTL, streams, scheduled/async consumers, operators, deployment workflows, and #136 migration. The runbook must define quiescence or complete ordered change capture/reconciliation through cutover and rollback; a procedural promise not to deploy is insufficient.

The existing numeric downtime/load/cost ceilings, owner coverage, recovery-asset retention, named-table collision rule, Retain policies, change-set abort checks, and separate HUMAN approval for backup/restore/import/cutover/rollback/cleanup should remain unchanged.

After the issue makes these requirements explicit, Security can re-review the groomed design. This BLOCK authorizes no Support disclosure, AWS call, IAM change, backup/export, rehearsal, cleanup, or production mutation.

[alexeygrigorev]

PM AMENDMENT — Security re-review requested

I amended the groomed issue body to close exactly the three global-control gaps in the Security block:

1. Added a per-phase least-privilege, short-lived session matrix with principal/MFA/approval provenance, explicit credential exclusions, separate read/mutation scope where practical, exact allowed-versus-observed API/action/resource reconciliation, verified expiry/revocation, and fail-closed access or operation drift.
2. Classified every export, restore, and derived Sponsor integrity artifact as production-confidential even in non-production, with approved KMS/access/isolation and no-integration/egress controls, private keyed or equivalent disclosure-resistant integrity evidence, retention/hold and verified cleanup/revocation, and minimum Support disclosure excluding item data absent specific Security + HUMAN approval.
3. Required a reviewed private audit/redaction execution mechanism plus technically enforceable deploy/change/write freeze, complete writer/mutator inventory, and ordered mutation capture/reconciliation through cutover and rollback.

The Architecture-approved route-B sequence, CloudFormation candidates and constraints, numeric downtime/load/cost ceilings, recovery retention, named-table and Retain safeguards, change-set abort checks, and separate frozen-runbook-digest-bound HUMAN approval for every mutation and rollback remain unchanged.

Security: please re-review the amended groomed design against the blocking findings. This PM specification amendment authorizes no Support disclosure, AWS call, IAM change, backup/export, restore/rehearsal, deploy/change/write action, cleanup, rollback, or production mutation. The issue remains blocked pending the documented HUMAN evidence and review gates.