What follows is the technical spine of the company — five architectural decisions, written down. Each is an Architecture Decision Record: a decision, the context that forced it, the alternatives we rejected, and the consequences we accepted.
We publish these so any engineer, any technical procurement evaluator, any researcher can verify the company before engaging with sales. You should not have to talk to anyone to know whether we can do the work.
Defence systems must operate where the cloud cannot reach. The link drops on contested airspace, the GPS denies on contested ground, the satellite passes on a 90-minute cycle. A cloud-first architecture inherits its failure modes — and the failures are correlated with the moments the system is most needed.
The standard industry pattern — push compute to a hyperscaler region, cache at the edge — is built for advertising, retail, and consumer products. It is the wrong shape for defence, where the worst-case latency budget is set by an adversary, not by a CDN.
Most defence software fails procurement because it is sold as a monolith. The integrator has only one of four needs; the vendor insists on selling all four. The deal collapses or the customer is over-sold and under-deployed.
Drishti, Vyooha, Nirnaya, Suraksha each address a distinct procurement centre. If any one of them required the other three, the company could not exist. The architecture must reflect the way customers actually buy.
Operators must be defensible. After-action review must be possible in days, not weeks. A decision made under tempo, in good faith, by a watch officer, must be reconstructable — sensor by sensor, fusion step by fusion step — six months later, in a court, in front of a panel of three.
A black-box recommendation engine cannot meet that bar. "The model said so" is not a defence. It does not survive the first Question Hour. It does not survive the first procurement review. It does not survive the first journalist with a Right to Information request.
Indian operational data, Indian models, Indian weights — must remain inside Indian jurisdiction. This is not a tradeoff to be negotiated against cost or convenience. It is the precondition for the company to exist as a sovereign supplier.
Industry-standard "India-region" hosting on a foreign hyperscaler does not satisfy this. Jurisdiction is operator, not data location. A foreign operator with India-region storage answers to its home regulator first, every time.
The worst failure mode in a defence system is the one where the operator does not know the system has failed. A binary up/down failure model masks the long tail of partial failures — a sensor with a bad clock, a node with high tail latency, a model with quietly degraded confidence.
Operators trust the system in proportion to how clearly the system tells them what it doesn't know. A system that pretends to be healthy when it isn't — or reverts to default values without telling anyone — is a system the operator stops trusting after the first incident.
Each ADR above is a single decision. The structural views that follow show how those decisions compose into a system you can deploy. The layer stack. The three planes. The reference deployment.
A vertical section through the system — from the operator's eyes at the top, down through the four platforms, to the silicon at the bottom. Read it like an architect's section drawing: what sits on what, and where the load is borne.
The dashed rust line is the trust boundary. Anything above it is in scope of our software guarantees; anything below is the customer's, the partner's, or ours-as-hardware-supplier — but it is always inside Indian jurisdiction, by ADR-004.
The layers above the trust boundary are composable by ADR-002: a customer can deploy any subset, in any order, on any compatible substrate.
How sensor events become decisions. The hot path. Sub-second budget. Owned by Drishti, traversed by Vyooha and Nirnaya.
How the mesh organises itself. Leader election, ROE distribution, mode transitions. Owned by Vyooha, hosted by Suraksha.
How every event becomes defensible record. Cryptographically chained, signed at each hop, exportable in CERT-In format. Owned by Suraksha.
What a customer actually receives, on day one of operation. Not an architecture diagram — a deployment topology, with explicit boundaries between what we ship, what the customer hosts, and what the partner integrates.
Three boundaries are non-negotiable: the trust boundary (ADR-004), the platform contract (ADR-002), and the operator authority line — beyond which no autonomous action is permitted without an operator's commit.
Each ADR has a longer technical companion document — including code samples, performance characteristics, formal verification status, and red-team test results — released under non-disclosure to qualified evaluators.
REQUEST TECHNICAL DEEP-DIVE → JOIN US ON THIS →