AZ

Mordor Intelligence / Product record

MI.02

B2B robotics strategy intelligence · entity graph · evidence-backed decision support

GRID

A B2B intelligence product for strategy teams in robotics and automation organisations, turning fragmented market signals into evidence-backed strategic action.

GRID—the Global Robotics Intelligence Database—is a B2B product for strategy teams inside robotics and automation organisations. It connects companies, facilities, deployments, robot models, construction signals, workforce changes, tenders, contracts, patents, policies, risks, and leads so teams can decide where to compete, partner, invest, and expand. Every event is treated as a signal about one or more market entities.

Role
Product owner · technical architect · agentic intelligence engineering
Period
Production product development at Mordor Intelligence
Open live GRID ↗
01 / Product overview

The problem, users, and product decisions.

I treated GRID as a strategy instrument, not a dashboard collection or an internal organisational system. The product lets strategy teams notice a market change, investigate the affected entities, verify the exact source and scope, then compare, watch, export, or turn that intelligence into a strategic or commercial action without losing context.

Robotics intelligence arrives as fragmented public signals: a facility announcement, a deployment, a new model, a construction project, a tender, a patent, a policy, a workforce change, or a risk event. The same company may appear under aliases, and a place may be confused with a headquarters, operating facility, integrator, or deployment site.

Strategy teams inside robotics and automation organisations need those fragments converted into a queryable, geographically intelligible market model: where demand is forming, which competitors are moving, which technologies are being deployed, and where a partnership, investment, or expansion decision is justified. The system must remain honest about unknown, partial, stale, duplicated, or low-confidence facts.

Users

Who uses it and what they need.

Strategy teams in robotics organisations

Monitor competitors, deployments, technologies, markets, and demand signals; turn evidence into choices about where to compete and expand.

Product and portfolio strategy

Compare robot categories, applications, adoption signals, and adjacent capabilities when shaping roadmap and market-entry priorities.

Corporate development and investment

Track company activity, geographic expansion, patents, policy, workforce, and risk to identify defensible investment or acquisition theses.

Partnership and ecosystem strategy

Find manufacturers, integrators, facilities, and deployment patterns that justify a partnership or channel decision.

Business development

Move from a verified market signal to an organisation, opportunity, watchlist, or commercial follow-up without losing the strategic context.

Executive leadership

Read a current, source-backed view of the robotics economy without accepting fabricated global totals.

Scope

What GRID does—and does not do.

  1. 01

    GRID is a market-facing B2B strategy product; it is not an organisational control plane or an internal workflow system.

  2. 02

    GRID is not a news reader; news is one signal class feeding a larger entity and evidence model.

  3. 03

    The product distinguishes organisations, facilities, deployments, models, and locations instead of collapsing every proper noun into one company record.

  4. 04

    A page of results never becomes a claimed global aggregate. Metrics retain exact query scope and source freshness.

  5. 05

    Generated or aggregated material is not labelled as analyst-authored unless a real editorial workflow owns it.

  6. 06

    Commercial follow-up is downstream of strategic intelligence; it must not overwhelm the monitor, investigate, compare, and verify workflow.

Product decisions

Key product decisions.

Every event points to entities

Signals become useful when a user can move from the event to organisations, facilities, models, geography, related records, and evidence.

Evidence before assertion

Important facts and summaries retain source, scope, confidence, and freshness; unknown remains a supported product state.

One strategy loop

Dashboard, map, directories, signal modules, saved views, watchlists, exports, and opportunities are connected stages of one strategic job.

Dense, calm, predictable

Shared table, filter, status, and action patterns let strategy teams work with high information density without relearning every module.

How it works

The strategy loop preserves context from signal to decision.

GRID’s routes are different views over the same strategic job. A team should never have to abandon the evidence trail while moving from discovery and comparison to a saved thesis, market decision, or commercial action.

GRID lifecycle from request intake to delivery
  1. G1Command CenterMonitor

    Dashboard and global map expose current changes across entities, signal classes, and geography.

  2. G2Signal modulesInvestigate

    Open the underlying deployment, news, tender, contract, policy, patent, workforce, construction, or risk record.

  3. G3Entity servicesResolve

    Distinguish aliases, organisations, facilities, sites, operators, suppliers, integrators, and exact robot models.

  4. G4Evidence layerVerify

    Inspect the source, field-level support, date, scope, confidence, and related records.

  5. G5My Space / PipelineDecide

    Watch a market, save a strategic view, export a bounded dataset, identify an opportunity, or begin organisation follow-up.

  6. G6Usage + operationsObserve

    Record access, source health, export history, and product states without inventing missing counts.

Product modules

The main parts of GRID.

01

Primary GRID surface

Command Center

Strategy · product strategy · corporate development · executives

Expose the current robotics economy through a global dashboard and map without manufacturing counts or urgency.

