Pipeline studio, retail orders
Retail orders pipeline
Pinned stage
01 Bundled event batch
Decision: Every batch is a versioned sample file with its hash in a manifest. The run refuses a file whose SHA-256 does not match the manifest, so a result can always be traced to exactly the rows that produced it.
Alternative considered: Fetching rows from a URL or letting the reader upload a file.
Consequence: Evidence stays reproducible and inspectable, at the cost of only ever running curated data in this version, guarding against a result nobody could reproduce because the input had changed or was never recorded.
In this run
Run a batch to see the rows this stage handled.
- 01Initial batch
- 02Follow-up batch
Runs the initial batch first.
- 03Replay follow-up
Runs the initial batch first.
Limits: up to 10 batches, 500 rows each, 1,000 accumulated facts, 2 MiB input, 30 seconds
Explore other fixed scenarios
Conflict with historical ledger resends an event from the initial batch with a different amount. If the initial batch has not run in this session, it runs first so there is history to conflict with.
The engine loads when you run the first batch. Nothing runs until then.
Preparing the local runner…
Saved browser run, follow-up batch, captured
- Input rows
- 7
- Quarantined
- 1
- Duplicates
- 1
- Unique valid events
- 5
- Inserted orders
- 1
- Updated orders
- 1
- Ignored events
- 3
- Fact rows
- 5
- Current order value
- A$245.00
3 of 3 checks passed
- Sample file load7 ms
- Worker initialization0 ms
- SQL pipeline101 ms
Total measured119 ms
Measured by the saved browser run, in the order the phases ran. Time between them is not split out.
Run a batch to trace each row to its source event and the stage that decided it.
Stage: event-batch, disposition: accepted
Receive the checked sample
The small initial.json sample enters the walkthrough as delivered rows, not as a live network event.
import hashlibimport jsonfrom pathlib import Pathdef load_batch(path: Path, manifest: dict[str, dict[str, str]]) -> list[dict]: raw = path.read_bytes() digest = hashlib.sha256(raw).hexdigest() if digest != manifest[path.name]["sha256"]: raise FixtureMismatch(path.name, digest) rows = json.loads(raw) if len(rows) > 500: raise BatchTooLarge(len(rows)) return rowsSaved run, checked against this build
The follow-up batch as a browser ran it on . It shows only while its build, SQL and sample-file hashes match this page. Your own runs fill Receipt and Data.
- Input event rows
- 7
- Quarantined rows
- 1
- Identical valid repeats
- 1
- Orders inserted
- 1
- Orders updated
- 1
- Stale/no-op events
- 3
- Current order facts
- 5
- Current order value
- A$245.00
3 of 3 quality checks passed for this saved run.
- Pass state fact reconciliation
- Pass daily mart reconciliation
- Pass nonnegative order amounts
Explore other fixed scenarios
Conflict with historical ledger resends an event from the initial batch with a different amount. If the initial batch has not run in this session, it runs first so there is history to conflict with.
The engine loads when you run the first batch. Nothing runs until then.
01 Bundled event batch
Decision: Every batch is a versioned sample file with its hash in a manifest. The run refuses a file whose SHA-256 does not match the manifest, so a result can always be traced to exactly the rows that produced it.
Alternative considered: Fetching rows from a URL or letting the reader upload a file.
Consequence: Evidence stays reproducible and inspectable, at the cost of only ever running curated data in this version, guarding against a result nobody could reproduce because the input had changed or was never recorded.
- Fetch sample file, not run
- Verify SHA-256, not run
- Init DuckDB-Wasm, not run
- Run SQL, not run
- Run checks, not run