Defence Procurement Routes for AI: iDEX

A founder in Koramangala told a defence-adjacent Slack that they were 'in iDEX' because they had attended a webinar and followed the Defence Innovation Organisation on LinkedIn. A year later they had no challenge win, no prototype sign-off, and a slide that implied a Ministry of Defence procurement route. A service officer at a later meeting asked for the challenge number. There was none.

iDEX — Innovations for Defence Excellence — is the Ministry of Defence's flagship innovation scheme, funded and managed through the Defence Innovation Organisation, a not-for-profit company under the Department of Defence Production. It exists to pull startups, MSMEs and individual innovators into defence and aerospace problems through challenges, partner incubators, grants for prototypes, and a pathway that can lead to procurement if the service still wants the thing after it works.

That last clause is the one decks skip. A DISC win is not an indent. A prototype grant is not an AMC. A photograph with a senior officer is not a rate contract. iDEX is a real route. It is a long route with gates.

This guide is how to walk the route without inventing grant ceilings or merging iDEX with DRDO's Technology Development Fund. Those are different schemes. The companion piece compares the money. This piece compares the procurement story. Not official DIO advice. Read idex.gov.in and the specific challenge brochure.

What iDEX is, in procurement English

It is a problem-pull system. Services and organisations publish problems. You apply to a challenge — Defence India Startup Challenge (DISC) editions, open challenges, ADITI, iDEX Prime and other windows as announced. Partner incubators and DIO run the process. Winners receive support to prototype under a framework the brochure names (you will see SPARK language in official material). The live grant envelope is in that brochure, not in this article.

It is not GeM. It is not a state IT empanelment. It is not a PAC. It is not TDF. TDF sits with DRDO and funds development of defence technologies under its own portal and rules. You can, in a career, touch both. You should never file one as the other.

It is not only for weapons. Problems have included dual-use software, training, logistics, cyber, and sensing. An agentic system that drafts, retrieves, or watches a network could fit a problem if a user organisation wrote that problem. Do not force a civilian grievance bot into a DISC that asked for a fuze.

iDEX words that get mixed

Word	What it is	What it is not
DIO	Defence Innovation Organisation — the Section 8 company that funds and manages iDEX	A service HQ that can raise an indent by itself
DISC	A challenge edition with published problem statements	A standing vendor list
ADITI / Prime / open challenge	Other windows iDEX has used; read the current page	Automatically a larger cheque — ceilings live in the brochure
Partner incubator	An institution that helps run the challenge and support winners	Your customer
Prototype success	A gated technical result under the agreement	A production order

The path, without a fake flowchart

Watch idex.gov.in/challenges. Read the problem like a specification, not like a theme. If you cannot write a one-page test that would prove you solved it, do not apply.

Apply with a team that can take security instructions seriously. Defence users will ask where code is written, who holds the repo, whether any model call leaves a controlled network, and whether you train on their data. If your commercial product phones a public API, do not pretend it is a tactical agent.

If you win, the grant and milestone contract will consume a founder. Treat it as a product, not as marketing. Deliver the prototype in the environment they name. Document isolation. Do not slip a SaaS dependency in month four.

If the prototype works, procurement is a separate political and financial act. Services have their own manuals. iDEX has been built so that successful innovations can be taken up. 'Can' is the word. Stay close to the user organisation. Help them write the statement of case. Do not tweet that you have a defence contract until you have a defence contract.

1. Pick one problem you can test.
2. Build a restricted demo — no customer data from civilian clients, no uncleared cloud hops.
3. Apply on the official path. Ignore agents who sell 'iDEX introductions'.
4. If rejected, read the problem again or wait for a better fit. Do not restyle the same chatbot.
5. If selected, staff milestones like a paid product. Involve your security lead from week one.
6. If successful, support the user through their procurement file. Price a production and support year honestly, including air-gap operations.

What defence users will ask of an agent

Where does inference run. On their network, on yours, in a vendor cloud. If you cannot offer an isolated runtime, many problems will die in security review even if the challenge brochure sounded software-friendly.

What leaves the perimeter. Prompts, embeddings, crash dumps, licence checks. The no-outbound discipline in civilian SDCs is stricter here, not looser.

Whether you train on their data. Say no if no. If you need fine-tuning, say it is on their metal, on their corpus, with their deletion. Do not hide a vendor training loop.

