Research operations · commercial intelligence · organisational control plane

MI-hub

The operating system that moves a commercial research request from intake to accountable delivery.

MI-hub is not a CRM or a ticket list. It is a research-operations assembly line. Sales, Research, Formatting, Delivery, SEO, Primary Research, managers, and operations each receive a purpose-built surface over one durable operational record.

Role: Product owner · technical architect · product engineering
Period: Two years of production development at Mordor Intelligence

A client request crosses organisational boundaries before it becomes a delivered answer. Sales understands the commercial context; Research owns the investigation; Formatting prepares the deliverable; Dispatch returns it to the customer. Email and memory cannot reliably coordinate that chain.

The product problem was therefore not “track a task.” It was to create a shared operating contract: who owns the request now, what has been completed, what may happen next, what is late, and what evidence must survive the hand-off.

Users

Who uses it and what they need.

Sales

Submit and route requests, retain customer context, see action queues, pipeline, conversion, and accountable ownership.

Research

Claim work, begin investigation, preserve notes and evidence, and complete the research stage.

Formatting

Claim research-complete work, prepare the deliverable, and signal formatting completion.

Delivery / Dispatch

Verify the hand-off and record the final delivery state.

Managers, POCs, executives

Inspect service levels, workload, performance, bottlenecks, and exceptions within their permitted scope.

SEO

Operate Brand Mentions as a separate opportunity workflow inside MI-hub.

Primary Research

Coordinate expert engagements, submissions, transfers, outcomes, and research evidence.

Scope

What MI-hub does—and does not do.

01
MI-hub remains the source of operational truth even when no Freshsales deal exists.
02
Brand Mentions is an MI-hub module for SEO operations; it does not pretend to be a T1–T7 client request.
03
Sales Intelligence starts with eligible MI-hub requests, then enriches them with mailbox, CRM, and finance evidence.
04
The product exposes team-specific surfaces over shared contracts; it does not erase differences between Sales, Research, Formatting, and SEO work.
05
AI may extract and classify evidence. It cannot authorise a state transition, a send, a probability, or a permission decision.

Product decisions

Key product decisions.

One source object

An MI-hub request exists independently of CRM completeness, so operational work never disappears because commercial enrichment is missing.

Team-shaped surfaces

Each function sees the queue, vocabulary, actions, and analytics relevant to its work while sharing the same underlying lifecycle.

Scope before aggregation

Self, team, organisation, assignment, and function scopes are resolved before dashboards or drill-downs read data.

Unknown is a valid state

An unavailable provider or unsafe large read returns an explicit unavailable state instead of a persuasive zero.

How it works

T1–T7 is the product contract.

The lifecycle is explicit because every transition changes ownership, permissions, clocks, notifications, and the set of legal next actions.

MI-hub lifecycle from request intake to delivery

T1SalesReceived
The request, client context, requirement, and routing information enter the operating record.
T2Research lead / POCAssigned
A valid research owner and assignment scope are established.
T3ResearchResearch started
Active investigation begins; service-level and checkpoint logic can now distinguish waiting from work.
T4ResearchResearch complete
The research hand-off is declared complete with its operational history intact.
T5FormattingFormatting claimed
A formatting owner accepts the next stage rather than work moving through an invisible inbox.
T6FormattingFormatting complete
The delivery-ready state is recorded and the next valid action becomes dispatch.
T7Delivery / DispatchDelivered
The final hand-off is recorded as a durable outcome, not inferred from a sent-message side effect.

Product modules

The main parts of MI-hub.

Operational surface inside MI-hub

MI-hub Sales Dashboard

Salespeople · team leads · managers · directors · authorised delegates

Turn the request lifecycle into scoped pipeline, conversion, revenue, ownership, and action intelligence.

What it does

The dashboard is an action surface, not a vanity chart. A salesperson sees their work; a lead can inspect a team; a director can move across the organisation only when the capability and requested scope permit it.

How it works

