Understand the pipeline — what happens between your question and your answer | MCP Analytics
The pipeline

What happens between your question and your answer.

You ask something about your data in plain English. What comes back is a piece of work you own — a report with its method stated, its assumptions tested and its code attached, plus the module that made it, yours to run again. This is the shape of what happens in between.

Have one built, or take one that exists

Both give you the same kind of report. The difference is whether your question has been asked before.

The pipeline

You describe a question nobody has answered yet. We work out the method, write the code, verify it, and hand back an analysis you own.

  • Built for your exact question
  • Yours to re-run and modify
  • Minutes to about an hour, depending on depth
Understand the pipeline
or

The library

High-quality analyses for the questions people run most — modelled on what the pipeline builds, verified the same way.

  • Prebuilt and independently verified
  • A worked example with every analysis
  • Full report in minutes
Browse the library

Then choose how deep your analysts go

The same question can get three sizes of answer — the quick pass, the memo, or the commissioned study. You pick the depth; the pipeline staffs the job.

Different specialists for different tasks. The pipeline staffs each job with the model suited to it — lighter, faster models handle profiling and quick reads; the strongest models are reserved for method selection, deep studies and verification. You don't manage any of that. You just pick the depth.

Every answer joins a library you can question

Delivered work doesn't scatter into downloads. Every report you've run becomes searchable in plain English — find last quarter's churn number without remembering which report it was in. And you can ask questions across all of it: the answer comes back synthesized from your own delivered analyses, with citations back to each report it drew from.

How the knowledge layer works →

ask your library
“What did we learn about discount codes this year?”
Discounts lifted repeat purchase in Q2 [S1] but the margin impact turned negative above 15% [S2]; the uplift study found the effect concentrated in first-time buyers [S3].

[S1] Repeat purchase uplift · [S2] Margin analysis · [S3] Discount cohort study

How a build happens

Every analysis goes through the same sequence, whether it takes two minutes or forty.

  1. We work out what you're actually askingThe question is matched on domain, intent and the shape of your data before any method is picked — the same triage an analyst does first. Mistaking the type of question is the most common error in data analysis, and the one that makes everything downstream wrong.
  2. Your data is profiled, not assumedColumn types, distributions, repeated keys and dates decide which methods can apply at all. One row per customer is a different problem from one row per customer per month.
  3. A specification is written before codeWhat will be computed, on which columns, and why that method rather than another — settled and recorded first, so there is something concrete to check the result against.
  4. The analysis is written in R and run in isolationSpecialist builder agents write a specification first, then the R for your question — not a template. R is where statistical methods live, and each run happens in a clean, disposable environment.
  5. Output is verified independentlyIndependent verifier agents re-run the build: assumptions are tested rather than assumed, arithmetic is reconciled, and the written narrative is checked against the numbers it claims to describe. A build that doesn't hold goes back, not out.
  6. Failures are repaired, not shippedWhen a check fails the analysis goes back to be fixed and re-verified. Builds that cannot be made correct are never delivered — and never billed.
  7. It is deployed, then tested in productionThe finished analysis is registered as a tool and run once for real before you see it, because building correctly and running correctly are different things.

See the eight roles in detail →

Calculated, not hallucinated

We don't have a language model read your spreadsheet and describe what it seems to say. The numbers in your report come from statistical code that ran on your data — they exist before a word of insight is written — and the code ships with the report so anyone can check it. The writing is generated; the arithmetic is not.

Browse the library Commission an analysis →

WHERE NEXT
proofPipeline case studies →Commissioned builds, from plain-English question to delivered report.depthChoose your depth →A fast read, a one-page answer, or the full commissioned study.price itPricing →What each tier costs and what it delivers.