What-If Analysis
How AskEdi models a hypothetical change instantly, using a sensitivity measured from your own data whenever there is enough history to measure it.
What-If Analysis is AskEdi's response to hypothetical change questions: what happens to a metric if a driver changes by a certain amount. AskEdi resolves a real sensitivity for that driver, using your own historical data whenever there is enough of it, then runs the scenario instantly. No configuration screen, no sliders.
When What-If Analysis Activates
AskEdi classifies the intent of your question automatically. Questions that typically activate What-If Analysis include:
- "What if we raise prices 5%, what happens to revenue?"
- "What if we cut belt speed 10%, impact per line?"
- "What if solar radiation increases 10% in Mumbai?"
- "What if price rises 5% and marketing spend rises 10%, what happens to revenue?"
You do not need a special keyword or command, and there is no configuration step. AskEdi resolves the driver and the outcome directly from your question against your schema.
What Data This Needs
What-If Analysis gets a real, measured sensitivity instead of a general assumption when your table has this:
- Both the driver and the outcome as real numeric columns. A simulation only runs when the column you name as the driver and the column you name as the outcome both map to numeric fields in your table.
- A driver that has actually varied over time. If your driver has been flat, or changed by the same fixed amount every period, there is nothing for AskEdi to measure a real sensitivity from, and it falls back to a clearly labeled general assumption instead.
- Enough shared history for multiple drivers. Asking about two or more drivers together gets a more accurate result when they have enough overlapping historical data for AskEdi to separate each driver's own effect from the others.
AskEdi only runs a simulation when the driver and the outcome you named both map to real numeric columns in your table. If either does not, AskEdi explains why and suggests what to ask instead. No credit is consumed for that response.
What a What-If Response Includes
Every What-If Analysis response is four sections, in the same order.
1. Baseline Context (The "Before")
States the current, real value of the metric before the hypothetical change, along with the timeframe and scope the baseline is drawn from.
2. Scenario Comparison (The "After")
Shows the projected value after the hypothetical change, next to the baseline, as a table:
| Metric | Baseline | Simulated |
|---|
When your question asks for the impact per category, this section renders one row per category instead:
| Segment | Baseline | Simulated | % Change | Coefficient source |
|---|
Categories are resolved independently. Two categories in the same table can have genuinely different measured sensitivities. Table rows are sorted by the size of the projected impact.
3. Sensitivity & Parameter Analysis (The "Risk Margin")
Every simulation is re-run at a milder and a more severe version of the resolved sensitivity, holding the size of the hypothetical change fixed. This gives you a realistic range, not just a single midpoint projection, and shows how much the result depends on the sensitivity assumption being exactly right.
4. Operational Recommendation & Assumptions
The closing section renders as a highlighted card, not plain text. It contains four labeled parts:
| Part | What it contains |
|---|---|
| Simulation Finding | The headline result: what the hypothetical change is projected to do to the metric, stated with the real baseline and projected values. |
| Assumptions Used | The exact sensitivity used for every driver in the scenario, and where it came from: measured from your own historical data, a value from your column's description, or a general assumption. Never left unstated. |
| Simulated Recommended Action | What to do with the scenario, framed as a planning input grounded in the projected result above. |
| Validation Threshold | The real value that would signal the assumption set is wrong, and should trigger a rollback of whatever change was planned around this scenario. |
A sensitivity that is measured from your own data and one that is a general assumption are labeled differently in every response. Never treat "Assumptions Used" as measured unless the source explicitly says so.
What This Looks Like
A shortened example, for a question like "what if marketing spend increases 10%, impact on average daily orders?":
Baseline Context (The "Before") Over the trailing 12 months, the latest observed average daily orders baseline is 28.8.
Scenario Comparison (The "After") Applying a 10% increase in marketing spend projects average daily orders to move from 28.8 to 31.5, a 5.0% increase.
Sensitivity & Parameter Analysis (The "Risk Margin") Under the milder bound, the projected outcome lands at 30.7 (2.5%). Under the more severe bound, it moves to 32.2 (7.5%).
Operational Recommendation & Assumptions (highlighted card) Assumptions Used: marketing spend coefficient 0.5 (user override). Validation Threshold: roll back if average daily orders moves beyond 31.6 during the monitored window.
The real response is longer and grounded in your own column names and numbers. This shows the shape, not the content.
Where the Sensitivity Comes From
The number that determines how strongly a driver affects the outcome, sometimes called an elasticity or coefficient, is not invented by the AI on any run. AskEdi resolves it in a fixed order, and always reports which source was used:
- The number you specifically named. If your question, or a follow-up, names an exact sensitivity to re-run with, that value is used directly.
- A description already on the column. If your column's description states a known sensitivity, that value is used.
- Measured from your own data. AskEdi fits the driver's and the outcome's real historical movement against each other. When two or more drivers are asked about together, AskEdi first checks whether they historically moved together, and if so, measures each driver's effect while accounting for the others, so one driver's effect is not mistakenly credited to another.
- A general assumption, used only when there is not enough historical variation in the driver to measure a real sensitivity. This is clearly labeled as an assumption, not a measurement, in every response that uses it.
Verifying the Numbers Behind the Answer
The sensitivity, the baseline, and the risk range are all computed server-side before the response is written. To inspect the work directly:
- Analysis view: shows the exact query that ran against your data source.
- Methodology Notes: shows the resolved sensitivity, its source, and the fit quality when it was measured, independent of what the response text says.
Frequently Asked Questions
Next Steps
Root Cause Analysis
Find out which driver is actually responsible for a change before simulating what happens if it moves.
Forecasting
Project the current trend forward instead of modeling a hypothetical change to it.
Methodology Notes
Inspect the exact sensitivity, its source, and the fit quality behind every simulation.
AskEdi
Back to the AskEdi overview: how a chat works, response types, and how to get started.
Need help? Email support@edilitics.com with your workspace, job ID, and context. We reply within one business day.
Last updated on