Reconcile Sponsor CRM table ownership with CloudFormation

[alexeygrigorev]

Reconcile Sponsor CRM sandbox table ownership with CloudFormation

Status: blocked — the AWS target is confirmed sandbox-only; waiting for an authorized HUMAN to classify the existing sandbox source table and explicitly state whether any data loss is acceptable, followed by fresh Architecture/Security proportionality review
Tags: bug, infra, data, migration, testing, P1
Depends on: None — #140/#141 historical evidence remains valid context; #141 is not a blocker and must not be recollected without a newly identified exact-pair source
Blocks: #136
Next owner: authorized HUMAN data owner/operator for the Phase 0 classification record
Resume condition: one sanitized Phase 0 classification statement records either (A) real/private/unknown data or loss not accepted, or (B) independently proven fresh synthetic/disposable data with explicit total-loss acceptance; then Architecture and Security perform a fresh proportionality review before Support contact, reset design, AWS calls, repository changes, or mutation

Authoritative boundary and objective

The existing target is the live dataops-v1 application stack in the DataOps sandbox AWS account and eu-west-1. The existing Sponsor CRM table is the sandbox source table. There is no production AWS account, production stack, production cutover, or production environment in this issue. The #145/#136 migration uses the existing exact main-branch OIDC trust with no GitHub Actions environment; that identity choice does not establish ownership.

Sandbox account placement does not classify the current table contents, prove that the table is disposable, authorize data loss, or weaken ownership requirements. Until Phase 0 independently proves otherwise, the table, its items, keys, diagnostics, backups, exports, restores, and derived integrity evidence retain source-equivalent private/operational confidentiality.

#140 and #141 found one historical table-creation event but no trusted record binding its historical table identifier to the exact CloudFormation stack incarnation. Preserve that historical evidence and every existing issue comment. Do not infer ownership from account placement, a same-name ARN, current logical/physical mapping, schema, current table identifier, or missing/present tags. Do not manually create reserved aws: tags. #136 remains blocked until an exact supported ownership end state and integrity outcome are independently accepted.

This grooming authorizes no AWS call, private-evidence inspection by an agent, Support contact or disclosure, backup, export, restore, import, detach, replacement, deletion, tag, change set, deployment, migration, environment change, repository/workflow mutation, data mutation, or cleanup. Each later action requires its named gate below.

Phase 0 — HUMAN source-data and loss classification

Before selecting a remediation route, an authorized HUMAN data owner/operator must classify the current sandbox source table using authentic records and evidence retained inside the approved private boundary.

• State whether the table is independently proven fresh synthetic/disposable, or contains real/private operational data, or remains unknown.
• State whether complete loss of the current table and all contained records is explicitly acceptable. Silence, sandbox naming, low item count, apparent emptiness, reconstructability assumptions, or lack of recent use never counts as acceptance.
• Identify privately the accountable data owner, classification authority, evidence sources, UTC decision time, evidence digest, scope, and any retention/legal/operational dependency.
• Confirm whether any application, operator, workflow, stream, scheduled process, integration, backup, audit requirement, or downstream record depends on the current table.
• Publish only one sanitized classification statement; do not publish item data, counts that disclose private activity, identifiers, screenshots, commands, private locations/links, credentials-adjacent details, or raw evidence.

Use one of these public forms:

Protected-data route: The existing sandbox source table contains real/private operational data, its classification remains unknown, or total loss is not explicitly accepted. Authentic classification evidence and accountable ownership are retained privately. No AWS or repository action occurred.

Reset-candidate route: The existing sandbox source table is independently proven fresh synthetic/disposable, contains no real/private operational data, has no retained dependency, and an authorized owner explicitly accepts complete loss within the recorded scope. Authentic classification and loss-acceptance evidence are retained privately. No AWS or repository action occurred.

Any ambiguity selects the protected-data route. No criterion in this issue is checked merely because the account, stack, domain, or workflow is named sandbox.

After the statement is posted, Architecture and Security must freshly review whether the evidence supports the selected route and whether the controls are proportionate. Their review approves a route for further grooming only; it does not authorize an AWS call or mutation.

Route A — protected ownership reconciliation

Route A is mandatory when data is real/private, classification is unknown, loss is not explicitly accepted, a dependency exists, or Architecture/Security do not accept the reset-candidate proof.

A1. Support guidance and read-only diagnosis

