Product

From a metric dip to a cited root cause

A funnel step falls. Aestus measures it against its own baseline, ranks only the causes it can evidence, and files one fix ticket.

Join the waitlist See what it produces

When the number moves

Investigate a funnel issue

Who it is for: Product and growth leads whose events land in a warehouse, and whose fixes have to become tickets.
What starts it: Every weekday at 13:00 in your workspace time zone, or on demand from the ticket you are already looking at; On a schedule

Coming soonInvestigate a funnel issue is built, but not ready yet, so it cannot be turned on today. In Aestus you can ask to be told when it is ready.

A funnel investigation is the place a model will most confidently invent a cause. That is not a general worry about accuracy; it is a specific, predictable failure with a shape you can point at. Hand anything — a person under time pressure, or a model under prompt pressure — a real fall and a thin change timeline, and you get back a fluent explanation. The mechanism is plausible. The timing lines up. The confidence is high. And there is no evidence behind it, which you cannot tell by reading, because an invented cause sits in the same font, under the same heading, with the same confidence chip as a real one.

The consequence is not an embarrassing document. It is a sprint spent hardening a code path nobody touched, while the thing that actually broke goes unexamined for another month. So this use case is built around two refusals rather than around a better prompt.

The first is that counting is done by code. The measurement step is allowed to report one kind of thing: whole numbers of users that a query returned. It reports no rate, no delta, no ratio and no average, and the reply it must produce has no field to put one in. Every percentage you read — the step conversions, the fall in points, the relative change, how many conversions are missing against the baseline — is computed from those integers afterwards, by software, from the same counts you can see. If the model names a worst step that its own counts do not support, the whole measurement is refused rather than quietly corrected, because a model that misread its own numbers has written every sentence downstream about the wrong step.

The second is that a cause has to resolve. Not sound right — resolve. An evidence line must name one of exactly four things: a segment cell the measurement reported, a pull request the run read, a ticket on your board, or a run. That is checked as a lookup against what the run actually retrieved, not by reading the prose, so a confident sentence gets no credit for confidence. A cause that resolves nothing is removed before the document reaches you, and the share of the fall it claimed goes back into a number the document prints out loud: how much of this is unexplained.

That number is the point. An investigation that ends with "we do not know what accounts for 206 of the 828 missing verifications" is more useful than one that ends with a tidy story, because both of them are read by someone deciding what to build next week and only one of them is true. Unexplained tells them to keep looking and not to ship a fix for a cause nobody established. A plausible attribution tells them the opposite of both.

Timing gets its own treatment, because it is the most over-read evidence there is. A merge nineteen minutes before the onset hour is real, and it is worth writing down, and it is not evidence of causation. So a cause whose only support is timing is kept, labelled, forbidden from leading the ranking, and credited with none of the shortfall. Coincidence is data. It is not an explanation.

The last thing the document does is say what it could not see, and it says it whether or not it found anything. A change nobody recorded cannot be on a timeline built from tickets and pull requests. A tracking change and a behaviour change are the same fall in this data — if an event stops firing, users look like they stopped converting. A release that no ticket names was never read, because the repository tools can fetch a pull request by number but cannot list what merged in a window. And anything outside the warehouse relation — email delivery, a CDN, a third party in the path — was not measured at all. Printing those four every time is what stops "no change was found" being read as "no change happened", which is the quietest way an honest investigation misleads.

What you get

The artifact this use case produces, in the product view you would read it in.

Example — fictional team and data. Not a live run or customer result.

Worked example

document

Funnel investigation — Signup → Activated, 2026-09-08

Produced by: Run EXAMPLE-FN-01 · read-only warehouse · document artifact on LIORHEBE-2363 · one fix ticket filed · demo values