What it does

The Command Center answers “what changed, where, and why does it matter to our strategy?” It is an entrance into investigation, not executive wallpaper detached from evidence.

How it works

  1. 01

    Compose authenticated dashboard scope on the server.

  2. 02

    Load bounded summaries and map-ready records from shared services.

  3. 03

    Hydrate filters, drill-down, charts, and geospatial interaction in the client.

  4. 04

    Preserve the current scope while routing into an entity or signal.

  5. 05

    Expose loading, partial, stale, and unavailable states independently.

Safety checks

  • No badge appears without a canonical count and freshness contract.
  • Map claims have text or table equivalents.
  • A summary links to the underlying records and scope.
02

Core intelligence substrate

Entity Directory

Strategy · product and portfolio strategy · partnerships · corporate development

Maintain distinct, searchable records for organisations, facilities, robot models, deployments, and integrator relationships.

What it does

The directory is what turns event monitoring into market structure. A user can inspect an entity, its aliases, relationships, geography, related signals, and evidence instead of searching the same name repeatedly.

How it works

  1. 01

    Resolve incoming names and aliases against canonical entities.

  2. 02

    Represent organisation, facility, model, deployment, and integrator roles separately.

  3. 03

    Attach field-level source evidence and confidence.

  4. 04

    Connect related signals through explicit relationships.

  5. 05

    Serve searchable and filterable entity routes through shared APIs.

Safety checks

  • Entity types are not interchangeable.
  • Possible duplicates remain reviewable.
  • Unknown attributes stay unknown.
03

Nine shared signal modules

Signals

Strategy · product strategy · partnerships · corporate development

Structure deployments, news, risk events, regulation, patents, workforce, tender notices, contract awards, and construction activity.

What it does

Each module answers a different monitoring question but uses the same table, filter, evidence, state, and action grammar. The user learns one instrument, not nine disconnected dashboards.

How it works

  1. 01

    Domain agents and ingestion services acquire candidate signals.

  2. 02

    Schemas normalise dates, organisations, locations, categories, and source references.

  3. 03

    Entity services link the signal to canonical records.

  4. 04

    Semantic and deterministic validators challenge classification and field support.

  5. 05

    Module routes present bounded results with evidence and related entities.

Safety checks

  • Shared logic prevents one module inventing a different evidence standard.
  • Signal severity or confidence never relies on colour alone.
  • Related-entity links preserve investigation context.
04

Commercial opportunity surface

Pipeline

Strategy · partnerships · business development · market expansion

Connect tender, contract, and construction signals to the organisations, facilities, and follow-up actions they may justify.

What it does

Pipeline is downstream of verified intelligence. It helps a commercial user act on a signal while preserving why the opportunity exists and how confident the system is.

How it works

  1. 01

    Qualify the signal and related entity before presenting an opportunity.

  2. 02

    Retain tender, award, construction, organisation, and geography context.

  3. 03

    Allow a bounded record to be watched, saved, exported, or added to leads.

  4. 04

    Route organisation-contact operations through the server API boundary.

  5. 05

    Record usage and follow-up without rewriting the source signal.

Safety checks

  • Market evidence remains separate from CRM-style action state.
  • Contact and privileged operations are server-side.
  • Commercial action preserves the original evidence path.
05

Personal intelligence workspace

My Space

Every authorised GRID strategy user

Turn investigation into a persistent watchlist, saved strategic view, export history, opportunity list, and personal market scope.

What it does

A strategy product becomes useful when a team can return to a thesis. My Space preserves the exact scope and action chosen after verification.

How it works

  1. 01

    Persist a named active scope per user and organisation.

  2. 02

    Store watchlist and saved-view references to canonical entities or queries.

  3. 03

    Record export history with bounded scope.

  4. 04

    Keep leads linked to originating intelligence.

  5. 05

    Hide destinations until their real behaviour and access contracts exist.

Safety checks

  • Personal objects remain organisation-scoped.
  • Unavailable features are hidden rather than mocked.
  • Exports record the scope that produced them.
06

Intelligence production subsystem

GRIC Agentic Backend

Research engineering · data operations · domain reviewers

Acquire public evidence, run domain-specific reasoning, validate structured records, and feed GRID’s entity and signal model.

What it does

The agents exist to reduce the cost of structuring a large market. They do not replace the product’s identity rules, taxonomy, evidence requirements, or reviewer authority.

How it works

  1. 01

    FastAPI exposes bounded orchestration and ingestion jobs.

  2. 02

    Specialised OpenAI and Google agents research and extract domain evidence.

  3. 03

    Retrieval tools fetch and parse public pages and structured inputs.

  4. 04

    Schemas and validators resolve fields, taxonomy, and relationships.

  5. 05

    Supabase stores accepted records, evidence, jobs, and audit state for the product surface.

