The 2014 Foundry System: How a Derivation Chain Actually Gets Built

In 2014, HSA's founder built the core of a production tracking and item-master system for a foundry, working from a legacy COBOL data export. It covered daily production records by material and machine, a KPI dashboard (melting weight, moulds per hour, productivity), and a master catalog of parts, patterns, and tooling — built in Excel and VBA, without any formal software background at the time.

The financial side of the system — machine-level profitability tracking — was removed by the business before the founder could keep a copy, since it was the company's proprietary data. What remains is the structural design: how the system modeled a part and its production separately, and derived nearly everything from one measured fact.

A cast part's weight — nett and gross — is a single measured fact. A greensand recipe fixes the ratio between mould volume and metal volume; density connects mass to volume on both sides of that ratio. Summed across every mould on a machine, that gives material usage. Counting moulds gives machine time. Machine time against headcount gives productivity. None of it required separately measuring five different things — it required one measurement and the physical ratios already built into the process.

That reasoning pattern — described in full in "The Derivation Method" — is the same one that, roughly a decade later and in an entirely different domain, produced TenderMatch.

This system predates any AI-assisted development by about a decade. It's the clearest evidence that Constraint Engineering isn't a framework HSA's founder read about and adopted — it's a reasoning pattern he arrived at independently, under real operational pressure, before it had a name.