AI but make it real
The demo always works. I show you what happens after.
Amelia Saxton
Getting a model to write the code is easy now. Getting a system to say what it cannot do is the entire job, and it is the part almost nobody builds.
So that is what I build, and this is where the receipts are. The gate that caught my own build lying to me three times. The one character typo that inverted the only guarantee a component had. The three features I cut because a browser cannot honestly deliver them.
No hype. No screenshot of a demo that worked once. Real builds, named defects, and the parts that broke.
The builds
All of it mine, built outside any employer, on my own machine. Every claim below ties to a file I can open in front of you.
agent-mesh
A governed message bus for multi-agent teams
A message bus is easy. A message bus that can prove what it refused, and why, is the thing that survives a security review. Every message is a file, every delivery is checked against policy before it lands, and every decision the governor makes is written to an append-only ledger.
- Fails closed by construction. A message is delivered because a rule said yes, never because no rule said no. An empty policy denies everything, and a gate proves it.
- Zero dependencies. No package has been installed to run it: three Node builtins, no lockfile, nothing vendored.
- Three gate suites green, run end to end through the real command line interface in a throwaway directory with exit codes asserted.
- I had it adversarially reviewed and it found six real gaps. Two are fixed and pinned by fourteen new regression checks. The other four are written into the README as named defects, because a claim a project cannot back is worse than a missing feature.
- The best of those: the allowlist failed OPEN if a policy field was written as a string instead of an array, because "deliver".includes("deliver") is true. A one-character config typo inverted the one guarantee the component exists to make.
Command Center
Handwriting-first notes and an operations dashboard
A single self-contained HTML file. No build step, no server, no account. Handwriting with real pressure, notebooks and sections, and a loops module that reads a locally built snapshot.
- Everything lives in the browser on the device. Nothing is sent anywhere, which is a deliberate constraint rather than a missing feature.
- Because that is true, the app nags for an export and says plainly that clearing site data destroys the notes.
- The publish step runs a disclosure check that prints exactly what personal detail is about to go public, and refuses to release a credential no matter what flag you pass it.
- 14 of 14 deploy-guard checks green, verified 2026-08-06.
Two offline family apps
Case study in gate discipline
Two single-file offline applications built for my own household. The apps themselves stay private, so what follows is about how they were built rather than what they contain.
- 2,361 lines behind seven gate suites including a full browser end-to-end run, all green.
- Three features were cut because a browser cannot honestly deliver them: enforcing device screen time, syncing a reading library, and moving real money. Each limit is stated on screen instead.
- That was the interesting engineering. Every one of those had an easy version that demos well and then breaks in front of a user who was depending on it.
- A repeat-item bug was found by a purpose-built gate: 25 back-to-back repeats in 4,000 rounds before the fix, 0 after.
A governed operating system for AI assistance
The thing that runs all of the above
A working personal AI operating layer: persistent memory, always-on rules loaded every session, tiered approval by blast radius, adversarial review councils, automatic model routing, and packaged skills.
- Review gates that produce a dated receipt on disk, because a review with no artifact is an unverified claim.
- An advisory file-claim tool so concurrent agent sessions stop overwriting each other, with its own limits documented rather than oversold.
- It is advisory, single-filesystem, and has a residual race. That is written in its own documentation, not discovered by a user.
The rules
Not values on a wall. Each one is a gate that has stopped real work of mine from shipping, and every one of them exists because I got burned first.
Foundation before scale
Write the model of how the thing actually works before building against it. If I cannot write it down, I am not ready to build. This rule exists because I lost a week to three builds that each started before the base case was nailed.
Prove it on one
Before trusting any result over a population, run one named case end to end against an independent source. Not the tool's own output. Not a mirror of my own logic. The real value from the real source.
Read the failures
A success rate is not a result until the failures are counted, bucketed, and the worst one quoted with its real values. A bare percentage is an unverified claim wearing a number.
End to end or it is not done
Load the page in a real browser and click it. Run the tool by its real command. Open the file and look at it. Unit tests prove the parts, not the product. I have shipped a build that passed every check and rendered broken text to the user, which is why this one is not negotiable.
State the limit in the product
Where a system genuinely cannot deliver something, the product says so on the screen. The alternative is a version that looks like it works and falls apart in front of the person counting on it.