.svg){kind=icon}
Justin Noggle | Senior Software Engineer at Torch.AI
I am a software engineer. Every day, my team and I build complex edifices of code and interconnected systems. It is a deeply held passion, and we are proud of the work that we do.
Yet I keep my distance from that complexity when I'm able. I use paper notes, physical books, and vinyl records. The simplicity of physical interfaces gives me room to think, and that has deep parallels in how we design systems at Torch.
The best dinner experience I've had wasn't served with a three-page menu and every ingredient in the kitchen listed for my perusal. It was at a small place, with a short menu, that declared firmly "No Substitutions". When I take a bite of a well-crafted dish, I can appreciate all of the work done by the chef and their team to cut out all but the essential textures, flavors, and aromas.
I want my users to have the same experience when they bite into my software.
There is an assumption, sadly, pervasive across government interfaces, that the amount of features a piece of software exposes is a direct measure of the capability it delivers. A screen full of buttons and a workflow full of clicks are taken as proof of "serious software." The assumption runs in the other direction too: a sparse interface reads as unfinished, or unambitious. Requirements get written as if every ounce of optionality preserved and offered to the user is a capability delivered. This is backwards. Optionality is not capability. It is complexity pushed from engineering onto the user.
At Torch, we build software on top of sophisticated data ingestion and retrieval systems. These systems take in enormous, messy stores of institutional knowledge, generate vector embeddings and indexes against them, and make them searchable in ways that were not possible only a few years ago. The problem we pose to our designers and engineers is not how to expose that complexity to users, but how to absorb it.
Victor is my team's answer to that problem. It is a networked learning environment. Soldiers find each other in it, ask the questions they would otherwise have to ask down the hall, and answer them for the people who come next. A unit that fielded a system last quarter knows things the manual does not, and Victor's job is to put that unit within reach of the one fielding it tomorrow. The knowledge still moves between people. What the software does is widen the network those people can reach and keep what they say once they have said it.
Underneath that sits reasoning infrastructure built for this problem: a composable pipeline where every stage — how data is embedded, what domain it is bound to, how relationships between domains are defined — is explicit, measurable, and traceable back to the source that produced it. The AI layer we build on top of it can retrieve, synthesize, and route a question without a soldier ever needing to know which body of knowledge held the answer, and without losing the thread back to where it came from.
Victor is the layer a soldier actually touches. Everything that follows is drawn from building it: the decisions we made, the arguments we had about them, and the things we deliberately chose not to ship.
The people using sophisticated software live and work in the physical world, under time constraints. They are, technically, operating an AI platform. They should never have to think of it that way. Technology has a pernicious habit of inserting itself into every corner of a life, and software built for this domain has to resist that habit rather than indulge it. The measure of our work is not how much of the system a user comes to understand, but how little of it they ever need to.
Simplicity of this kind is defensible only when the layers beneath it are inspectable. Software can reason things on a user's behalf precisely to the degree that inferencing can be traced back through the transformations and configurations that produced them, to the source material they rest on. Where that foundation is absent, absorbing complexity is not simplicity. It is concealment. In a domain where decisions can carry dire consequences, concealment is a catastrophic failure mode.
Every design decision comes down to a single question. Who carries the complexity? The people who build the system, or the people who use it? The lessons that follow are four answers to it.
I recently had the opportunity to speak with retired Lieutenant General Milford Beagle Jr. In a presentation concerning leadership, he explained that what leaders desperately need is the time to plan and the space to make decisions. Too often, in the initial stages of a mission, warfighters spend their time fighting their tools, leaving an increasingly compressed space to understand the mission context and very little time to choose the best course of action.
Every day, across our military, a unit takes delivery of a system it has never operated before, and someone must get it onto the network, into the training plan, and into the hands of soldiers who will depend on it. The manual runs to hundreds of pages and describes the equipment as it was designed to work. What that soldier needs is what the last three units to field it learned the hard way, and there is no repository for that.
They should not have to identify the correct repository, search the right set of documents, learn to operate an AI interface, or track down the one person in their unit who knows a guy who knows a guy. The job isn't "use an AI knowledge platform." The job is to get useful data, knowledge and trustworthy reasoning support, and get back to mission preparation. That sounds obvious, and yet it is routinely lost in how military software gets specified and built.
The discipline is to listen for the problem underneath a requested feature rather than the feature itself. In large part, that means paying close attention to the workarounds people have already built for themselves, including what I refer to as the military whisper track: when someone needs to know something, they do not dig through a repository. They ask a person who knows another person, who knows. This is not a cultural quirk or a deficiency to route around. It is a signal, and it should shape the design of a system.
Framing interfaces around what job the user is trying to accomplish has an enormous positive impact. Design around the progress a person is trying to make, not around the technology we are excited to have built. What a user asks for and what they are actually trying to accomplish are very often two different things, and only the latter matters.
Victor's requirements start there, at the job, and are held to it. Every feature in the product has to trace back to a question a soldier was already trying to answer, usually by asking somebody else.
Victor looks, deliberately, like a social media feed. It has a feed, posts, comments, votes, topics, and profiles. All things soldiers are already familiar with.
That is not an accident, and it is not a lack of ambition. It is a decision to leverage a mental model people have already developed. Everyone knows how to write a post. Nobody needs to be taught what a comment or an upvote is. What they do not need to know, and what they should not have to know, is how that post operates within the larger informational environment underpinning it.
Underneath Victor's familiar surface lies real complexity: retrieval-augmented generation, embeddings, semantic search, knowledge domain routing, model selection, ranking, and authentication infrastructure. None of it goes away. It is just not given to the user as their problem to solve.
The governing principle we hold ourselves to is that every button is a decision the software is asking the user to make. If the system can make that decision safely and predictably on its own, the button does not belong there. Progressive disclosure, familiar mental models, and reduced cognitive load are engineering rules here.
It is worth being precise about what "safely and predictably" means. It means the reasoning is deterministic given the same inputs, that its basis is recorded and reviewable, and that it never silently crosses a boundary of classification, authority, or provenance that a human would have needed or wanted to weigh. Reasoning that fails any of those tests does not get absorbed. It stays visible, and it stays with the person who is accountable for it.
Where absorption is legitimate, the leverage it produces is substantial. A single post inside Victor can activate doctrine retrieval, AI-assisted synthesis, community expertise, topic and social relationships, search indexing, feedback signals, and institutional memory. A single search field combines semantic and traditional search without ever asking the user to choose between them. AI generated responses appear as part of the discussion itself rather than as a separate chatbot bolted onto the side of the product.
The point is not that Victor contains sophisticated technology. The point is that the technology increases the value of actions users already understand how to take.
That distinction matters more here than it would in a commercial product. Military doctrine is dense, dry, and genuinely difficult to parse and apply. Reading it feels closer to working through a technical manual than reading Clausewitz or Sun Tzu, and AI-assisted synthesis helps meaningfully with that gap. But community expertise, or in this case, soldiers helping soldiers directly, is the more important half of the equation, not a secondary feature sitting next to the AI. The technology's job is to amplify that community, not to replace it.
That is also how knowledge compounds. The fourth unit to field a system does not have to start where the first one did.
A soldier reading a response needs to know immediately what kind of answer it is: official doctrine, organizational guidance, a lesson learned, or one person's individual experience. Those are not interchangeable, and a platform that treats them as such has failed.
Provenance and citation are therefore first-class design concerns rather than afterthoughts. Authoritative knowledge and community knowledge are clearly distinguished from one another. Recency matters. Applicability matters. The platform must actively support feedback and validation rather than passively hosting content.
Human judgment and command responsibility are complicated, and they are not something software should try to automate away. The system needs feedback from individual soldiers on the ground, and it needs a clear channel for commanders and leaders, whose words should carry weight. This is not a technical nuance. In every conversation I have had with military leadership, at every level, the message has been the same: nobody wants AI to make the decision. They want AI to enable the person who makes it.
That is why AI is deliberately kept in a supporting role throughout Victor. AI should shorten the distance between a question and relevant knowledge. It should never obscure where the answer came from.
Trust also has an unglamorous dimension. Identity, classification markings, and audit are usually filed under compliance, but in this domain, they are provenance concerns wearing different clothes: they govern who can see a thing, what authority it carries, and whether anyone can reconstruct how it got there. Treating them as constraints the design accounts for from the start, rather than as problems to solve once the product exists, is the same discipline applied one layer down.
Four lessons, one answer. The complexity belongs to the people who build the system. Judgment, authority, and accountability stay with the person accountable for the outcome, but the complexity is ours to carry, and every ounce we decline to carry is paid for by someone with less time than we have.
The question of who carries the complexity has a second half. Why would anyone volunteer for it?
We could work in another field. It would be easier to build software for commercial users. The same engineering ideals transfer cleanly to other domains. The stakes would be lower, the pressure lighter, and the markets would be bigger. Understanding the problem would be much easier.
We do not.
The work we do here has a multiplicative effect on the world that is hard to find elsewhere. Our country's economic viability and the freedom its citizens enjoy rest on its ability to keep peace. That ability rests on soldiers who are given the capacity to adapt, the space to understand problems deeply, and the time to make critical decisions. We can offer these things to warfighters by being mindful, attentive, and absorbing the complexity ourselves, upfront.
Done well, none of that work is visible. A soldier asks a question, finds an answer they can trust, and gets back to preparing for a mission, never having seen the kitchen.
Torch is a reasoning infrastructure company.
We design and deploy complete, mission-ready capabilities that transform fragmented, multi- source data into coherent understanding at machine speed.
By building ahead of need and delivering off the shelf, we compress the path from idea to operational impact from years to weeks.
Latest updates, insights, and field reports from across Torch.AI.
Trusted AI for critical missions.
Exploring the reasoning systems, data infrastructure, and AI methods
Building sessions and education for mission-ready AI.
The latest company updates, product releases, and mission milestones.
