On the Seam: Working Drafts · July 2026
The Zero-Fail Environment
My first real Air Force assignment was a console in a windowless building where “good enough, we still got there” was never a sentence anyone said. What it taught me about speed, creativity, and the failures you can't hear.
My first real assignment in the Air Force was with the 21st Space Operations Squadron at Onizuka Air Station in Sunnyvale — better known by its nickname, the Blue Cube. It was a top secret assignment, and I remember the first time I walked in: windowless, wide hallways on raised floors, every door locked behind a room number or a nondescript name instead of a sign telling you what was inside. Everything was new, sterile, and serious. In tech school, I'd misread the assignment and thought I was headed to Japan. I ended up in California instead, which was still enough of a different world from the Houston I grew up in. I was nineteen, and it was one of those experiences most people never get close to. I walked in knowing almost nothing about the world I'd just entered, in March of 1994. Six months later, I was qualified to work the console on my own, certified through an intensive on-the-job training pipeline that didn't care how green I'd been the day I arrived — only whether I could be trusted with the mission now. I'd stay through November of 1995.
The squadron's job was to run a piece of the Satellite Control Network — tracking, telemetry, commanding, and mission data retrieval for more than 150 Department of Defense, allied, civil, and national satellites, plus GPS ground support spread across the Pacific. During my tour, between March 1994 and November 1995, that meant supporting some real missions: the Inertial Upper Stage deployment that put TDRS-G into orbit off STS-70 in July 1995, the tracking alignment behind the first Shuttle-Mir rendezvous on STS-63 in February 1995 and the historic docking on STS-71 that June, and the orbital precision required for the Space Radar Laboratory flights on STS-59 in April 1994 and STS-68 that September. None of that worked without the ground configuration and scheduling my squadron held together.
That's a zero-fail environment. Not “low-tolerance.” Zero. You don't get partial credit for close.
There's no such thing as “good enough, we still got there.”
I think about that a lot watching how people talk about AI and enterprise systems now. The prevailing instinct is speed-first: ship it, see if it's wrong, iterate. And for a huge amount of work, that instinct is correct — it's how you find the good idea faster than the careful way ever would. But it breaks completely the moment you're in a no-fail domain. Nobody says “well, it was mostly right, and we still got a satellite tracked.” You don't apply that logic to an old phone system either — you pick up the receiver expecting a dial tone, every single time, with zero interest in hearing it worked 97 percent of last month. Some systems don't get graded on a curve. They get graded on whether they worked.
The mistake is assuming that means fail-safe thinking should just take over everywhere, all the time. It shouldn't. That's the part people miss.
Creative thinking can produce a fail-safe solution. Fail-safe thinking cannot produce a creative one.
Most people who are trying hard to be right stop being creative around the same moment they start protecting a position. They ideate until the fun goes out of it — until every new idea gets measured against “could this be wrong” before it's even been given room to be interesting. You have to loosen the thinking first. Let yourself genuinely explore the art of the possible, entertain the bad ideas next to the good ones, before you dial anything back in toward what's actually going to survive contact with a zero-fail requirement. Reverse that order — start from “what can't fail” — and you'll never generate the option that would have been both safe and good. You'll only generate the option that was already safe, which is a much smaller set.
That's the actual discipline the console taught me, more than the technical skill itself. Know which mode the moment calls for. Most enterprise AI work — the exploration phase, the prototype, the internal tool nobody's betting the business on yet — wants the loose mode. Something touching a customer account, a financial transaction, a safety system, a piece of infrastructure with no acceptable failure state — that wants the console mode, the one where you've already done your creative thinking upstream and now you're just executing against a standard that doesn't move.
The question I ask myself now is simple: what does it cost if this is wrong, and can I hear it fail?
A phone system fails loudly — no dial tone, you know immediately. A lot of modern AI failure is quiet. The output looks plausible. Nothing rings an alarm. That's the actual danger in treating every domain like it can absorb “good enough, iterate” — not that speed is bad, but that some systems fail silently, and silent failure in a zero-fail domain is the only kind that matters.
I didn't walk into that console at Onizuka understanding any of this. I walked in nineteen years old and scared. But six months of OJT teaches you fast which questions actually matter, and “did it basically work” was never one of the questions anyone was asking me. It laid a foundation I've stood on ever since — the first real proof that I could do anything I put my mind to.
Dr. Trey Harper writes on trust, legitimacy, and the architecture of the agentic enterprise at treyharper.com and in the LinkedIn newsletter On the Seam: Working Drafts. The views expressed here are entirely my own and do not represent the policy or position of my employer or any customer.