Pillar 01 · DTRIHub
DTRIHub — our DeepTech Research & Intelligence Hub, and is a standing research programme run with university research groups and PhD advisors, with eight researchers working on it full time across energy and utility, payments and education. It proves the method; the lalla.ai platform runs it; EUNIQ and TopSyllabus sell it.
The programme
The DeepTech Research & Intelligence Hub is staffed continuously. Eight people work on it full time alongside university research groups and our PhD advisors — which is what makes it a programme rather than a phase somebody budgets for once and then closes.
We work with universities, and we mean it structurally. Researchers and students take defined problems with real data, under an agreement that settles publication and intellectual property before the first line of code. Our PhD advisors review the method against the literature, and they are expected to say when an approach does not hold. That relationship is the reason we can claim method rather than integration. See who reviews the work →
Research domains
We work in a domain when three things are true: a real operating problem, data we can actually reach, and an advisor who has run the system we are modelling. Everything else waits.
Network losses, asset failure and revenue leakage across electricity, gas and water, the domain behind EUNIQ.
High-volume, low-latency, heavily regulated. Our BFSI lead co-invented UPI, so the domain expertise here is first-hand rather than researched.
Modelling what a student actually understands rather than what they completed: the domain behind TopSyllabus.
Clinical and operational data where consent, privacy and clinical reality bound what a model may do. Advisor in place: a practising medical doctor.
Citizen-facing systems where auditability, accessibility and data residency are requirements rather than preferences.
Design and certification programmes where traceability from requirement to released drawing is itself the deliverable.
Three active, three under assessment. We would rather name what we are actually working on than list every industry we could theoretically serve. If your domain is not here and the problem is real, that is a conversation worth having, it is how the first three started.
Research areas
These are domain-independent by design, and all four ship into the same place: the lalla.ai platform. That is why the method transfers from a distribution network to a classroom, and why a second product costs a fraction of the first.
We model the domain as a typed graph so a model reasons over how things are actually connected instead of over flat rows. The graph is the reusable asset; only the domain changes.
Forecasts that respect the topology beneath them. What happens at one node constrains what can happen at its neighbours, and a prediction that ignores that constraint is a guess with error bars around it.
Separating probable cause from coincidence across noisy, partly-instrumented signals. And stating the confidence alongside the finding rather than issuing a bare verdict.
Every output carries the evidence that produced it, at the moment it is shown. Explanation is part of the result, not a panel someone can open afterwards.
The research model
We maintain a working association with university research groups and a PhD advisory bench, plus domain advisors with operating experience in each sector we enter. The path between them and a shipped product is defined, not improvised.
A real operating problem is written as a research question, naming the data that exists and the data that does not.
Faculty and PhD advisors review the approach against the literature. What is already solved is cited, not reinvented.
Students and our engineers build against real or reference data. The result either beats the baseline or it is written up and dropped.
What survives is hardened into a versioned capability inside lalla.ai, where every product can reach it.
The discipline is stage three. A prototype that does not beat its baseline gets written up and dropped, and that has to be a normal outcome rather than a failure. A research programme where everything succeeds is not a research programme.
Where it lands. Everything DTRIHub proves ships upward into lalla.ai, the platform beneath every product. Research that only ever reaches a paper is not a research programme we would fund.
Intellectual property
Joint research fails on ownership more often than on science. We settle it in writing at the outset, which is also what makes universities willing to work with us a second time.
Candidate claim areas are identified at design stage, not after a paper is drafted. India offers no grace period after publication, so the sequence matters and it is fixed: file first, publish second.
What each side brings stays theirs. What the programme creates is allocated in the agreement before work begins — so a successful collaboration does not end in an argument about who owns the method.
The network
A deep-tech claim is only as good as the people willing to put their name against it. Three groups do, and they do different jobs.
Two PhD advisors review method and validity before anything is built: whether the approach is sound, whether the baseline is honest, and whether the result means what we think it means.
A working association that puts researchers and students onto defined problems with real data, under an agreement that settles publication and IP before the first line of code.
Operators who have run the systems we are modelling. They are the reason a research question starts from a real failure mode rather than an interesting dataset.
The people who turn a validated method into a versioned engine and then into running software. Research that no one can ship is a paper, not a product.
Joint research programmes, platform licensing and product co-development are all scoped under DeepTech, including the IP terms, agreed in writing before work begins.
Start here
Thirty minutes with the engineers who would do the work. No deck, no discovery invoice, a straight read on feasibility, sequence and what a first build would take, including when the answer is that you should not build it.
