We didn't start from a requirements document — those describe what people believe happens. We asked for the real working files instead, and received 73 documents. 22 held real data; 21 were blank templates. That split was itself the first finding: a blank template tells you how a factory intends to manage something; the filled ones tell you how it actually does. The two rarely agree.

Then we built a glossary of their own vocabulary — every word used on the floor, mapped to what we understood it to mean, handed to each department head to tick or correct. We put 65 open questions to them, and got 65 answers.

We did not simply believe the answers. Each was re-checked against their own records. One stated payroll formula was verified across 4,598 piece-rate records — it held up, and in passing exposed six tiers of guaranteed hourly wage that everyone used in practice but that existed in no master data anywhere.

Two departments also gave us opposite answers to the same question — is a 13.7% defect rate normal? Production said yes, quality said no, and neither knew the other disagreed. Meanwhile the order master, goods in and out, outsourcing notes, statements and receivables existed only as empty templates: the order chain had a beginning and an end, with nothing joining them.

The ontology came first: 29 tables with effective dating, historical snapshots, and employment identity split into two dimensions. One decision shows why this step exists — job type belongs to the work, not to the worker. A person is not "a flat-machine operator"; a task is flat-machine work, and the same person may do three kinds of it in a day. Model that the wrong way round and payroll becomes unfixable two years later, long after anyone remembers why.

The client signed the ontology off before we wrote a line of application code — all 65 questions closed, version dated and confirmed. Correcting a misunderstanding at that point costs one line of a document.

Architecture followed from it: layered, with a single payroll service that is the only place in the system where money is ever calculated. Daily output and order progress are derived, never re-keyed — which is precisely what kills the triple entry rather than merely speeding it up.

Each module is built against the ontology and must pass 31 automated gates before it counts as done — covering validation, permissions, money masking, concurrency and workflow state.

One gate tests the other gates. It re-injects the original defect each gate was written to catch and fails if that gate stays green — because a gate turns green when the product is fixed, and it also turns green when it has quietly gone blind. One of ours silently stopped checking 60 fields and kept printing green; only a manual recount caught it. A ruler nobody re-checks is not a ruler.

On top of that we run multi-role QA: reviewers playing production controller, storeman, inspector and accountant, walking the real product through a browser the way those roles actually would.

Sandbox first, proven with their real history loaded — 8,721 piece-rate records migrated, so the system opened with their past already in it rather than with empty tables. The interface ships in English, Simplified and Traditional Chinese, because the floor, the office and the customer don't read the same one.

Production reporting moved to scan-and-report at the workstation. One scan now produces what three spreadsheets used to: the daily report, progress against the order, and the payroll line. The re-keying isn't streamlined — it stops existing.