What changed: Step 2 (email_verified) converted at 61.2% against a 78.4% baseline — a fall of 17.2 points, or 21.9% relative, on 4812 users at step 1 against 34190 in the baseline. None of those figures was written by a model: each is computed from the whole-user counts the queries returned. An hourly chart and a row per step sit under it.
When it changed: The first hour that sits below every hour of the previous seven days, in UTC, and the changes inside the day around it — the tickets that completed in that span, the pull requests they name, and the files those pull requests touched. 828 conversions are missing against the baseline rate, and that number is the denominator every attribution below is measured against.
Ranked causes: 2 causes, each with an evidence line naming a source this run actually retrieved and a confidence. 206 of the 828 missing conversions are reported as unexplained, because no cause established here accounts for them and none is asserted. A cause that names nothing the run retrieved is removed before this section is written; a cause supported only by timing is labelled and cannot lead.
Ruled out: Instrumentation, traffic mix and seasonality, every time, each with the single observation that dismisses it — a flat segment across the boundary, a share that did not move, the same weekday inside the baseline. An explanation nobody tested has not been ruled out.
Recommended fix: Exactly one change, the file or surface it touches, and the ticket filed for it. When the fall is unexplained this section says "No fix proposed" and gives the reason, and no ticket is filed — work with no identified cause has no definition of done.
Open questions: What the run could not answer and exactly what would answer it: a decision that is somebody's to make rather than a number, and a question that needs a system this workspace has no connection to.
Method and limits: The two window bounds in UTC, the sample counts, and 5 parameterised read-only queries returning 1318 rows in total — 1 of them returning none, which is stated as the finding it is. 3 breakdown cells fell below 30 users and were withheld with no number given. Then the four things this investigation cannot see, in the same words every time.

How it runs

Each step is one node in the workflow graph the interpreter runs. Nothing here is a prompt chain hidden in a route handler.

Workflow steps

01Measure
Read-only SQL against your warehouse counts the users who reached every step, for the observation window and for the baseline, then splits the worst step by browser, country or plan. The queries are parameterised and nothing is written back.
02Count in code, not in the model
The measurement step reports whole numbers of users and nothing else. Every rate, every delta, the relative fall and the size of the shortfall are computed from those counts by software you can check. There is no field in the reply for a percentage, so there is nowhere to put one that no query produced.
03Decide whether it matters
Below your threshold the run ends quietly and records that the funnel held. No document, no ticket, no message, and no notification either — a daily all-clear is how a team learns to ignore the one that is not.
04Investigate
Find the first hour below the previous week, then collect the changes around it: tickets completed in that span, the pull requests they name, the files those pull requests touched. Rank the causes, each with its evidence and a confidence.
05Drop what cannot be evidenced
A ranked cause has to name something the run actually retrieved — a segment cell from the measurement, a pull request it read, a ticket on your board, or a run. One that names none of those is removed before you read it, and its share of the fall is reported as unexplained. A cause supported only by timing is labelled as such and never leads.
06File and publish
One fix ticket in your project, linked to the investigation, plus the document. Nothing existing is moved, closed, assigned or commented on. The Slack post waits for your approval every time.

By hand, and on Aestus

The same job, on either side.

By hand
Three people open three dashboards and compare numbers from memory.
On Aestus
One query set, one baseline, one document, and the queries are recorded with the row count each returned.
By hand
The baseline is "last week felt better".
On Aestus
The baseline is the previous 28 days, printed with its UTC bounds and its sample count.
By hand
Somebody quotes a conversion rate and nobody can check it.
On Aestus
The model reports user counts. Every rate in the document is recomputed from them, and a rate the counts do not support is refused rather than printed.
By hand
The deploy that caused it is found by asking in Slack.
On Aestus
The change timeline is built from tickets completed in that span and the pull requests those tickets name.
By hand
Small segments get quoted with eleven users behind them.
On Aestus
Cells below your minimum sample are dropped, counted, and the withholding is stated instead of the number.
By hand
"It might be the redirect change" ends the meeting.
On Aestus
Every cause carries an evidence line naming its source and a confidence, and a cause that evidences nothing is dropped and the fall is called unexplained.
By hand
Nobody writes down what the investigation could not see.
On Aestus
The document states it every time: a change nobody recorded, a tracking change, a release with no deploy record, and anything outside the warehouse.

What Aestus records

Every run is auditable after the fact, which is what makes handing the job over survivable.

The document
An artifact on the ticket the run is anchored to, with the seven sections in the same order every time, the hourly chart, and the method and its limits at the bottom.
The queries
One row per query the run made, with how many rows it returned. A query that returned nothing is recorded and stated in the document, because "no segment explains this" is an answer.
The ticket it filed
One, in the project you chose, linked to the investigation. When the fall is unexplained it files none, because a ticket asking somebody to fix an unidentified cause has no definition of done.
The run
Cost, tokens, latency and failure classification, the same as every other dispatch in Aestus, plus at most one memory claim proposed with its citation and left unreviewed until somebody approves it.

What it connects to

Only the tools this workflow actually uses. Each one has a setup guide.

Questions teams ask

Where do the numbers come from?

From read-only queries against your own warehouse, in this run. The measurement step reports user counts and nothing else; every percentage in the document is computed from those counts, and one the counts do not support is refused before anybody reads it.

