The prediction report is where a MiroFish run pays out: hundreds of simulated interactions condensed into a page you can act on. It’s also where users make their one predictable mistake — reading it like a forecast instead of like reconnaissance. This guide walks through each section of a report, what it’s derived from, and the discipline of using it well.
Section 1: the executive summary
One or two sentences stating the most likely outcome the simulation produced: “The change is absorbed by most segments, but power users organize a visible objection that peaks in week two.” It’s the line everyone will quote in your team chat, which is exactly why it needs the most discipline.
The summary is a central tendency, not a verdict. It says “this is the outcome the simulated dynamics leaned toward,” full stop. Read it, then make yourself read the next two sections before forming an opinion — they’re where the actual texture lives.
Section 2: risk signals
These are the specific hazards the run surfaced: which group turns first, which framing of the grievance spreads fastest, what silence gets interpreted as. Signals come from observed agent behavior, which gives them a concreteness generic risk lists lack — not “customers may be unhappy” but “the objection becomes organized once it reaches the moderator cluster.”
Risk signals are the most valuable section of the report, because each one is a specific thing you can now watch for in reality. A signal that names a group, a trigger, and a timing converts directly into monitoring: you know where to look and what early shape the problem takes.
Section 3: narrative paths
The distinct storylines the simulated conversation explored — typically two to four, e.g. a containment path, an escalation path, a fade-out path. Paths are not equally likely, and the report says which dominated; the others document the conditions under which things go differently.
Use the paths as branch planning. For each, note the fork: what observable event distinguishes the escalation path from the containment path? That fork is your real-world tripwire. Teams that pre-write one response per path get most of the value of the run.
Section 4: follow-up questions
The run’s own suggestions for what to ask next. They’re generated from tension the simulation noticed but didn’t resolve — an agent that almost flipped, a group whose silence was ambiguous. Don’t skip them: they’re the cheapest available map of where the run’s uncertainty is concentrated, and each one can go straight into the follow-up chat against the still-live simulated world. (That chat is demonstrated in the second demo video on Bilibili.)
The discipline: decision support, not prophecy
A report earns trust in a narrow, specific way: it exposes reaction structure — who moves first, what stories form, where the feedback loops sit — that you could not have enumerated from your desk. It does not know your market’s next surprise, and no honest simulation claims otherwise.
Three habits keep the relationship healthy:
- Argue with it. For each risk signal, ask “what would have to be true in my real audience for this to happen?” If the answer is plausible, the signal stands on its own merits — the simulation just found it faster than you would have.
- Chase the surprises. The right response to an unexpected finding is not belief or dismissal — it’s the follow-up chat, then a check against real data. Surprises are leads, and leads get investigated.
- Re-run on decisions, not on doubt. If the report unsettles you, changing nothing and re-rolling is superstition. Change the seed, the wording, or the plan — then a second run measures something.
A worked read-through
To make the sections concrete, here’s how a real reading session might go for a feature-deprecation run.
The summary says the removal is “absorbed with contained objection from affected power users.” Resist the relief; open the signals. Signal one names the containment condition: objection stays contained only while the two high-centrality community voices stay neutral. That’s not a prediction — that’s an instruction: those two accounts are now on your watch list for launch week. Signal two notes the migration guide’s tone was read as dismissive by the affected cluster; that’s a Tuesday-afternoon edit, essentially free.
The paths give you three futures: quiet absorption (dominant), a “what gets cut next?” trust spiral (minority, triggered if a second removal is announced within the window), and a competitor-assisted exodus (rare, requires both community voices defecting). You now know your one genuinely forbidden move — announcing another removal this quarter — which no single-number forecast would have surfaced.
Finally the follow-up questions suggest asking what the silent majority actually thought. Two minutes in the chat reveals they barely registered the change — which reframes the whole exercise around the vocal 4%, where it belonged.
Fifteen minutes, four decisions influenced. That’s the report working as intended.
Where reports fit in the pipeline
Everything in a report is a distillation of the simulation stage — agents interacting across rounds on a synthetic social surface — which itself grows from your seed documents. The whole chain is laid out in how MiroFish works, and the synthesis code is inspectable in the open-source repository. When a plain one-shot answer suffices instead of all this machinery is its own question, covered in simulation vs. a single chat answer.
The fastest way to make this guide concrete is to hold a real report in your hands: run any scenario at mirofish.us — the main MiroFish site — and read it section by section against this page.