Sydney, Australia. Twenty years in enterprise pre-sales and solutions architecture, most recently as a Customer Success Engineer at Databricks. Master of Engineering (Data Science), University of Sydney.
I spent two decades explaining other people's platforms to the engineers who had to run them. Storage, converged infrastructure, then data platforms. The work was always the same underneath: find out what a system actually guarantees, then say so plainly to someone who will be held to it.
I started out somewhere less obviously related. From 2003 to 2005 I was a QA/QC officer in a forensic drug laboratory, a classified environment running to ISO 9001, where I maintained the quality procedures and handled evidence under chain of custody so that results held up under federal and state law. Verifying GC-MS, HPLC and GC ion trap instruments teaches a specific habit: an unverified result is not a weak result, it is not a result at all. Most of what I design now is that habit in a different medium.
Python systems, designed and directed rather than typed. I specify the architecture, make the design decisions and review every line; an LLM agent does the typing. That split is the interesting part, and most of what I have learned in the last year is about where it fails.
The recurring problem is that generated text is fluent whether or not it is true. Fluency is not evidence. So the systems I design put the check outside the model:
- Claims trace to a source. Nothing reaches a document unless it maps to a verified entry.
- A scripted lint gates every draft. A rule nothing enforces is a rule that decays, and I have the commit history to prove it.
- The reviewer holds no write access. A reviewer that can edit its own findings will.
application-doc-toolkit is the public piece of this. MIT licensed.
I put the enforcement in the repository rather than in a convention people are asked to remember. This is not enterprise release engineering, it is CI-style discipline applied to personal projects:
- Pre-commit hooks that actually block. A documentation drift check wired into
pre-commitrefuses a commit whose docs contradict the code. Bypassable on purpose, never silently. - A test harness that fails on an untested script, not only on a failing test. Adding a script without its suite is a build failure by design, which is the only version of that rule that survives contact with a deadline.
- A scripted linter on the shell itself, added after I measured that the severity floor I had chosen was letting the commonest real bug class through unreported.
- Containerised integration tests — a Docker-in-Docker run exercising a full deployment stack end to end, image build through encrypted-volume mount, write and authentication, before it is trusted with real data.
A personal archiving project, designed around the evidentiary question rather than the storage one: not do I have the data, but can I show it is the data I captured.
The chain is SHA-256 content hashing, a chained custody log so an entry cannot be altered without breaking every entry after it, and Merkle-root anchoring over the set. It was designed with legal evidentiary standards in mind — chain-of-custody integrity, tamper evidence, verifiable provenance. It is not audited or certified against any named framework, and the documentation says so before it says anything else: the evidence-chain reference opens with a section titled What the chain does NOT verify. A tamper-evidence design that oversells itself is worse than none, because someone will rely on it.
Two things I would point at over the code. The design is documented for two audiences with a declared precedence rule, including a plain-English derivation for a legally-trained but non-technical reader, with the technical source stated as the winner on any conflict. And diagramming the custody model is what exposed its worst defect: the digest recorded when a capture happened but not what was captured. The diagram found it. Reading the code had not.
Private repository, access on request.
"Opportunities, Risks, and the Tension Between Privacy and Public Interest During the COVID-19 Pandemic" — Medium, Trends in Data Science, 2020. Where public interest should and should not override individual privacy, and the four conditions I would want met before accepting automated data collection.