AI research products
Three products for research, strategy, and operations.
At Mordor Intelligence, I worked as both product owner and technical architect across a research-production pipeline, a B2B robotics-intelligence product for strategy teams, and a research-operations platform.
These are separate products, not modules of one general AI platform. They serve different users and workflows. All three keep the source, validation, and review history behind automated output.
Three separate products.
Deep research
A production system for turning a market-study contract into a defensible, evidence-bearing report.
Market-intelligence production · agentic research · publication controlGRID
A B2B intelligence product for strategy teams in robotics and automation organisations, turning fragmented market signals into evidence-backed strategic action.
B2B robotics strategy intelligence · entity graph · evidence-backed decision supportMI-hub
The operating system that moves a commercial research request from intake to accountable delivery.
Research operations · commercial intelligence · organisational control planeMy role as product owner.
I identified the source object, user groups, legal state transitions, decision surfaces, non-goals, and success condition for each system. That meant distinguishing a market-facing B2B product for external strategy teams from the internal lifecycles that organise research production and delivery.
- Deep research begins with a report contract and ends with a publishable, evidence-bearing study.
- GRID begins with fragmented robotics-market signals and ends with evidence-backed intelligence a strategy team can use to decide where to compete, partner, invest, or expand.
- MI-hub begins with a research request and ends with accountable delivery—while hosting specialised team products inside that operating boundary.
My role as technical architect.
I built and repaired the control plane around agents: contracts, evidence lineage, semantic adjudication, deterministic validation, identities, permissions, queues, retries, provider health, audit trails, and hard approval gates.
- Models operate on bounded inputs and return typed, challengeable outputs.
- Databases and services own state, permissions, idempotency, and readback.
- Failure becomes an explicit product state instead of a plausible-looking result.
Rules used across all three products.
The products use different workflows and technology, but they follow the same rules for data, permissions, automation, failure, and human review.
Typed contracts
The work begins with an explicit schema, scope, state, and definition of done.
Evidence provenance
Important fields and claims retain source identity, time, quality state, and path to readback.
Agent boundaries
Models extract, compare, resolve, or draft; deterministic services own permissions, state, and gates.
Recoverable work
Jobs carry stable identity, attempts, leases, retries, and explicit failure state.
Scoped access
Organisation, team, assignment, self, and functional boundaries are resolved before data is exposed.
Human authority
Publication, external sending, ambiguous evidence, and consequential decisions retain an accountable reviewer.
How the three products differ.
Report contract + live IW data
Evidence and approved data → validated report sections
Publishable market study
Signal + entity + field evidence
Fragmented robotics activity → verified strategic intelligence
Market decision, watch, export, or opportunity
Research request
T1 intake → T7 delivered, across accountable teams
Completed research hand-off + operational history