After the first report
The first simulation report is not the finish line. Follow-up analysis is where MiroFish becomes useful for learning: change one assumption, rerun, compare, and decide what to verify next.
Follow-up analysis helps prevent a common mistake: treating a fluent report as final. A better habit is to ask which assumption drove the result, what evidence is missing, and what would happen if one condition changed.
In MiroFish, follow-up analysis can reuse seed material, memory, graph context, and ReportAgent findings. The goal is to compare reports rather than rewrite the first result from memory.
Use these steps to move from a broad phrase to a reviewable scenario, report, or clarification.
Tag findings, assumptions, and evidence gaps before editing anything.
Change a price, message, timing, actor group, evidence claim, or policy condition.
Keep source boundaries so the comparison remains meaningful.
Look for which findings stayed stable and which branch moved.
Draft the first MiroFish run on this page before opening a workspace.
These checkpoints keep the page tightly matched to the exact search phrase while staying useful for a real MiroFish run.
A follow-up run is an experiment. Keep the baseline report intact, write down the one condition you are changing, and predict what should move before running again. That discipline makes the comparison readable because the second result has a clear reason to differ from the first.
The best variables are concrete: price, launch date, proof strength, policy wording, audience segment, competitor response, public evidence, or time horizon. Avoid changing prompt style, source packet, persona mix, and decision goal all at once. When too many pieces move, the report may look better but teach less.
After the rerun, compare stable findings against changed findings. Stable findings deserve outside validation. Changed findings reveal sensitivity. New gaps become the next research task. This turns the workflow into a learning loop instead of a pile of unrelated reports.
Keep a short change log beside the reports. Record the original question, the changed assumption, the reason for changing it, and the result that moved most. That small habit makes the follow-up page useful for teams because anyone can see whether the second run clarified a decision or merely produced different wording.
A good comparison table has four columns: baseline finding, changed input, new finding, and practical action. If the practical action is blank, the rerun may be interesting but not yet useful. Force the output to name what should be measured, who should review it, and when another run would be justified.
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 comparison between scenario runs: stable findings, changed branches, new risks, stronger evidence needs, and a recommended next action. The key limit is equally important: Changing many variables at once makes comparison muddy. Follow-up analysis works best when the second run changes one important condition.
Use these checkpoints to turn the first MiroFish result into a grounded next action.
The video starts with the homepage, shows seed material upload, moves through graph construction and agent setup, and ends with a professional report screen.
These images come from the notepad MiroFish image set and are used as concrete workflow references rather than decoration.
A team runs a product launch scenario and sees trust concerns. In follow-up analysis, it adds proof material and reruns. If the trust branch improves but pricing objections remain, the next action becomes clearer.
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.
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.
Use the table to decide what belongs in the page, what belongs in MiroFish, and what still needs outside verification.
| Part | What it means | Why it helps | Check before acting |
|---|---|---|---|
| First report | Baseline findings and risks | Creates comparison point | Do not overwrite |
| Changed assumption | One variable to test | Shows sensitivity | Avoid changing too much |
| Rerun report | New branch behavior | Reveals stable vs unstable findings | Check source context |
| Decision note | What to verify next | Turns analysis into action | Use external evidence |
These related MiroFish pages keep the workflow connected from the homepage to the current topic and back into action.
Continue the MiroFish workflow with this related guide.
Open guideContinue the MiroFish workflow with this related guide.
Open guideContinue the MiroFish workflow with this related guide.
Open guideContinue the MiroFish workflow with this related guide.
Open guideShort answers for readers who need the useful boundary before opening a MiroFish workspace.
After reading the first report and identifying the assumption most worth testing.
Usually no. Change one major condition first so the difference is readable.
A comparison that shows stable findings, changed branches, and outside evidence to check.