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 report with its method stated, its assumptions tested and its code attached — because an answer you cannot check is not worth much. 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

The same question can be answered at different depths. A fast read arrives in minutes; a full study goes further and takes longer.

Snapshot

A fast verified read

What the data says, checked, in minutes.

 Brief

A one-page answer

The computed answer on a single page — chart, numbers, method.

 Deck

A full study you own

A durable, multi-card analysis you can re-run whenever.

 Compare

Which depth do I need?

What each one includes, side by side.

Once you have one

An analysis is not a one-off answer. It is something you keep, re-run and change.

Create

Commission a new one

Describe what you want to know. We work out the method, write the code and check the result.

Run

Apply it to new data

Same analysis, new file, same method — which is what makes two results comparable.

Modify

Change the question

Iterate without starting over, and keep the lineage of what changed.

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 classified before any method is picked. Mistaking the type of question is the most common error in data analysis, and it is 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 isolationR is where statistical methods live, maintained by the people who developed them. Each run happens in a clean, disposable environment.
  5. Output is verified independentlyAssumptions are tested rather than assumed, arithmetic is reconciled, and the written narrative is checked against the numbers it claims to describe.
  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 →

Why you can trust the output

Every claim above is something you can check rather than take on faith.

How a build actually worksThe eight roles a build passes through, and what each one is responsible for.Why we write RThe statistics language, not the glue language — and what that buys you.Same data, same answerWhy an analysis you cannot re-run is not evidence.The code that ranEvery report ships the source that produced it.Citations & referencesMethods cited, so a reviewer can check the choice, not just the number.Compared to plain AIWhat a language model does when you ask it to analyse a spreadsheet.

What we don't do

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, 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 →