Brad M. Lindsey
Master Electrician, DoD / DHA · Master HVAC Tech · independent engineer
I build software the way I wire a panel — every claim labeled, tested, and traceable to the evidence behind it. The discipline that keeps it honest is open source.
The short version
Twenty years in the trades taught me one rule that doesn't bend: what's behind the wall has to do what the paperwork says. Switchgear, building automation, VFDs, federal facilities — work where a wrong label isn't a typo, it's a hazard.
I sat down with that rule and wrote my first line of code on April 4, 2026. Seven weeks later I had a few hundred thousand lines of Python, written alongside frontier models — and a problem worth solving. AI writes confident code, then writes confident documentation about that code, and the two quietly drift apart. By month three you can't tell what's been built from what's been described.
So I built the part that keeps them honest — a small discipline that pins every claim to its evidence and refuses to let the story run ahead of the work. Then I open-sourced it.
The discipline, and what runs on it
One idea sits under everything here: a claim may advance only as far as its evidence. The discipline is that idea made into a tool. The three products are that discipline applied to work I know.
A small discipline that pins every claim to its evidence and won't let the description run ahead of the work. Open source, stdlib + numpy only. Under the hood: hash-sealed stages, a six-state proof ledger, and numerical checks at intake.
For mission-critical facilities: every recommendation stays tied to the evidence that triggered it, so "why did you do that?" has a reconstructable answer instead of a remembered one.
Field captures land bound to the operator who signed them, checked against the relevant NEC article with the code section cited alongside the finding. Built on the licensed side of the trade, not scraped from a manual.
Deterministic pathing for the built environment — same inputs, same path, every time — with the inputs behind each route carried alongside it, so any recommendation can be re-derived rather than trusted.
How a claim earns its place
Every claim I publish carries exactly one of these states. The ledger is monotonic — you can't jump ahead to a state you haven't reached. Tap one to see what it means.
A claim starts as an idea and only moves forward when the evidence does. Tap a state above.
Live example — my PT-1 phononic test currently sits at artifact-generated. The print exists; the acoustic measurement doesn't yet. So that's exactly what it says. Either outcome is information.
Expert data & model evaluation
I take on AI-training and evaluation work — preference ranking, expert annotation, red-teaming, and judging model output in regulated technical fields where a confident wrong answer has a real-world cost.
What I bring is a combination that's hard to source: a licensed Master Electrician and HVAC tech with two decades of federal-facility experience, who also works inside LLM pipelines every day and documents every step. The data arrives proof-stated and verifiable, not just asserted — which, for this kind of work, is the whole game. (Department of Defense / Defense Health Agency work at the credential level; facility specifics stay private.)
Per-project or ongoing. Start a conversation →
Writing
A companion arXiv preprint is in progress — Phase-Chain Freeze and Closed-Form Re-Route: a Discipline for LLM-Collaborative Engineering with Cryptographic Provenance. Forthcoming.
Longer pieces go on LinkedIn. Author of record: ORCID 0009-0004-6392-2720.
Work with me
I take on a small number of advisory and evaluation engagements — teams putting LLMs to work in regulated, high-stakes environments, where a confident wrong answer carries real cost. The provenance discipline applied to your pipeline, not a deck about it. Reach out and tell me what you're building.