Engineering lab
Good engineering
shows its working.
Explore an original, interactive example of the care that goes into a useful data workflow. Change the inputs. Inspect the result. See what happens when something goes wrong.
Data quality workbench
Browser-local demo · Synthetic samples
A small invoice dataset moves through parsing, validation and duplicate detection. Valid records become a consistent JSON output. Records that need attention keep a readable explanation.
Try adding a duplicate ID, removing a currency or changing a date. Use synthetic data only.
Nothing entered here is uploaded or stored by this demo.
| Record | Result | Reason |
|---|
The rules are explicit
Predictable behavior.
Explainable exceptions.
This is deterministic software. It makes decisions using the rules below, so every output can be traced to an input and a validation check.
Inspect the demo source ↗What makes a record valid?
All five columns are required: invoice_id, customer, amount, currency and issued_at. IDs start with a letter or number and contain only letters, numbers, hyphens or underscores, up to 64 characters. Amounts must be positive decimals with up to two decimal places, no greater than 1,000,000,000,000. This demo limit keeps cents consistent in JSON and CSV exports. Dates must be real calendar dates in YYYY-MM-DD format.
What is normalized?
Whitespace is trimmed, currency codes are uppercased, and amounts are converted to JSON numbers. This example accepts INR, AED, USD, EUR, GBP and SGD. Dates and IDs retain their meaning.
How are duplicates handled?
An invoice ID is a case-sensitive key. If an ID occurs more than once, every row carrying that ID is held as a duplicate. The demo does not guess which conflicting record should win.
What happens when CSV is malformed?
An unclosed quote, a missing header, a repeated header or a row with the wrong number of fields stops the run. No partially parsed output is silently accepted. Quoted commas, escaped quotes and multiline fields are supported. This small demo accepts up to 1,000 records and 200,000 characters.
What would a production version need?
Agreed source contracts, access controls, persistent processing history, monitoring, reconciliation and a recovery path. The sample rules here are deliberately limited. This demo is not accounting software and does not connect to a live invoice system.
Architecture walkthrough
The happy path is only half the system.
A production integration also needs to make failure visible and recovery intentional. This is an illustrative design, not a running backend.
Receive
Source contract
Event or file identifier
Validate & route
Schema checks
Duplicate policy
Write accepted records
Traceable destination updates
Hold for review
Reason, record and safe replay
A useful place to start
Your next project.
A clear first step.
Planning a website, custom software or an AI solution? Tell our team what you want to improve. We’ll help define a practical scope.
Discuss a project