Can it be wrong about the cause?

Yes, so it prints its confidence and its evidence, and it drops a cause that names nothing the run retrieved. When nothing survives, the document says the fall is unexplained and proposes no fix. That is the honest answer, and it tells the team to keep looking rather than to ship a guess.

What if the funnel did not really move?

Below your threshold the run ends quietly and records that the funnel held. It writes no document, files no ticket, posts nothing and does not notify you.

Does it blame a person?

No. It names changes and systems. A sentence that names a person as a cause is refused before the document is written.

What can it not see?

A change nobody recorded, a release no ticket names, a tracking change that looks identical to a behaviour change in the data, and anything outside your warehouse such as email delivery or a CDN. The document states all four every time, so "no change was found" is never mistaken for "no change happened".

All use cases How access is governed

Sources

docs/runbooks/use-case-workflows.md
content/integrations/github.md
content/integrations/slack.md

Hand over Investigate a funnel issue.

Tell us how your team does this today and we will set it up with you.

Talk to us

Investigate a funnel issue

Who it is for

Product and growth leads whose events land in a warehouse, and whose fixes have to become tickets.

What starts it

Every weekday at 13:00 in your workspace time zone, or on demand from the ticket you are already looking at

On a schedule

Coming soonInvestigate a funnel issue is built, but not ready yet, so it cannot be turned on today. In Aestus you can ask to be told when it is ready.

Funnel investigation — Signup → Activated, 2026-09-08

Produced by: Run EXAMPLE-FN-01 · read-only warehouse · document artifact on LIORHEBE-2363 · one fix ticket filed · demo values

What changed: Step 2 (email_verified) converted at 61.2% against a 78.4% baseline — a fall of 17.2 points, or 21.9% relative, on 4812 users at step 1 against 34190 in the baseline. None of those figures was written by a model: each is computed from the whole-user counts the queries returned. An hourly chart and a row per step sit under it.
When it changed: The first hour that sits below every hour of the previous seven days, in UTC, and the changes inside the day around it — the tickets that completed in that span, the pull requests they name, and the files those pull requests touched. 828 conversions are missing against the baseline rate, and that number is the denominator every attribution below is measured against.
Ranked causes: 2 causes, each with an evidence line naming a source this run actually retrieved and a confidence. 206 of the 828 missing conversions are reported as unexplained, because no cause established here accounts for them and none is asserted. A cause that names nothing the run retrieved is removed before this section is written; a cause supported only by timing is labelled and cannot lead.
Ruled out: Instrumentation, traffic mix and seasonality, every time, each with the single observation that dismisses it — a flat segment across the boundary, a share that did not move, the same weekday inside the baseline. An explanation nobody tested has not been ruled out.
Recommended fix: Exactly one change, the file or surface it touches, and the ticket filed for it. When the fall is unexplained this section says "No fix proposed" and gives the reason, and no ticket is filed — work with no identified cause has no definition of done.
Open questions: What the run could not answer and exactly what would answer it: a decision that is somebody's to make rather than a number, and a question that needs a system this workspace has no connection to.
Method and limits: The two window bounds in UTC, the sample counts, and 5 parameterised read-only queries returning 1318 rows in total — 1 of them returning none, which is stated as the finding it is. 3 breakdown cells fell below 30 users and were withheld with no number given. Then the four things this investigation cannot see, in the same words every time.

Questions teams ask

Where do the numbers come from?

Can it be wrong about the cause?

What if the funnel did not really move?

Below your threshold the run ends quietly and records that the funnel held. It writes no document, files no ticket, posts nothing and does not notify you.

Does it blame a person?

No. It names changes and systems. A sentence that names a person as a cause is refused before the document is written.

What can it not see?

Sources

docs/runbooks/use-case-workflows.md

content/integrations/github.md

content/integrations/slack.md

From a metric dip to a cited root cause

Investigate a funnel issue

What you get

Funnel investigation — Signup → Activated, 2026-09-08

How it runs

By hand, and on Aestus

What Aestus records

The document

The queries

The ticket it filed

The run

What it connects to

Questions teams ask

Other use cases

Hand over Investigate a funnel issue.

From a metric dip to a cited root cause

Investigate a funnel issue

What you get

Funnel investigation — Signup → Activated, 2026-09-08

How it runs

By hand, and on Aestus

What Aestus records

The document

The queries

The ticket it filed

The run

What it connects to

Questions teams ask

Other use cases

Hand over Investigate a funnel issue.