I'm a systems engineer in a public safety environment. The systems I keep running are the ones people reach after something has already gone wrong, which sets a different bar than most IT work — the failure isn't a bad quarter, it's a call that doesn't connect.
My work sits in three places: the network and virtualization layer under emergency communications, the security posture around it, and the practical question of where AI belongs in systems that can't afford to be confidently wrong. What I keep returning to are the failures that don't announce themselves — degraded service that still passes an availability check, a vendor dependency nobody inventoried, a monitor measuring the wrong layer entirely.
I run my own infrastructure for the same reason: local inference stacks, self-hosted services, hardware I own end to end. It's the only way to see how something actually fails rather than how the documentation says it will.
I write that up as field notes at blog.theknowngood.com, and maintain a reference dataset on AI model evaluation at theknowngood.com.
Licensed amateur radio operator, KO6JKE. Troubleshooting an RF path and debugging a network stack are closer than they look, and both matter most when the usual channels are down.
Available for
Conversations and technical deep dives on emergency communications resilience, infrastructure auditing, AI governance in regulated environments, and self-hosted architecture.