Not a real shop — a practice environment for FlowRunner training
Flowland Seed Co. Practice shop

Answer keys

What is actually wrong with the data.

Write your report first. Several lessons ask you to find these yourself — reconciliation, the exception report, review moderation. Reading this page before you try turns an exercise into a copying task. Come back when you have something to check.

Flowland's datasets do not all reconcile — the same way a real shop's do not. This page lists every discrepancy, generated from the same script that generates the data, so it cannot fall out of step. Build your report, email it to yourself, then compare. The last section covers the eight orders the Order Replayer fires at your flow, five of which carry the kind of data that has to be handled.

Known mismatches

Generated by seed/generate.mjs. Do not edit by hand.

The discrepancies below are deliberate. They are the raw material for the

reconciliation, exception-reporting and debugging lessons — FR-106 in particular,

and the Run the Shop capstone, whose passing bar is that a learner's reconciliation

report finds every one of them.

They are also what a working shop's records actually look like: a payment standing

against an order that was cancelled, a shipment with nothing paid behind it. So if

you are here because the data does not reconcile — it does not, on purpose. Please

do not "fix" it. See CONTRIBUTING.md.

Dataset: 120 orders, 109 payments, 75 shipments,

34 reviews, 22 returns, 40 products,

30 customers.

1. Orders paid twice

Two successful payment records against one order. A reconciliation flow summing

payments per order finds more money received than the order was worth.

2. Payment succeeded, order cancelled

The order was cancelled but a successful payment stands against it, with no

refund. These are the ones that cost real money in a real shop.

3. Shipped with no payment

The order reached shipped but no payment record exists for it at all. Note

that the defect is an absence — a flow looking only at the payments dataset

will never see these. It has to start from orders.

4. Shipment for a cancelled order

A parcel is moving for an order that was cancelled.

5. Delivered with no shipment record

The order says delivered; the shipments dataset has never heard of it.

Another absence-shaped defect.

Lesser inconsistencies, also deliberate

and FLS-ALY-CARPET have in_catalog: false but appear on older orders.

Joining orders to the catalog on an inner join silently loses those lines.

CustomerEmail, while the clean dataset has it. The export is lossy.

"NULL" in shipping_cost, not as a JSON null and not as $0.00.

and padded with spaces. Grouping by status without trimming produces duplicate

buckets.

payment. These are not defects — they are what a real payments table looks

like — but flows that assume every payment succeeded will get them wrong.

Review moderation labels

Generated by seed/generate.mjs. Do not edit by hand.

Ground truth for the review-moderation lessons (FR-105, PB-23). The API at

/api/shop/reviews does not expose these labels — that is the point. A

learner builds a classifier, then scores it against this file.

The hard cases are deliberate. harsh-legit reviews are hostile in tone but

legitimate in substance; a classifier that removes them is wrong in the way that

gets a real shop in trouble. glowing and spam are both effusive and

five-star; tone alone cannot separate them.

normal — 10 reviews

Ordinary, measured feedback. Should pass moderation untouched.

glowing — 6 reviews

Genuine enthusiasm. Note that spam often looks like this to a naive classifier — separating the two is the lesson.

harsh-legit — 8 reviews

Negative, sometimes angry, but a real customer with a real complaint. Must NOT be removed. These are the ones that should escalate to a human.

spam — 6 reviews

Promotional or fraudulent. Should be removed.

abusive — 4 reviews

Personal attacks and hostility. Should be removed and escalated.

The Order Replayer

Generated by seed/generate.mjs. Do not edit by hand.

Eight orders you can fire at your own flow from /replay, as many times as you

like. 5 of them carry a deliberate data problem; the other 3

are clean orders that a naive flow still mishandles.

Every field is fixed, including event_id. Replaying an order produces exactly

the same delivery it produced last time, which is what makes "fix it and prove

the fix works" (FR-106.2.3) a real exercise rather than a hopeful one.

What is wrong with each order is announced on the page. Spotting which one it is

is not the exercise — finding the run that failed, and reading why, is.

rp-01 — A straightforward order

One line, a US address, every number consistent. The control. If your flow cannot get through this one, nothing the other seven tell you will mean much.

rp-02 — An order from Canada

No region, a letter-and-digit postal code, and country is CA. A template that prints {{region}} renders an empty line; a postal-code check written as five digits rejects a valid address.

rp-03 — A wholesale order, 24 lines

Twenty-four line items. Any step that reads line_items[0] and stops, or that builds a summary without a loop, silently reports the wrong thing rather than failing.

rp-04 — A line ordered zero times

A per-unit calculation — cost per packet, a weight average, a discount rate — divides by zero. Totals still add up, so nothing looks wrong until the division runs.

rp-05 — A SKU that is not in the catalog

Looking that SKU up returns 404. An HTTP Request block with no error handling ends the run there — the classic case for Handle Error (FR-102.4.1).

rp-06 — A total that does not add up

A flow that trusts the total charges the wrong amount and never notices. A flow that recomputes finds it immediately. This is the difference the reconciliation lessons are about.

rp-07 — A customer with no email address

Every step succeeds until the one that sends the confirmation. The run fails at the last block, having already done its work — the failure mode that is hardest to reason about from the outside, and the reason FR-106.2.2 exists.

rp-08 — The same order, delivered twice

A flow that acts on every delivery charges twice, emails twice, and ships twice. Recording the event_id in Shared Memory and ignoring one already seen is the whole of PB-15.