AGILEDATAWAREHOUSE SYNTHETIC WORKFLOW REVIEW
Local rehearsal and handover notes | 22 October 2026

Start
Extract the ZIP to a local folder. Use Python 3.10 or later:
    python run_rehearsal.py
No third-party packages, credentials, Google Cloud or network access are needed.
The runner overwrites only its own evidence files under ./evidence.
Inspect engine.py before running. This is a local correctness demonstration.

Source contract
Every change contains a stable order_id, UTC updated_at, positive integer
source_version, event_day, integer amount_cents and operation UPSERT.
A version has exactly one payload. Versions do not decrease update timestamps.
Source updates must advance updated_at for timestamp extraction to be complete;
if that cannot be guaranteed, use an agreed CDC cursor or overlap/reconciliation.
Deletes, simultaneous writers and unknown source mutation rules are outside this model.
The expected snapshot is manually specified in expected.json, independently of engine.py.

Evidence and finding references
E01 fixtures.json: six fictional source versions across four order keys.
E02 expected.json: independent expected current state, four rows, GBP 1,020.00.
E03 evidence/baseline.json: event-date filter plus append/retry yields five rows,
    GBP 1,300.00 and stale A/B versions. Those are local fixture results, not lost revenue.
E04 evidence/candidate.json: contract-aware candidate equals E02.
E05 evidence/checks.json: twenty executed local checks T01-T20.
E06 candidate_bigquery.sql and job_evidence_query.sql: unexecuted design templates.

Failure and recovery rehearsal
T14 injects failure before publication; rows and checkpoint remain unchanged.
T15 injects failure after publication and before checkpoint acknowledgement;
retry reproduces the same rows then advances the checkpoint.
T16 restores an in-memory snapshot of both data and checkpoint.
These tests do not prove BigQuery atomicity, Composer retries or live recovery.

Production validation plan for a separately agreed implementation
1. Source owner confirms version, timestamp, deletion, immutability and late-data rules.
   Pin Composer/Airflow/provider versions and the actual billing/region configuration.
2. Freeze the baseline, source snapshot, selected runs/job IDs and business control totals.
   Record approved access, cost cap, environment, deployment approver and rollback owner.
3. Read-only review may use sanitised exports. A client administrator may execute the
   evidence query. Direct job-metadata access needs jobs.listAll and jobs.create;
   execution can incur query charges and does not confer permission to change tables.
4. In an isolated client test dataset, load representative immutable batches. Reconcile
   complete rows and keys against an independent full snapshot; run negative tests.
   Compare recurring runtime, bytes, slot usage and cost under the actual billing model.
   All of these remain unexecuted in this rehearsal.
5. Rehearse boundary/overlap extraction, immutable batch storage, failed writes,
   lost acknowledgements, delayed updates and recovery on the installed Airflow version.
   Keep one active writer. Configure explicit logical intervals; do not use now() for data.
6. Before production, rehearse data and checkpoint restoration, downstream publication
   and approvals. Do not restore only one of data/checkpoint; a mismatch loses updates.
   Pause the affected workflow only in an approved window. Retain the known-good code
   and snapshot; confirm restoration permissions and the agreed retention window first.
7. Release only after the owner approves parity, freshness, cost envelope and rollback.
   A mismatch, unhandled delete, unsafe timestamp rule or budget breach stops release.
   Restore the approved snapshot/checkpoint and code under owner control if required.
8. Observe the agreed number of scheduled cycles; inspect control totals and freshness.
   Sign off documented known limits, ownership, access revocation and data deletion.
   Planned care, alert tuning or wider refactoring require a separate agreement.

Access and data handling
Start with approved metadata and redacted code only; no business rows are required
for initial triage. Choose client-run exports or isolated work inside their environment.
Do not email credentials, embed secrets or copy unrelated projects. Record each export,
purpose and expiry; access is time limited and removed by the client administrator.
Agree deletion of working exports at handover and record completion; legal retention
for contracts/invoices is separate. A real engagement specifies the actual dates.

What the package does not establish
No customer work, measured cloud saving, production deployment, workload benchmark,
Airflow/Composer scheduling, live SQL execution or professional delivery time is implied.
There was no real acceptance, invoice, payment or follow-up to a client.
