Within days, a sandstorm leaves a fine layer of dust on the optical sensor housing. Image quality degrades, false detections multiply, and the operators begin to distrust the alerts. The problem is not the algorithm. It is an environmental condition that didn't weigh in during design, because nobody who selected the housing had watched dust settle on optics in the field. Eventually the system is switched off, and personnel revert to manual surveillance.
This is a hypothetical scenario, but it is the one we return to most often inside FieldX. Understanding that failure does not require a better algorithm; it requires an understanding of the environment, and that understanding lives with the people who operate in it. Notice where the vulnerability entered. Not at deployment, and not in the model. It entered months earlier, in a design review, when a condition that seemed peripheral in the lab turned out to be decisive in the field. The housing looked like a procurement detail. In the field, it was the whole system.
Most technology companies, ours included, were raised on a simple doctrine: build a minimum viable product, ship it, iterate. In consumer software this works, because a failure becomes a bug fix in the next release. In defence, an update has a greater cost — often a life. The soldiers we build for are stationed at –40°C in Siachen, at +60°C in the deserts of Rajasthan, and in the dense jungles of the Northeast. Iteration still matters to us; we could not build without it. But iteration has to be informed by those environments, not driven only by release timelines.
So the question we keep returning to is not “how do we ship faster?” It is: what does it take to build systems that keep working under mud, dust, cold, heat and fear?
India’s AI infrastructure is expanding at remarkable speed. The IndiaAI Mission is putting tens of thousands of GPUs within reach of startups and researchers, with plans to scale capacity sharply over the next few years, while private players and global companies pour capital into local compute and cloud. All of this is necessary. None of it, on its own, changes what a soldier experiences at a border post.
Compute is storage; what reaches the field is delivery. In defence technology, the pipes between the two are processes — the ones that connect engineers, operators, designers, logisticians and researchers around the same problem, early and often.
From where we sit, India’s gap is not talent. We meet extraordinary people every month. The gap is that the talent rarely converges on the same problem at the same time. The hardware is arriving. The capital is arriving. Convergence is the part that has to be built deliberately, and it is the part we spend the most time on.
We did not invent this observation; we borrowed it. Across the innovation ecosystems we studied while shaping FieldX, one pattern recurs: breakthrough technologies rarely emerge from a single discipline working in isolation. They appear where cross-functional teams converge to build robust systems. None of the examples below were consumer companies chasing release velocity. All of them were building things that had to work the first time, far from the people who made them.
At Bell Labs, physicists, chemists, metallurgists, engineers, theoreticians and experimentalists worked in close proximity, with research, systems engineering and manufacturing feeding into one another rather than operating as separate functions. Ideas did not end as papers or patents; they travelled, through integration, into deployed systems, because every kind of expertise the journey required lived under the same roof.
Lockheed’s Skunk Works ran on small cross-functional teams, direct communication, minimal bureaucracy and empowered project leads. The point was never simply to build aircraft quickly. It was to rapidly build aircraft that performed in real operational conditions.
More recently, DARPA’s work on human–machine teaming has put AI researchers, human-factors specialists and operational experts in the same room from the start, designing the human and the machine as one integrated system rather than introducing the AI as an afterthought.
The systems architect thinks in interactions, not components. Performance does not emerge from a model, a sensor or a carrier board in isolation; it emerges from how they behave together, especially when one of them degrades. In our world that might be a cooled sensor, an edge computer, a network link and the software stitching them together — any of which can fail independently. The architect keeps asking: where are the points of failure, what happens when a subsystem behaves differently than expected, how does a change here ripple over there. For this way of thinking, “done” does not mean every part works. It means the whole works together, consistently and predictably, in the environment it was designed for.
The domain operator focuses on what a person can realistically absorb, interpret and act upon under pressure, fatigue and uncertainty. Consider a CISF officer who has completed multiple eleven-hour night shifts at a perimeter post. By the ninth hour, a detailed dashboard is no longer useful; attention has narrowed to a single light, a single tone, a single cue. That lived experience converts directly into design constraints: fewer channels, ruthlessly prioritised information, signals that can be read in a one-second glance. This perspective’s test is always the same — in this scenario, under this fatigue, does the system reduce the cognitive load on the operator, or quietly add to it?
The interaction designer owns the last mile between system output and human action. Picture a trial in which an operator misses three critical alerts — not because the alerts were inaccurate, but because they were visually indistinguishable from routine notifications. The algorithm was never the problem; the presentation was. This way of thinking starts from a blunt premise: information is only useful if it can be perceived, understood and acted upon in real conditions. Can the alert be identified through night-vision devices? Can the cue be heard over engine noise? Do the controls still work in gloves? Every screen and every sound gets examined from the operator’s side of it.
The validation lead asks the uncomfortable questions. What have we not tested? What are we assuming without noticing? What happens when GPS is denied, radio links are degraded, or the optics are dirty, misaligned or partially obstructed? This perspective designs test campaigns that resemble the field rather than the lab — sand working into enclosures, rain on touch interfaces, low-light glare, power interruptions, intermittent connectivity. Its job is to find the failure modes before the field finds them for us. Uncomfortable questions are cheaper in a lab notebook than in a deployment report.
The integrator and logistician thinks past the demo, into the third winter of service. Can the system be repaired at a forward location? Are spare parts realistic? Can software be updated without specialised infrastructure? Can a unit actually absorb the training? This perspective owns the unglamorous work — documentation, training pipelines, rollout and maintenance planning — that separates a successful trial from a system that is still trusted years later.
We would not claim that every team needs exactly these five. They are simply the perspectives that, in our experience so far, have most often changed what we shipped.
The other shift has been in when we test. Real-world testing used to sit at the end of the process, like a final exam. We have been moving it forward, into design itself.
In practice that means getting systems out of controlled environments early. Field exposure before the product is finished. Shadow-mode operation, where the AI observes and reports but does not influence decisions, so we can measure how it behaves against reality without betting anything on it. Adversarial exercises whose explicit purpose is to stress, deceive and break what we have built, while the cost of breaking is still ours alone.
It also means treating operator feedback as a core input to product development rather than a courtesy at the end of it. Operators notice things engineers do not: an interface that fights with gloves, an alert that dies in bad weather, a workflow that adds friction at exactly the wrong moment. Each observation looks minor in isolation. Cumulatively, they decide whether a system is used and trusted — or switched off while personnel revert to the old way of doing things.
None of this replaces iteration; it redirects it. Time spent on field trials, rigorous testing and multidisciplinary feedback is not a delay in the engineering process. In defence, it is the engineering process.
We want to be careful about the register of all this. Building this way is slower. It produces more questions, more testing cycles, more assumptions revisited when they fail to survive contact with the field. We do not always get it right, and we are not offering a formula. Other teams, with other constraints, will find other ways.
What we can report is narrower, and we think more useful: when more perspectives entered the room earlier, when assumptions were challenged repeatedly, and when field realities shaped development decisions, our products got better. That is the finding. Not a doctrine — an observation from inside one lab, still being tested.
