Q3 E2E Synthetic Data and Cleanup

Principles

1. Synthetic data must be attributable to exactly one LTI run.
2. Mutable scenarios target acceptance, sandbox, test mode, or development only.
3. Cleanup narrows by run-owned identifiers and creation time. It never widens after a lookup failure.
4. Secrets and raw DR tokens are runtime inputs, not evidence.
5. A cleanup failure is a visible run failure or manual-review state.

Run Identity

Each run records:

• immutable LTI run and execution IDs;
• scenario and suite versions;
• source repository and revision;
• target environment;
• start and completion timestamps;
• a unique synthetic identity derived from an approved test mailbox;
• created campaign, member, donation, provider, and synchronization identifiers;
• cleanup state and evidence.

Do not use personal employee or supporter addresses as synthetic identities.

Campaign Fixtures

• Acceptance petitions and donation forms use [ACCEPTANCE] labeling or an equivalent visible acceptance notice.
• Public campaign text and images may be reused; supporter/member data may not.
• Shared campaign fixtures are versioned and retained until a replacement is verified.
• Before bulk reseeding, create and record an acceptance database backup.

The current baseline contains 450 seeded acceptance petitions and 90 sandbox donation forms across 30 production segment definitions. Backup 1784327649439 predates that seed.

DR Tokens

• Generate or obtain DR tokens only through the acceptance member flow.
• Persist only the existing approved hash or redacted representation.
• Never put a raw token in logs, screenshots, URLs stored as evidence, Asana, or reports.
• A scenario may hold a raw token in process memory only for the bounded step that requires it.

Donations and Providers

• Use provider-specific synthetic identities; do not share Stripe and GoCardless credentials or silently fall back between them.
• Correlate by run start time, synthetic identity, amount/currency, provider, and returned provider identifier.
• Use test-mode or sandbox credentials from Secret Manager.
• Do not issue an automatic refund, cancellation, or mandate deletion unless that provider's approved cleanup contract explicitly allows it.
• Retain provider sandbox identifiers in redacted evidence for investigation.

Cleanup Order

1. Stop any active browser/provider step and record terminal evidence.
2. Complete provider-specific cleanup only when explicitly supported.
3. Remove exact acceptance member/signature rows only after verifying the unique synthetic email and creation window.
4. Remove run-owned temporary files and local browser state.
5. Record complete, partial, manual_review, or not_applicable cleanup status.

Broad SQL deletion, table reset, truncation, wildcard email deletion, and production cleanup are prohibited.

Retention

• Browser diagnostic files generated by scheduled Selenium/browser checks, including files in the configured screenshot and browser log directories: 28 days.
• Agent API AgenticQARunArtifact records, including redacted screenshot and log evidence uploaded to a run: retained with the owning run indefinitely under the normative LTI contract.
• Run summaries, scenario versions, and provider identifiers: retained indefinitely until an approved archival policy replaces compatibility behavior.
• Shared acceptance campaign fixtures: retained until a verified replacement.
• Raw secrets, authorization headers, payment instruments, and DR tokens: zero durable retention.

Recovery

If seeded acceptance content or schema becomes invalid, stop mutable runs, create a fresh backup if the database remains coherent, and restore the last verified acceptance backup. Restoration requires operator approval and must verify database identity before execution.