Engineering portfolio · Aotearoa New Zealand
Robin Huang
Full-stack engineer in Auckland, New Zealand. I build software for regulated industries — the kind of work where the rules are published, so you can check whether the code actually follows them. Every project here started as my own idea, built out of a genuine passion for programming and the software industry.
Ten platforms.
Built to be checked.
Trade, security, drinking water, energy, health and open finance. Each platform is built against the published standard it has to follow, then checked against that standard directly — not just against its own tests. They are small projects, built out of interest and worked on a little at a time. None has run in production. I would like to grow them into something real, and maybe one day into something an industry could use.
Full CV, résumé & contact live at robinhuang.nz ↗
How I check my own work
Three bugs the tests missed.
Each of these sat in code that was internally consistent and fully tested. Each still disagreed with the real-world rule it was meant to implement.
Drinking water · Taumata Arowai
A boil-water notice that could lift early
The stand-down gate counted clear lab results by the time they were imported, not collected. E. coli culture takes 18–24 hours, so a sample taken before the contamination is imported after it — and clears the gate. The common case, not an edge case.
WaterOps ANZ →
Tax · Inland Revenue
15% GST charged to a business not registered for it
Adding GST to prices is itself a registration trigger — an unregistered supplier may not do it. Every fixture in the repo was tax-registered, so the unregistered path was never exercised. The correct non-GST mapping already existed; nothing had ever routed to it.
TradeOps AI →
Margin · contribution accounting
Three engines agreeing perfectly on the wrong number
A TypeScript spec, a pure-Python port and a DuckDB transform reconciled to an identical contribution margin — and it was 52.5% too high. The revenue was GST-inclusive; every engine consumed it as ex-GST. Agreement is not correctness.
MarginFlow →
None of them came from a test. All three came from checking the code against the published standard it claimed to follow — drinking-water rules and GST law. Those standards are free and precise, which is what made it possible to check the code against them at all.
The GST rule, as a working tool.
Two of these bugs came down to one GST rule, so I built that rule into a small calculator anyone can use — open-source, tested, and correct on the edge cases.
The range
Ten platforms. One deep, nine at slice depth.
TradeOps is the deep one — a full quote-to-cash workflow with a sandbox-verified Xero integration. The other nine model their domains at vertical-slice depth. Each card below carries the label its evidence supports, so you can see how far any one of them actually goes.
TradeOps AI
Trade services · NZ/AU
Live Gmail IMAP · real LLM extraction · official Xero sandbox
ControlOps ANZ
Security evidence · M365
Live Microsoft Graph, consenting dev tenant — 92 observations
integration verifiedWaterOps ANZ
Drinking water · NZ
Live cross-service E. coli scenario against real PostGIS
integration verifiedGeoRisk ANZ
Spatial exposure · NZ
Real PostGIS · EPSG:2193 exact-area · least-privilege DB role
integration verifiedFactoryOps ANZ
Industrial telemetry · OPC UA
Independent OPC UA server → RLS ingestion
integration verifiedTrustID ANZ
Verifiable credentials
Out-of-process verifier over real public HTTP
integration verifiedOpenFinanceOps ANZ
Consumer Data Right · AU
Real HTTP/PKCE CDR journey vs an in-repo mock holder
simulatedMarginFlow
Commerce margin · data engineering
Python/DuckDB pipeline reconciling to the tested engine
syntheticEnergyOps ANZ
EV charging · OCPP
OCPP simulated — labelled as such
simulatedCareOps ANZ
Health data · NZ
Synthetic
syntheticHow it is built
Rules the code is held to.
Every merge gated.
Full suite, a Docker multi-scanner in strict mode, adversarial multi-agent review, green CI. Protected mains; immutable release tags — corrections ship as a successor version, never by moving a tag.
Unknown is never safe.
A missing cost is excluded from a margin, never zeroed. Partial evidence turns a check amber, never green. A sample with no collection time is excluded fail-closed.
Simulated is never reported as integrated.
A fixed vocabulary separates implemented / tested / integration-verified / official-sandbox-verified / simulated / demo-ready / externally-reviewed / production-validated — and nothing is promoted without the evidence for that word.
Stated plainly
What isn’t true of this work.
This is a portfolio in development, not a shipped product — so the limits belong up here, not in a disclaimer at the bottom. Even the gate that guards this work has not always agreed with reality, which is exactly why the checks above exist.
Not externally reviewed.
No practitioner outside the project has evaluated any of it. Self-review and AI review are not external validation and are never recorded as such.
Not production-validated.
Nothing has run in production or a pilot.
Not certified.
Reading a regulation is not conformance. The conformance work records a cited position with known gaps — 31 findings remain open and registered, four of them HIGH.
The scanner’s own gate failed open until recently.
An unrecognised category matched nothing, so a strict gate looked enabled while protecting nothing. Every prior “gate passed” was re-verified by measurement rather than assumed. They held — because no repository overrode the default. That check is recorded because the alternative, assuming, is how the three failures above happened in the first place.