Data
Thirty requests in the backlog and one analyst
A scoping note per request, so the backlog is triaged on value rather than on arrival order.
What the worker does
An AI worker writes the scoping note that turns an analysis request into a decision about whether to do it. For each item in the backlog it records the decision the analysis informs, the data required, whether that data exists in the warehouse, and the cheapest version that would still answer the question. The analyst then triages on value instead of on arrival order.
- Runs
- Per request, then as a batch
- Connections
- Supabase, Notion, Linear
- Output
- A scoping note per item
Backlogs are ordered by who asked most recently
Not by value. The item at the top is there because somebody mentioned it in standup, and the item at the bottom has been there since February and might be the one that matters. Nobody reorders the list because reordering requires knowing what each item is worth, and that information was never captured.
So the analyst works down from the top, the February item stays at the bottom, and every month somebody says the backlog is out of control without anyone being able to say which parts of it should simply be deleted.
The four fields in a scoping note
| Field | The question it answers | Why it kills requests |
|---|---|---|
| Decision | What changes based on the answer? | A request with no decision behind it does not survive being written down |
| Data required | Which tables and fields does this need? | Reveals when the answer requires data nobody collects |
| Data exists | Do we actually have it, at the grain needed? | Half of ambitious requests fail here |
| Cheapest version | What would a good-enough answer look like? | Turns a two-week project into a two-hour one, often |
The cheapest-version field earns its place
It reframes the request
A cohort model built over two weeks and a count over two hours frequently point at the same decision. Naming both lets the requester choose, which they were never offered before.
It exposes the requests that need the model
Some genuinely do, and the scoping note makes that case explicitly instead of the analyst having to defend the time.
It gives the analyst a starting point
Even when the full version is approved, the cheap version usually runs first and sometimes ends the question.
Scoping against analysing
The worker scopes
- Reads the request and restates the question
- Checks the schema for the data required
- Proposes the cheapest sufficient version
- Links previous work on the same question
The analyst analyses
- Decides what is worth doing
- Writes and runs the query
- Judges whether the result is trustworthy
- Delivers the answer and defends it
Questions people ask
+Does every request need a scoping note?
Anything larger than a quick lookup benefits, and the note takes the worker minutes rather than an analyst's afternoon. Requests answerable in five minutes are usually answered rather than scoped, which the intake step already sorts out.
+Who decides what gets deleted from the backlog?
A person. The scoping note makes deletion defensible by recording that nobody could name a decision the analysis would inform, which is a much easier conversation than declining a request on instinct.
+Can the worker estimate how long an analysis will take?
It can describe the data required and whether it exists, which is the part that actually determines effort. A time estimate from a machine that has not written the query would be a number with nothing behind it.
+How does this interact with request intake?
Intake turns a message into a specified task and asks the clarifying questions. Scoping happens after that, on requests that survived, and produces the note the analyst triages against. Running both means the backlog contains only requests somebody could defend.
Related
One analyst, thirty requests, and an AI worker in between
Five jobs that stand between a data team and the analysis they were hired to do.
Can you pull the numbers, sent as a direct message at 6pm
Every ask restated as a question, with the clarifying questions asked before anyone writes SQL.
Three teams, three definitions of active user, one meeting
Every definition of a metric found and listed side by side, with the source of each.
Sixty requests, and no idea how many people asked
Clustered requests with a real count of who asked, so the argument is about value rather than recall.
Connect Supabase to Polaris
Supabase is the connection where a careless key choice does the most damage, and the only one Polaris cannot yet check for you.
Hire an AI data analyst
It settles what active user means, writes the query that matches the definition, and turns the numbers you hand it into a paragraph an executive can read.
Focus lane
A commitment for a horizon, not a filter over everything you have.