01
Request enters /api/sales/* and passes requireAuth.
02
Capability and sales-organisation membership are checked.
03
resolveSalesScope computes the legal self, team, person, or organisation boundary.
04
Requested team or person is validated against that boundary.
05
The sales read service calls bounded, typed RPCs for statistics, owner counts, and drill-downs.

Safety checks

Scope is resolved before aggregation.
Large or timed-out reads surface as unavailable.
Drill-down contracts are separate from summary contracts.

SEO operating module inside MI-hub

Brand Mentions

SEO specialists · reviewers · content and outreach owners · managers · provider administrators

Convert a discovered external mention into inspectable evidence, a qualified outreach opportunity, and a guarded human-approved action.

What it does

Brand Mentions uses MI-hub’s identity, scope, jobs, notifications, and audit infrastructure, but it has its own workflow. It is intentionally not disguised as a T1–T7 research request.

How it works

01
Graph alert mailbox ingestion is idempotent.
02
URLs are unwrapped; domains are canonicalised; existing links and exclusions are checked.
03
Article retrieval respects robots and produces inspectable HTML evidence, classification, and sentiment.
04
Ahrefs and internal report matching qualify relevance; contact discovery and contextual drafting prepare an opportunity.
05
Human approval is a hard gate before a guarded Graph send.
06
Reply and backlink monitoring close the loop without auto-replying.

Safety checks

Every capability flag defaults disabled.
Mailbox must be configured, authenticated, identity-verified, healthy, and enabled.
Every send rechecks approval, draft, mailbox, pause state, quota, recipient, and article.
Paid or negative mentions remain human decisions.

MI-hub-first diagnostic intelligence module

Sales Intelligence

Sales leadership · analysts · managers · commercial operations

Explain commercial momentum from time-safe operational evidence without letting a language model manufacture probability.

What it does

The eligible population begins with MI-hub requests, including requests that have no CRM deal. Commercial systems then enrich the operational record. The pilot remains diagnostic: projections, live scoring, and public UI publication stay disabled until calibration and lineage are trustworthy.

How it works

01
MI-hub lifecycle, bounded Graph evidence, Freshsales reconciliation, and finance lineage form the source set.
02
An immutable evidence manifest records what was available and where it came from.
03
Features are computed with event_time less than or equal to score_as_of to prevent future leakage.
04
Checkpoint-specific models preserve timestamp, owner, cutoff, feature contract, and model version.
05
Calibrated statistical candidates—logistic regression, EBM, CatBoost, XGBoost, or survival/hurdle approaches—own probability.
06
An LLM may extract or explain evidence; it cannot set the score.

Safety checks

MI-hub remains the cohort source.
Future events cannot leak into past predictions.
Freshsales matches carry confidence and health state.
Predictions and projections remain disabled when the evidence contract is not ready.

Sales and management surface inside MI-hub

Individual Performance

Salespeople · managers · directors · sales operations

Build comparable scorecards from historically correct roster, quota, shift, productivity, revenue, and pipeline evidence.

What it does

Performance is calculated as-of a period. A later team transfer or quota edit must not rewrite what was true when the work happened.

How it works

01
Resolve roster, effective team, quota status, shifts, and region as-of the requested date.
02
Apply explicit metric contracts to CRM, productivity, export, and snapshot facts.
03
Construct current and comparable periods before calculating targets and scorecards.
04
Expose conversion, revenue, pipeline, rankings, commitments, and deal health through typed reads.

Safety checks

Effective-dated membership preserves history.
Metric definitions are contracts, not chart formulas.
Source health and reconciliation state remain visible.

Research evidence module inside MI-hub

Primary Research

Primary Research · methodology operations · research leadership

Coordinate expert engagements and preserve interview or panel evidence for the broader research methodology.

What it does

The module turns expert outreach and submissions into an owned process with briefs, notes, transfers, outcomes, and completion state—not scattered correspondence.

How it works

01
Engagement and expert records retain assignment and status.
02
Briefs, submissions, notes, transfers, and outcomes form the working history.
03
Completion makes evidence available to the wider research method without erasing its origin.

Safety checks

Evidence retains source and engagement context.
Transfers change ownership without deleting history.
Completion is explicit rather than inferred from a message.

MI-hub runtime architecture from team surfaces to durable work

01
Team surfaces
React and TypeScript interfaces for core MI-hub, Sales, Formatting, SEO, Primary Research, managers, and administrators.
02
Typed client boundary
Validated forms, typed Axios calls, TanStack Query cache rules, Zustand UI state, rich-text editing, and analytical views.
03
API façade
Express routes and middleware keep transport thin and send business operations into explicit services.
04
Identity and scope
JWT verification, blacklist and organisation checks, capability gates, and organisation/team/subteam/self/assignment scopes.
05
Domain services
Lifecycle transitions, sales reads, notification rules, provider reconciliation, approval checks, and module-specific policies.
06
Durable state
Supabase Postgres, typed RPCs, row-level security, history, snapshots, and evidence manifests.
07
Workers and signals
Leased jobs, attempts, retry classes, Graph and provider work, durable notifications first, realtime second.

Technical rules

Rules every part of the system must follow.

Authentication is not authorisation

A valid identity is followed by capability and organisational scope checks. Route handlers cannot infer permission from a role label alone.

History is effective-dated

Team membership, quota, roster, and ownership changes preserve valid-from and valid-to context instead of rewriting the past.

External systems enrich

Freshsales, Graph, and finance sources add evidence and reconciliation. They do not replace the MI-hub lifecycle as the operational record.

Jobs are resumable

Background work records attempts, availability, leases, correlation, and error class so a partial provider failure can be retried without duplicating effects.

LLMs extract, code decides

Groq with an Ollama fallback can parse bounded email evidence; schemas, sanitisation, policy, database state, and human approval determine what the system may do.

Technology

The technology and responsibility of each layer.

AreaSpecificationArchitectural reason

Frontend

React 18 · TypeScript · Vite · Tailwind · Zustand · TanStack Query · React Hook Form + Zod · Tiptap · Recharts

Fast team-specific surfaces with explicit server-state, validated input, rich delivery content, and operational analysis.

Application API

Express · TypeScript · typed routes and domain services · thin Vercel entry

Transport stays replaceable while lifecycle, scope, and reconciliation rules remain testable in services.

Data

Supabase Postgres · typed RPCs · row-level security · Realtime

Durable relational truth, bounded analytical reads, database enforcement, and low-latency collaboration.

Identity

JWT verification · token blacklist · active-organisation check · capability and scope middleware

The system fails closed when revocation or organisational status cannot be trusted.

Async work

Durable job rows · attempts · availability · leases · retry classes · correlation IDs

Provider work can resume safely and operational failure is inspectable.

AI extraction

Groq primary · Ollama fallback · schema validation · sanitisation · few-shot contracts · audit trail

Model output is treated as untrusted extracted evidence, never as workflow authority.

Notifications

Durable notification record → Realtime fan-out → Graph / Teams / email workers

A user can read back a notification even if a transient delivery channel fails.

Failure handling

How the system handles missing or unreliable data.

Revocation provider cannot be checked

Authentication fails closed; the request does not continue on a hopeful assumption.

Dashboard read is too large or times out

Return a typed unavailable response, including an explicit 503 where appropriate, rather than render zero activity.

Worker stops after a partial external call

Lease, attempt, availability, correlation, and idempotency state make the job recoverable without blindly repeating side effects.

CRM identity is uncertain

Prefer exact identifiers; mark email or company matches as uncertain and retain MI-hub as source truth.

Realtime event is missed

Read the durable database record on reconnect; Realtime accelerates awareness but never becomes the only evidence.

Model output is malformed or overconfident

Validate and sanitise against the extraction contract; do not permit the result to perform a state transition.

Sources

What this case study is based on.

01
MI-hub production codebase: React and TypeScript client, Express services, Supabase data layer, jobs, migrations, parity checks, and staged tests.
02
Product documentation covering the T1–T7 lifecycle, organisation scoping, Sales Dashboard, Brand Mentions, Primary Research, performance, and Sales Intelligence.
03
Adjacent sales, finance, Graph, and Freshsales tooling inspected as integration sources rather than treated as MI-hub’s operational authority.