Who the human is. Agents that 'engage' are a legal and ethical problem in defence. Keep a human for any act that is not a draft or a detection flag, unless the problem explicitly says otherwise and counsel has read it.

What not to claim on the civilian website

Do not use service crests. Do not say 'approved by the Indian Army' because a unit tried a prototype. Do not list iDEX as an empanelment equivalent on a state IT bid. Different buyer, different instrument.

Do not publish operational details of a problem statement that was marked restricted. If you cannot tell, ask the incubator. Default to silence.

Do not mix iDEX grant money into a civilian valuation slide as 'MoD revenue'. Grants are grants. Revenue is a contract.

Objections you will hear — and what to do with them

These are the lines that stall the file. Answer them in the room, then put the answer in the note. A spoken answer without paper will be forgotten by the next officer.

Just tell us the current DISC grant ceiling.

Open the live challenge brochure on idex.gov.in. Ceilings have been publicly discussed at different levels for standard challenges and for Prime-like windows. They change. A field guide that freezes a crore figure becomes a lie.

iDEX is only for hardware.

Problem statements decide. Software and dual-use have appeared. Fit the problem, not a stereotype.

Once we win DISC, DPP/DAP procurement is automatic.

It is a pathway, not an automaton. The user still has to want it, fund it, and clear it.

We can use a public model API if the demo is impressive.

If the problem implies a controlled network, a public API is a disqualifier waiting to happen. Design isolation first.

A 60-day iDEX fitness check

Run this before you put defence on the pitch deck.

1. Week 1: read idex.gov.in, the DDP page, and two past problem statements. Write whether your product is isolation-capable.
2. Week 2: pick one live or recent problem. Write a one-page test plan. If you cannot, you do not have a bid.
3. Week 3: red-team security — outbound, training, citizenship of the repo, who can see logs.
4. Week 4–5: apply or wait. Do not pay a fixer.
5. Week 6: decide the cash story. A win is a prototype project. Keep civilian sales alive.

How this shows up in the file

Internal note: 'We will not describe ourselves as iDEX-selected unless a challenge number and a written instrument exist. We will not treat iDEX and TDF as one scheme. We will not publish service marks. Production revenue will be forecast only after a procurement instrument, not after a prototype milestone.'

If you are a civilian department reading an iDEX logo on a vendor slide: ask for the challenge number. Then ignore it for your own technical scoring. Their defence prototype is not your SDC design.

This article is informational field guidance for Indian public institutions and their vendors, not legal, tax, procurement or engineering advice. Confirm the live circular, RFE, GCC, GeM term, state G.O. and your counsel before you file anything. Incentives, ceilings and portal screens change.

How to run the route without confusing the letterhead

“Defence Procurement Routes for AI: iDEX” is a route problem. A P5 Startup/Vendor should know which legal person they are talking to — NIC, NICSI, a state IT corporation, iDEX, or a GeM buyer — and which paper that person can actually issue. Searching “iDEX defence AI procurement” is not the same as being on a panel that can receive a work order.

iDEX is a challenge and prototype path into defence, not a GeM listing and not TDF. Read the live challenge on idex.gov.in. Do not treat a winner slide as a production AMC. Empanelment letters are not purchase orders. DPIIT recognition is not a technical score. Reserved startup seats, if a notice writes them, are local to that notice. IndiaAI compute empanelment is not NICSI application-software empanelment.

Keep a warm evidence pack: CIN, GST, DPIIT, Udyam, financials, work-completion letters, architecture one-pager, DPA draft. Renewals are lost by people who treat the panel as a trophy.

• Screenshot the live RFE paragraph you are relying on, dated.
• Match the bidding entity name across every certificate.
• Do not mix iDEX, TDF, NICSI and GeM clocks on one tracker cell.
• Record the validity end date 90 days before it dies.

Close this loop before the next CAB

Put “Defence Procurement Routes for AI: iDEX” on the next change-advisory or bid-opening agenda as a single line item with an owner. If it cannot earn a line item, it will not earn a control. The owner should be a P5 Startup/Vendor, not “the vendor.”

Revisit the item when the model, the GeM term, the region, or the SI changes. “iDEX defence AI procurement” is not a one-time workshop. It is a watch item. Date the last check. Unsigned watch items are souvenirs.