Safety checks

  • Agent output is validated before durable writes.
  • Field evidence remains inspectable.
  • Domain and organisation scope is enforced outside the model.
02 / Technical architecture

How the system is built, controlled, and recovered when something fails.

I split the product into a server-first web shell, hydrated strategy-workspace interactions, thin authenticated API boundaries, shared domain services, durable relational and vector data, and agentic ingestion/enrichment. Privileged credentials remain server-only, and each module reuses the same evidence, identity, state, and access contracts.

GRID runtime architecture from team surfaces to durable work
  1. 01
    Authentication edge

    App middleware enforces Supabase-backed session behaviour and redirects unauthenticated dashboard requests before protected composition.

  2. 02
    Server route composition

    Next.js App Router renders the protected shell and module routes for dashboard, map, entities, signals, pipeline, and personal space.

  3. 03
    Client investigation

    Hydrated feature components, hooks, tables, filters, charts, maps, saved state, and accessible interaction patterns.

  4. 04
    Service boundary

    Shared libraries and domain services orchestrate reads and actions so route components do not duplicate business logic.

  5. 05
    Controlled API façade

    Server endpoints validate identity and input before privileged Supabase access, backend-bound RPCs, contact operations, support, usage, or admin work.

  6. 06
    Entity and evidence store

    Supabase/Postgres records entities, relationships, field evidence, user scope, saved objects, jobs, and vector-searchable intelligence.

  7. 07
    GRIC intelligence backend

    FastAPI with specialised OpenAI/Google agents, retrieval and extraction tools, validators, ingestion jobs, and structured writes into GRID.

Technical rules

Rules every part of the system must follow.

Service role is server-only

Browser code uses the public client contract; privileged Supabase keys exist only in server and API route execution.

Thin route handlers

Parse, authenticate, validate, call a shared service, and return a typed response. Domain rules do not accumulate inside page routes.

Identity before insight

Organisation, facility, deployment, model, and location resolution precede analytics that would otherwise double-count or misattribute activity.

State is explicit

Loading, refreshing, empty, partial, stale, denied, failed, low-confidence, and unknown are separate UI and API conditions.

Accessible evidence equivalents

Charts and maps provide text or table equivalents for essential information, and status never depends on colour alone.

Technology

The technology and responsibility of each layer.

AreaSpecificationArchitectural reason
Web application

Next.js 16 App Router · React 19 · TypeScript · server-first routes with client hydration

Protected intelligence routes gain a fast shell while dense filtering, maps, and actions remain interactive.

Data and auth

Supabase SSR/JS · Postgres · authenticated middleware · server-only privileged access

Identity and session state are resolved consistently while sensitive keys never enter browser code.

Strategy workspace state

TanStack Query · shared dashboard context · feature hooks · URL-preserving filters

Server state, market scope, and navigation context remain predictable across modules.

Geospatial

Leaflet + React Leaflet · map routes · text/table equivalents

Facilities, deployments, organisations, and signals can be investigated geographically without making the map the only accessible representation.

Analysis and motion

Recharts · restrained Framer Motion · reduced-motion handling

Charts communicate bounded values and motion supports continuity without obscuring dense information.

Intelligence backend

FastAPI · OpenAI Agents SDK · Google GenAI/ADK · Supabase · structured web extraction

Domain agents and extraction tools can be orchestrated independently of the frontend deployment.

Verification

Vitest · Playwright · accessibility checks · tested route and deep-link behaviour

A shared terminal needs consistent behaviour across modules, permissions, widths, and evidence states.

Failure handling

How the system handles missing or unreliable data.

Two aliases are mistaken for two companies

Entity-resolution and human-verifiable identity evidence prevent duplicated organisations from becoming duplicated market activity.

A facility is confused with a headquarters or deployment site

Typed entity and relationship contracts preserve place type, role, operator, and supporting evidence.

A global number is inferred from paginated results

The interface displays the bounded result scope; no aggregate appears without a canonical aggregation contract.

A source is stale, partial, or low-confidence

The state remains visible in the record and its summaries rather than being flattened into a normal-looking fact.

A client attempts privileged database access

Sensitive operations route through authenticated server endpoints; service-role credentials never ship to the browser.

A chart or map cannot be perceived or operated

Essential information remains available through keyboard-operable text and table representations.

Sources

What this case study is based on.

  1. 01

    GRID product record defining users, the monitor → investigate → verify → act loop, entity-first mental model, honest states, and information architecture.

  2. 02

    GRID frontend codebase: Next.js App Router, Supabase middleware, server composition, hydrated feature modules, services, controlled API routes, maps, charts, and end-to-end verification.

  3. 03

    GRIC backend codebase and runtime dependencies: FastAPI, OpenAI Agents SDK, Google GenAI/ADK, Supabase, structured extraction, spreadsheet processing, and tests.