Jasper Addyman

A bulk import can finish without errors and still leave the wrong prices or stock counts behind. This original Sheetstead Studio demo shows how to check a staging export against the agreed catalogue changes before release.

What I built

A read-only Python check compares three CSV exports by SKU: the baseline, the approved changes and the updated staging export. It reports expected and observed values for missing or unexpected products, unapproved changes and mismatched approved prices or stock counts.

What I verified

On fictional data, two of four approved changes matched at first and five exceptions were flagged. One SKU should have had 15 units but still showed 12. After the corrections, four of four approved changes matched and the recheck found zero exceptions across eight expected products.

This is an AI-assisted studio demonstration. It uses fictional files and makes no changes to a live store. The results were checked against known fixture values.

[View the audit results and before-and-after comparison](https://www.twine.net/signin

An original Sheetstead Studio example of what happens when a destination has saved an invoice but the caller receives a timeout. Retrying a request should recover the result without creating another invoice. All data is fictional.

What I built

A nine-node n8n workflow validates amounts, uses stable invoice keys and sends requests to a Python fixture API. The API stores each key and amount in SQLite. It returns the stored result for an exact replay and flags a conflict when the amount changes. The workflow caps retries at three attempts and records rejected or exhausted cases separately.

What I checked

I ran all eight cases twice in n8n 2.47.3, restarting the fixture API between runs. Independent database checks found the same three records and £454.00 in fictional invoice amounts after both runs. The tests cover duplicate keys, changed amounts, HTTP 429 and 503, a gateway timeout after a committed write, permanent rejection, exhausted retries and invalid input blocked before a request.

This is an AI-assisted engineering sample, not a client deployment. The HTTP failures are controlled test cases; real transport failures and production monitoring require separate handling.

[See the workflow, source files and verification results](https://www.twine.net/signin

An original SQLite demonstration using fictional billing and product records for one month.

The brief. Reconcile monthly recurring revenue to an independent billing total, and identify problems that could distort product metrics.

The method. I matched product events and subscription records by account, normalised annual billing to monthly amounts, and removed exact duplicates. The audit keeps revenue independent of event volume, excludes trial starts from product activity, and flags conflicting IDs and missing or unknown account keys.

The result. October recurring revenue reconciled to $250.00 with zero variance. The sample contains three paying accounts and two active accounts. It flagged one duplicate billing row, one duplicate event and two events with missing or unknown account keys.

I tested the month boundary and confirmed that a conflicting event changes the activity count without changing billed revenue.