• [HUMAN] Through an approved phase-scoped identity and minimum disclosure, obtain authenticated AWS Support guidance about the current sandbox table's CloudFormation association and supported repair choices.
• Ask whether the supported choices are association repair, retain/detach/import of the existing table, or restore/replacement under a new physical name; identify unsupported/destructive steps, import prerequisites, and named-resource constraints.
• Keep the response, source, scope, retrieval time, authenticity evidence, and digest private. Publish only a sanitized sufficiency decision.
• Architecture and Security classify the guidance as sufficient, ambiguous, or requiring escalation. Ambiguity fails closed.

If Support supplies an authoritative exact historical stack↔table binding, stop and request fresh #140 Architecture/Security review. Historical route A does not become authorized automatically.

A2. Immutable baseline and recoverability

Before any ownership mutation, the private runbook must define and independently verify:

• exact current stack/resource association, table identity, schema, keys/indexes, billing/capacity, encryption, TTL, streams, PITR, deletion protection, replicas, tags, alarms, application dependencies, and deployment state;
• deterministic key/item integrity with stable canonical serialization, complete pagination, exact counts, duplicate/missing-key checks, and point-in-time write reconciliation;
• a verified retained recovery source with exact source/time/KMS/access/retention/restore eligibility and rollback availability;
• source-equivalent confidentiality, private evidence handling, retention holds, cleanup owner, and verified deletion/revocation after the hold ends.

Any backup/export action is a separately named, cost-bounded HUMAN-approved phase after Architecture, Security, Tester, and PM accept the frozen plan.

A3. Isolated rehearsal

• Use only a separately approved isolated sandbox target with a unique non-live name, approved KMS/access, no production or external traffic, no integrations or uncontrolled egress, and explicit time/load/cost ceilings.
• Restore/reconstruct configuration, run complete deterministic integrity checks, rehearse the selected ownership path, preview exact CloudFormation effects, prove final managed association, and exercise rollback without touching the live source table.
• Abort on mismatch, replacement/delete drift, throttling risk, permission expansion, evidence leak, unaccounted writer, or unavailable rollback.
• Cleanup requires separate HUMAN approval after evidence/rollback holds are cleared.

A4. Select one supported CloudFormation path

Architecture and Security select exactly one Support-backed path and reject the others:

1. retain/detach/import the existing table, with effective DeletionPolicy: Retain and UpdateReplacePolicy: Retain, separate removal/import operations, exact import identifiers, and no delete or fabricated reserved tags;
2. restore/rebuild under a unique new sandbox physical name, with complete configuration reconstruction, writer reconciliation, application cutover, rollback, and retained old table through the observation window; or
3. an exact association-repair procedure supplied and confirmed by AWS Support for this case, subject to the same recovery, rehearsal, integrity, preview, rollback, and approval gates.

A5. Frozen live-sandbox runbook and execution gates

The private runbook must enumerate ordered actor/action/API steps, immutable inputs, expected outputs, identity/session checks, approval provenance, exact allowed operations, waits, monitoring, load/cost/time ceilings, rollback, cleanup, and abort criteria. Publish only its sanitized digest and decision.

Fresh gates are required in this order for every named mutation phase:

1. Architecture accepts the selected supported path and exact ownership end state.
2. Security accepts access, evidence, confidentiality, destructive boundaries, rollback, and abort controls.
3. Tester accepts rehearsal and deterministic integrity evidence.
4. PM accepts scope, operator flow, impact, cost, owners, and recovery.
5. [HUMAN] An authorized operator approves the exact named phase and frozen runbook digest immediately before it begins.
6. On-Call verifies the resulting sandbox ownership/integrity state and approved CI/CD path.

Approval for one phase never authorizes another. Material drift returns to review.

Route B — separate reset candidate, never inferred

This issue does not authorize reset, deletion, replacement, recreation, or data loss.

Only when Phase 0 independently proves fresh synthetic/disposable data, an accountable owner explicitly accepts complete loss, and fresh Architecture/Security accept that proof may PM groom a separate reset implementation issue. That issue must name the exact sandbox stack/table boundary, prove no real/private data or downstream dependency, define supported CloudFormation ownership creation, identify every destructive call and resource effect, preserve least privilege/audit/redaction, include abort and rollback/reseed behavior, require Tester and PM acceptance, and place a separate digest-bound HUMAN approval immediately before each destructive phase.

If any proof fails or drifts, return to Route A. A reset route may not weaken #136's exact ownership guard, fabricate reserved tags, use a tagless exception, rename or target a production account, or treat sandbox naming as authorization.

Global access, confidentiality, audit, and freeze contract

These controls apply to classification follow-up, Support disclosure, reads, backup/export, rehearsal, ownership work, any separately groomed reset, rollback, and cleanup:

• Use short-lived, uniquely attributable, phase-scoped credentials with exact account, region, resources, actor, expected principal, issuance/expiry, MFA/approval provenance, and minimum action/resource scope. Separate read and mutation sessions where practical. No shared/static credentials, broad administrator session, rehearsal access to unrelated data, or deploy-OIDC broadening.
• At entry and immediately before mutation, prove principal/account/region/resource/session and frozen inputs. Reconcile exact allowed versus observed APIs/actions/resources; any extra permission, unexpected call, identity drift, or expired session aborts. Verify session expiry/revocation at exit.
• Keep source data and derived artifacts private and encrypted in transit/at rest with approved KMS/access/isolation. No public/cross-account access, unintended integrations, event sources, webhooks, scheduled writers, stream consumers, production credentials, or uncontrolled egress.
• Item bodies, keys, raw output, per-item hashes, identifiers, Support correspondence, screenshots, and private paths/links never enter public logs or issues. Any public digest must use a Security-reviewed disclosure-resistant construction.
• Every phase uses a reviewed private audit/redaction mechanism recording UTC actor/session/action/result/state transition while suppressing sensitive output. A leak or evidence mismatch is an immediate ABORT and containment event.
• Before snapshot/integrity work or mutation, enforce a technical deploy/change/write freeze and inventory all writers/mutators, including application retries, TTL, streams, schedules, async consumers, operators, workflows, event mappings, integrations, and Migrate Sponsor CRM GSIs in a protected stage-only workflow #136. Require quiescence or complete ordered capture/reconciliation through rollback. Freeze release is explicit.

Repository and workflow lifecycle

Any repository, workflow, SAM/CloudFormation, infrastructure-template, validation, or operator-facing change follows the complete PM → Software Engineer → Architecture/Security where required → Tester → PM acceptance → commit with Refs #143 → local merge/push → On-Call lifecycle. A credentialed HUMAN infrastructure apply is separate and does not replace repository review.

If the selected supported route requires no repository change, PM records an explicit no-change disposition. No Support response, private runbook, sandbox classification, or HUMAN approval retroactively authorizes an unreviewed change.

Required final verification

• Phase 0 classification and loss decision are independently accepted; sandbox naming alone satisfied nothing.
• The selected route has fresh Architecture and Security proportionality decisions.
• CloudFormation reports the intended exact logical↔physical association and healthy resource state through read-only checks.
• Canonical ownership evidence is exact; no manual reserved-tag creation or generic tagless exception exists.
• Full schema/configuration and route-proportionate integrity checks pass against the accepted baseline or reset proof.
• No unapproved delete, replacement, retag, permission expansion, workflow dispatch, deployment, environment change, flag enablement, migration, queue action, or cleanup occurred.
• Exact sanitized operation inventory, state transitions, decisions, digests, downtime/load/cost, and PASS/FAIL/ABORT outcomes are recorded without private identifiers.
• Architecture, Security, Tester, PM, HUMAN, and On-Call record required final decisions before Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 advances.

Test scenarios

Sandbox name but unknown/private contents

Select Route A. No reset, loss acceptance, or weakened proof is inferred.

Synthetic claim lacks independent evidence or accountable loss acceptance

Fail closed to Route A. Do not groom or execute reset.

Fresh synthetic/disposable proof and explicit total-loss acceptance pass review

PM may groom a separate reset issue. This issue still authorizes no destructive action.

Support guidance is ambiguous or proposes an unsupported shortcut

Stop and escalate. Do not tag, import, replace, reset, or migrate.

Recovery/rehearsal/integrity/access evidence fails

Abort before the next action, preserve the sandbox source table and recovery evidence, and return to review.

Identity, writer inventory, operation inventory, or frozen plan drifts

Abort. Expire/revoke the session and require a fresh reviewed plan.

Out of scope

• Recollecting Provide one short-lived CloudTrail Event History audit session #141 without a newly identified exact-pair source.
• Assuming data is disposable from sandbox/account/domain/environment naming.
• Contacting Support or inspecting private evidence by an agent under this grooming step.
• A tagless migration exception, weakened Migrate Sponsor CRM GSIs in a protected stage-only workflow #136 checks, or manual reserved-tag creation.
• An unreviewed reset, delete/recreate, import, replacement, backup/export, restore, deployment, migration, flag, smoke/seed, queue, or cleanup action.
• Renaming the existing stack/table/role merely to add sandbox to its name.
• Targeting or designing a production AWS account rollout.
• Publishing raw operational knowledge, evidence, identifiers, item data, Support material, private links/paths, or credentials-adjacent setup details.

[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.