Simulation report: what changed, who reacted, what to verify.

Direct answer

A good simulation report is not just a narrative summary. It tells you which agents reacted, which assumptions mattered, which branch gained momentum, which evidence remains weak, and what follow-up analysis should happen before a real decision.

For readers, the most useful habit is to mark the report in three colors: findings that are source-backed, assumptions that need checking, and action items that belong outside MiroFish.

Prepare a useful first run

A reader should approach the document like an analyst, not like a spectator. First identify the baseline, the time horizon, and the branch labels. Then look for the evidence trail under each claim. A clear report will let you move from a summary sentence to the simulated events and source context that support it.

The strongest section is often the disagreement section. If every role appears to agree, the run may have been too narrow or the personas may need sharper incentives. When groups split, capture the reason for the split: proof, cost, timing, trust, policy pressure, novelty, operational risk, or narrative framing.

After reading, turn the document into three lists: facts to verify outside the model, assumptions to keep for the next run, and conditions that would reverse the conclusion. That practice makes the report a decision artifact instead of a polished story.

A professional handoff should also make ownership clear. Assign each verification item to a real team, source, or research method: customer interview, finance review, policy check, support ticket sample, public data pull, or stakeholder meeting. The document becomes stronger when every next step has a concrete owner and evidence source.

Review checklist

Before acting on a MiroFish output, check whether the scenario stayed inside the question you asked. The most useful output for this page is: A structured report with summary, branch comparison, persona reactions, risk notes, evidence gaps, and next-step analysis prompts. The key limit is equally important: A report can be clear and still be wrong if the input, persona setup, or assumptions were weak. Treat it as a decision aid.

• Read the summary last if needed. First check the source, actors, time horizon, and scenario question.
• Find branch differences. Look for why one path diverges from another, not only which path is labeled likely.
• Mark evidence gaps. Every weak source or unknown variable should become a follow-up task.
• Compare a rerun. Change one assumption and compare reports to see what is stable.

A realistic use case

A simulation report for a public announcement may show fast supporter enthusiasm, slow institutional trust, and a risk that critics focus on missing proof. The next action is not to believe the report; it is to add proof material and run a sharper follow-up.

The value of the page is practical: define the job, prepare the right input, read the output with its limits visible, and choose a next step that can be checked outside the page.

How to read the report

Read a MiroFish report as a map of assumptions and reactions. Mark source-backed claims, uncertain claims, and follow-up questions separately. Then choose one change for the next run instead of accepting the first report as final.