Simulate your next big decision 10,000 times.
Sometimes a decision is too important to make only once. What if demand comes in a little lower? What if a delay also raises costs? AI can help you build a Monte Carlo simulation: make the same decision in thousands of slightly different worlds, then see the pattern. The interesting result may be the assumption that matters more than anyone realized.
Try it now
Copy the prompt into your AI tool of choice, then answer its questions as they come.
Paste it into any AI chat to start. For most people, this is all you need.
Everything on this page in one paste: the prompt plus the full plan, every step and what to check. Use it for longer moves, to plan ahead, to share with a colleague, or if your AI can't open links.
How it goes
What the AI will do
- Builds a numerical model of your decision, using relevant records to identify what could vary and which assumptions move together.
- Runs and checks 10, 100 and 10,000 versions, then shows the distribution of outcomes and what changes the result.
What to have ready
- A consequential decision, even as rough notes. Existing proposals, spreadsheets or accessible company records help ground the assumptions.
Where you come in
- Confirm the alternatives, what a good outcome means, and assumptions that require your judgment. Review the first few simulated worlds and the finished comparison.
What you'll get
A reproducible simulation and a decision memo showing outcomes, sensitive assumptions and what you still need to learn. If execution or defensible inputs are missing, the AI identifies the prepared model or illustrative result as unfinished decision analysis.
You're done when
You have a checked, reproducible comparison of the decision alternatives, a readable distribution of outcomes and an explanation of which assumptions change the answer. Any missing execution, unsupported probabilities or illustrative inputs are clearly identified, so you can distinguish a completed decision model from preparation for one.
These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result. ### Start with the activity and the user's context Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear. Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them. ### Check the capabilities needed for this work Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit. When useful access is missing: - Explain what you cannot reach and how that material would help. - Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot. - If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response. - Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available. ### Ask focused questions and respect the answers Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful. Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements. ### Keep evidence and independent contributions distinct Distinguish evidence, inference, and missing information. Check your work against the source material. Use independent agents when your system actually supports delegation and independent investigation or review would improve the work: - Give each agent a bounded brief and the context appropriate to its role. - Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations. - Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately. ### Produce, check, and revise the result Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them. Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result. Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized. ### Make one decision in many possible worlds Help me simulate a consequential decision 10, 100 and then 10,000 times, making small, meaningful variations in assumptions or data and seeing how the outcomes change. Build and run a numerical Monte Carlo model: repeatedly sample uncertain inputs and calculate what each decision would produce. You do the research, modeling, coding or spreadsheet work, checking and explanation. I supply business judgment and confirm consequential assumptions. Repeated LLM answers are not simulated business outcomes. ### Find the decision and its evidence Begin with the material I have supplied, even rough notes. Identify the project, alternatives, decision date, people and relevant measures. Try available access to investment proposals, budgets, forecasts, operating data and existing spreadsheets. Search related email, chat, WhatsApp where accessible, calendar items and meeting transcripts for revised assumptions, disagreements, commitments and the reasons alternatives were considered. Search customer orders, usage, cancellations, sales history and supplier performance where these explain demand, pricing, delays or cost. Use the findings to recover the current decision and distinguish actual measurements from estimates. If the result goes to a board or leadership group, use invitations, correspondence and earlier reviews to establish whose decision it is and what measures or objections they have actually raised. Keep inferred concerns separate. Bound searches by project and relevant periods; retain source references and a record of coverage. For large records, delegate separate data areas with explicit questions and return formats, then reconcile versions and definitions. If access fails, investigate connection or export routes before asking for a specific permitted upload or action. Work from supplied records or an interview when necessary, labeling reconstructed inputs. A small illustrative model is useful when evidence is thin; its frequencies must remain separate from decision estimates. Ask one focused question at a time for consequential gaps. ### Agree what one run means Show me a short decision brief: options, time horizon, success measure, unacceptable threshold and what I control. Include the status quo when meaningful. Establish whether we are comparing profit, cash requirement, completion date, service level or several measures. Do not quietly turn a stakeholder preference into a numerical weight. Write the outcome calculation in plain language and show one hand-worked example. For a capacity choice, first-year contribution might be units served × (selling price − variable cost) − setup cost. Include capacity limits and lost demand; use multi-year cash flows and relevant financial assumptions when the real decision requires them. Recover accounting definitions from our records rather than mixing revenue, profit and cash. Keep unrelated complexities out. Wait for my correction or confirmation of the decision and any consequential judgment you have supplied on my behalf. Already supplied choices stand. If the model cannot represent the decision's central mechanism, repair it before using a larger run count. ### Specify what varies and what moves together Create an input table with: - Name and unit. - Baseline and range or distribution. - Source and date. - Reason for the chosen range or distribution. - Evidence status. Separate variation that occurs across customers or periods from uncertainty about a parameter we do not know. Never invent precise probabilities to fill a blank. Explain a distribution as a rule for how often different values are drawn. Use relevant historical observations when available, checking whether they represent the future situation. Preserve paired observations when their relationships matter. A triangular distribution can express a defensible low, most common and high estimate; its limits are assumed bounds, not automatically a confidence interval. Uniform sampling means equal weighting across the range. Use distributions appropriate to positive costs, bounded conversion rates or discrete events; do not apply the same ±10% normal noise everywhere. Describe dependencies before drawing numbers. A strong market might raise both demand and price; sample that common condition once and derive its effects. A delay may also increase cost. Across years, a market condition may persist; independent redraws each year could erase that persistence. Keep each alternative in the same sampled world so its comparison is fair. Identify known relationships, assumed ones and uncertainty about their strength. Show which assumptions need my judgment and wait for confirmation. When reasonable distributions cannot be supported, offer a clearly labeled range/scenario model or an illustrative simulation while we identify needed evidence. Do not call its frequencies real-world likelihoods. ### Build, inspect and increase the run count Inspect your execution tools and use a suitable available coding or spreadsheet environment. Python's standard library can generate common distributions and repeat seeded runs; consult the [official random documentation](https://docs.python.org/3/library/random.html) for the actual API. For methodological checks, use the [EPA's Guiding Principles for Monte Carlo Analysis](https://www.epa.gov/sites/default/files/2014-11/documents/montecar.pdf), particularly its treatment of dependencies, sensitivity, input evidence and numerical stability. These support the modeling method; they do not supply our business assumptions. Implement the reviewed formula and preserve the inputs and outputs of every run. Record code/formulas, parameter versions, software version, run count and random seed so another analyst can reproduce it. Check hand-calculated baseline and boundary cases, units, impossible values and option constraints. Where relevant data permit, compare model behavior with historical cases and explain mismatches. Run ten worlds first. Inspect their actual input/output rows and explain two contrasting cases so I can see the mechanism. Correct implementation mistakes, then run one hundred and ten thousand with the unchanged model, preserving the earlier sequence where possible. Plot the outcome distributions or provide a clear binned table if charts are unavailable. Repeat the larger run with fresh seeds and compare central values, tails and threshold frequencies. Agree a precision appropriate to the decision; increase runs if sampling noise still changes the conclusion, or explicitly report that numerical stability remains unresolved. A rare event may require many more than 10,000 runs. If computation is unavailable, investigate an allowed runtime first. Supply executable code or a working spreadsheet artifact with explicit run instructions and help obtain the resulting output. Do not fabricate execution. If no execution route is possible, deliver the prepared model as unfinished and identify exactly what remains. ### Find what changes the decision For each option show mean, median, a labeled range such as the 10th–90th percentiles, chance of crossing the agreed threshold and the paired difference from alternatives. Explain that an outcome range is not a confidence interval for the average. Report modeled frequencies as conditional on these assumptions, with simulation noise distinguished from missing knowledge. An option can win more often and still have a lower average payoff. Investigate the important drivers. Use input/output plots or an appropriate sensitivity method, explaining when dependencies make simple correlations misleading. Rerun plausible changes to distribution widths, central estimates, dependency assumptions and material model structure. Keep their chosen magnitudes visible. Trace representative bad and good outcomes back to inputs. Identify the assumption whose clarification would most help the decision and any switch point where the preferred option changes. More runs sharpen the model's answer; better evidence can change the answer itself. ### Review and deliver a usable decision aid If available, give a fresh reviewer the actual model, input evidence, execution outputs and decision brief, without your defense. Ask them to check formulas, dependence, comparability, sampling interpretation and whether the recommendation follows the stated objective. Resolve findings and rerun affected calculations. Otherwise use a distinct checking pass and disclose the shared context. Deliver a readable decision memo, distribution charts or tables, assumptions with sources, sensitivity findings, reproducible model and run data. Explain what seems robust, what changes under other defensible assumptions, and what remains unmodeled. Offer a recommendation only against our agreed criteria and keep it distinct from my decision. Stop with the completed analysis; implementing the business choice is a separate action. These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.
View full AI instructions
Simulate your next big decision 10,000 times.
What the AI will do
- Builds a numerical model of your decision, using relevant records to identify what could vary and which assumptions move together.
- Runs and checks 10, 100 and 10,000 versions, then shows the distribution of outcomes and what changes the result.
What you can provide
- A consequential decision, even as rough notes. Existing proposals, spreadsheets or accessible company records help ground the assumptions.
Where you'll take part
- Confirm the alternatives, what a good outcome means, and assumptions that require your judgment. Review the first few simulated worlds and the finished comparison.
What you'll get
A reproducible simulation and a decision memo showing outcomes, sensitive assumptions and what you still need to learn. If execution or defensible inputs are missing, the AI identifies the prepared model or illustrative result as unfinished decision analysis.
Activity context
Sometimes a decision is too important to make only once. What if demand comes in a little lower? What if a delay also raises costs? AI can help you build a Monte Carlo simulation: make the same decision in thousands of slightly different worlds, then see the pattern. The interesting result may be the assumption that matters more than anyone realized.
For the user
Bring the decision as it stands. The AI will look for relevant context, build the model and do the calculations. You will help settle the measures and uncertain assumptions, then review how the decision behaves across the simulated worlds.
Guidance for the AI
These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result.
Start with the activity and the user's context
Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear.
Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them.
Check the capabilities needed for this work
Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit.
When useful access is missing:
- Explain what you cannot reach and how that material would help.
- Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot.
- If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response.
- Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available.
Ask focused questions and respect the answers
Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful.
Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements.
Keep evidence and independent contributions distinct
Distinguish evidence, inference, and missing information. Check your work against the source material.
Use independent agents when your system actually supports delegation and independent investigation or review would improve the work:
- Give each agent a bounded brief and the context appropriate to its role.
- Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations.
- Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately.
Produce, check, and revise the result
Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them.
Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result.
Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized.
Your AI prompt
Make one decision in many possible worlds
Help me simulate a consequential decision 10, 100 and then 10,000 times, making small, meaningful variations in assumptions or data and seeing how the outcomes change. Build and run a numerical Monte Carlo model: repeatedly sample uncertain inputs and calculate what each decision would produce. You do the research, modeling, coding or spreadsheet work, checking and explanation. I supply business judgment and confirm consequential assumptions. Repeated LLM answers are not simulated business outcomes.
Find the decision and its evidence
Begin with the material I have supplied, even rough notes. Identify the project, alternatives, decision date, people and relevant measures. Try available access to investment proposals, budgets, forecasts, operating data and existing spreadsheets. Search related email, chat, WhatsApp where accessible, calendar items and meeting transcripts for revised assumptions, disagreements, commitments and the reasons alternatives were considered. Search customer orders, usage, cancellations, sales history and supplier performance where these explain demand, pricing, delays or cost. Use the findings to recover the current decision and distinguish actual measurements from estimates.
If the result goes to a board or leadership group, use invitations, correspondence and earlier reviews to establish whose decision it is and what measures or objections they have actually raised. Keep inferred concerns separate. Bound searches by project and relevant periods; retain source references and a record of coverage. For large records, delegate separate data areas with explicit questions and return formats, then reconcile versions and definitions.
If access fails, investigate connection or export routes before asking for a specific permitted upload or action. Work from supplied records or an interview when necessary, labeling reconstructed inputs. A small illustrative model is useful when evidence is thin; its frequencies must remain separate from decision estimates. Ask one focused question at a time for consequential gaps.
Agree what one run means
Show me a short decision brief: options, time horizon, success measure, unacceptable threshold and what I control. Include the status quo when meaningful. Establish whether we are comparing profit, cash requirement, completion date, service level or several measures. Do not quietly turn a stakeholder preference into a numerical weight.
Write the outcome calculation in plain language and show one hand-worked example. For a capacity choice, first-year contribution might be units served × (selling price − variable cost) − setup cost. Include capacity limits and lost demand; use multi-year cash flows and relevant financial assumptions when the real decision requires them. Recover accounting definitions from our records rather than mixing revenue, profit and cash. Keep unrelated complexities out.
Wait for my correction or confirmation of the decision and any consequential judgment you have supplied on my behalf. Already supplied choices stand. If the model cannot represent the decision's central mechanism, repair it before using a larger run count.
Specify what varies and what moves together
Create an input table with:
- Name and unit.
- Baseline and range or distribution.
- Source and date.
- Reason for the chosen range or distribution.
- Evidence status.
Separate variation that occurs across customers or periods from uncertainty about a parameter we do not know. Never invent precise probabilities to fill a blank. Explain a distribution as a rule for how often different values are drawn.
Use relevant historical observations when available, checking whether they represent the future situation. Preserve paired observations when their relationships matter. A triangular distribution can express a defensible low, most common and high estimate; its limits are assumed bounds, not automatically a confidence interval. Uniform sampling means equal weighting across the range. Use distributions appropriate to positive costs, bounded conversion rates or discrete events; do not apply the same ±10% normal noise everywhere.
Describe dependencies before drawing numbers. A strong market might raise both demand and price; sample that common condition once and derive its effects. A delay may also increase cost. Across years, a market condition may persist; independent redraws each year could erase that persistence. Keep each alternative in the same sampled world so its comparison is fair. Identify known relationships, assumed ones and uncertainty about their strength.
Show which assumptions need my judgment and wait for confirmation. When reasonable distributions cannot be supported, offer a clearly labeled range/scenario model or an illustrative simulation while we identify needed evidence. Do not call its frequencies real-world likelihoods.
Build, inspect and increase the run count
Inspect your execution tools and use a suitable available coding or spreadsheet environment. Python's standard library can generate common distributions and repeat seeded runs; consult the official random documentation for the actual API. For methodological checks, use the EPA's Guiding Principles for Monte Carlo Analysis, particularly its treatment of dependencies, sensitivity, input evidence and numerical stability. These support the modeling method; they do not supply our business assumptions.
Implement the reviewed formula and preserve the inputs and outputs of every run. Record code/formulas, parameter versions, software version, run count and random seed so another analyst can reproduce it. Check hand-calculated baseline and boundary cases, units, impossible values and option constraints. Where relevant data permit, compare model behavior with historical cases and explain mismatches.
Run ten worlds first. Inspect their actual input/output rows and explain two contrasting cases so I can see the mechanism. Correct implementation mistakes, then run one hundred and ten thousand with the unchanged model, preserving the earlier sequence where possible. Plot the outcome distributions or provide a clear binned table if charts are unavailable. Repeat the larger run with fresh seeds and compare central values, tails and threshold frequencies. Agree a precision appropriate to the decision; increase runs if sampling noise still changes the conclusion, or explicitly report that numerical stability remains unresolved. A rare event may require many more than 10,000 runs.
If computation is unavailable, investigate an allowed runtime first. Supply executable code or a working spreadsheet artifact with explicit run instructions and help obtain the resulting output. Do not fabricate execution. If no execution route is possible, deliver the prepared model as unfinished and identify exactly what remains.
Find what changes the decision
For each option show mean, median, a labeled range such as the 10th–90th percentiles, chance of crossing the agreed threshold and the paired difference from alternatives. Explain that an outcome range is not a confidence interval for the average. Report modeled frequencies as conditional on these assumptions, with simulation noise distinguished from missing knowledge. An option can win more often and still have a lower average payoff.
Investigate the important drivers. Use input/output plots or an appropriate sensitivity method, explaining when dependencies make simple correlations misleading. Rerun plausible changes to distribution widths, central estimates, dependency assumptions and material model structure. Keep their chosen magnitudes visible. Trace representative bad and good outcomes back to inputs. Identify the assumption whose clarification would most help the decision and any switch point where the preferred option changes. More runs sharpen the model's answer; better evidence can change the answer itself.
Review and deliver a usable decision aid
If available, give a fresh reviewer the actual model, input evidence, execution outputs and decision brief, without your defense. Ask them to check formulas, dependence, comparability, sampling interpretation and whether the recommendation follows the stated objective. Resolve findings and rerun affected calculations. Otherwise use a distinct checking pass and disclose the shared context.
Deliver a readable decision memo, distribution charts or tables, assumptions with sources, sensitivity findings, reproducible model and run data. Explain what seems robust, what changes under other defensible assumptions, and what remains unmodeled. Offer a recommendation only against our agreed criteria and keep it distinct from my decision. Stop with the completed analysis; implementing the business choice is a separate action.
Done when
You have a checked, reproducible comparison of the decision alternatives, a readable distribution of outcomes and an explanation of which assumptions change the answer. Any missing execution, unsupported probabilities or illustrative inputs are clearly identified, so you can distinguish a completed decision model from preparation for one.
These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.
These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.