Technology · Discipline

Evidence-gated acceptance

A capability counts only when evidence shows it wired and exercised at runtime, and the gates say what is still unproven.

HelixFAFO Core and Function ForgeAuth and access plane
Three states, three kinds of evidence proven liveproved by a live sessionwired at runtimeproved by a runtime traceimplementedproved by unit testsA mocked backend, an agent's report or a document stops below the top rung.
  • 55 of 55Rust tests passed by the meeting tools, kept open until their runtime gates passed
  • 47integration tests that list what they leave unproven
  • ~9,000lines of hardening modules built, and kept apart from what guards requests

Three states, each with its own evidence

AI engineering teams produce plausible claims that something works, and live tests in a real Microsoft tenant are scarce, so I set Helix a strict vocabulary. Unit tests prove a thing is implemented, a runtime trace proves it is wired, and a live session proves it works in the meeting. Every meeting action moved through those states, and nothing counted as complete until its live gate passed; the second-generation meeting tools passed every Rust test and every stage test, and I kept them open until the live gates passed.

Where Microsoft's platform has no supported path, the action fails closed and says why.

Microsoft's platformsee raised handscall on peopleraise its own hand"hand mutation unavailable"
No supported path means a typed refusal, never a pretend success.

When a voice change let the model promise a delegated action without calling the tool, the change did not pass its real-model gate, and the failed gate stays in the history because it tells me something true about the system. The integration suite for the Teams working service, on synthetic model executables, lists what it leaves unproven: Teams-tab sign-in, and a submission from Teams or by voice.

A mocked backend never counts as proven live.

See A meeting attendee that will not fake it.

Documents audited against the code

Design documents drift from code, and a document I trust more than the code is a liability, so I had the systems of FAFO Core and Function Forge re-documented from the code into dossiers with drift tables that set each claim against what the code does. When they disagree, the code wins.

documentsthe codewhere they disagree,the code wins
Row counts illustrative. The first Function Forge passed its own fifteen-point check and generated code that did not compile; that self-audit drove the second design.

See Tools that build tools, under governance and 196 deadlocks to zero.

Built is not the same as guarding

Security code that sits off the request path protects nothing, so for the Auth and access plane I keep what is built separate from what guards requests. A hardware-key login variant is a separate entrypoint.

requestNGINX · TLS · rate limitslocked-down service unitserving handlerhardening library · built, off the pathnever consulteda person approves each grant on the consent screen

See The hardening fix that locked everyone out. Across voice, meetings, an execution substrate and an auth plane, I hold my own systems to the standard I would hold a vendor to.