Mirum Malum, Mirum Beatum — Managing Surprise as Risk and Resource
Good project planning does not try to predict every surprise. It creates a structure in which the unexpected can be detected, interpreted and processed without making the project lose direction whenever reality deviates from the plan.
Project management is comfortable talking about risks, dependencies and mitigation. That is necessary, but it captures only part of uncertainty. A risk is usually something we can at least imagine as a possibility: a deadline may slip, a resource may disappear, a technical assumption may prove wrong. We can discuss probability, impact and countermeasures.
A genuine surprise behaves differently. It does not only hit the plan; it often hits the assumption on which the plan was built. A market suddenly behaves differently. Users employ a feature in an unexpected way. A model produces an output that fits neither the intended pattern nor the existing error model. A regulatory, organizational or technical change shifts the frame. Or an apparent mistake opens a solution nobody was looking for.
Such moments are not automatically good or bad. What matters is what they do to the project goal, its assumptions and the available options for action. The working concepts Mirum Malum and Mirum Beatum are useful precisely for this purpose.
Risk is not the same as surprise
Risk management works with anticipated uncertainty. Surprise management begins where the existing expectation structure is no longer sufficient. That may sound academic, but it is highly practical in AI projects.
If a language model is used, the need to review its outputs can be planned for. That is a risk and quality problem. It becomes a surprise when an apparently wrong output points to an ambiguous requirement, a contradictory data foundation or even a new solution path. At that point, the output alone is not the only thing that must be evaluated. The original question itself may need to be reconsidered.
The same logic applies outside technology. A customer may reject a planned feature yet reveal a much more valuable problem in doing so. A team member may become unavailable and create an immediate risk while simultaneously exposing an unhealthy dependency on individual knowledge. A cost increase may threaten a project and at the same time force a simpler architecture. A new market signal may promise growth while destabilizing the core project.
Surprise is therefore first of all information. Evaluation comes afterwards.
Two working concepts for unexpected dynamics
Mirum Malum describes a surprise that initially affects the project negatively: it breaks an assumption, increases effort, creates quality or safety problems, blocks work or threatens a goal. Mirum Beatum describes a surprise that opens an unexpected advantage: a better solution, a new use case, a shortcut, unexpectedly positive user behavior or an insight that makes the project stronger.
The word "initially" matters. The classification is not final. A Mirum Malum can become the starting point of an improvement after a good response. A Mirum Beatum can later turn out to be a distraction, a source of scope explosion or a false signal.
| Observation | Typical first effect | Dangerous reflex | Productive question |
|---|---|---|---|
| A central assumption collapses | Uncertainty, delay, friction | Throw out the entire plan immediately | What has actually become invalid, and what remains stable? |
| An unexpected solution works better | Excitement, new options | Redirect everything immediately | Is the advantage reproducible and relevant to the core goal? |
| An error reveals an unknown pattern | Confusion, distrust | Ignore or romanticize the error | Is it only an error, or evidence of a wrong assumption? |
| External conditions change | Pressure, priority shifts | Act without sufficient evidence | Which decision is genuinely time-critical now? |
Surprise management therefore becomes a form of interpretive competence. Not every unexpected event deserves a project change. But every relevant unexpected event deserves a disciplined review.
The real damage often starts after the event
Many projects do not fail because of the first surprise. They fail because of their response to it. Under pressure, teams change goals, priorities, tools and responsibilities at the same time. New information is mixed with old assumptions. Temporary measures become permanent structures. Later, nobody knows which decision was based on which evidence.
AI projects amplify this problem because new options can be generated extremely quickly. For almost every problem, an alternative architecture, a new tool, another workflow or a different model can be proposed within minutes. That creative speed is valuable. It can also create the impression that every surprise requires an immediate new solution.
A more professional order is simple: stabilize first, interpret second.
Stabilizing does not mean doing nothing. It means containing the impact of the surprise so that analysis does not take place inside continuing chaos. Only then should the team ask which assumption was made, what has actually changed and which options follow from the new information.
A five-stage protocol for surprise
A short protocol helps process negative and positive surprises with the same discipline. This prevents risks from being treated only defensively and opportunities only euphorically.
| Stage | Core question | Result |
|---|---|---|
| Observe | What actually happened, without interpretation? | Observation and immediate impact |
| Stabilize | What must be protected or temporarily frozen to prevent follow-on damage? | Bounded decision space |
| Interpret | Which assumption, expectation or dependency was affected? | Explanatory models and open questions |
| Decide | Ignore, monitor, test, integrate, escalate or change the plan? | Explicit decision and next checkpoint |
| Learn | What should become visible earlier, be planned differently or be reused later? | Updated project logic |
The strength of the sequence is that Mirum Malum and Mirum Beatum initially go through the same process. A positive surprise receives a burden of proof. A negative surprise receives the opportunity to become more than damage.
Mirum Malum: protect before you repair
A negative surprise often triggers the urge to build a solution immediately. This is exactly where discipline matters. Before optimizing, the project needs to know what must be protected.
If an important assumption no longer holds, the entire project does not automatically need to be rebuilt. The deviation may affect only one part of the solution path. The goal may remain intact while a technical route changes. The evidence may not yet be strong enough to justify a strategic shift.
A robust response therefore separates four levels: event, impact, assumption and decision. The event is what happened. Impact describes what is immediately blocked or threatened. The assumption identifies which previous belief no longer holds. Only the decision determines whether a local correction, test, escalation or replanning is required.
This distinction prevents a local error from becoming a global verdict on the project.
Mirum Beatum: opportunities need the same rigor as risks
Positive surprises are psychologically more dangerous than they appear. A suddenly successful approach, unexpectedly strong feedback or a new technical possibility can generate immediate enthusiasm. In project management, however, enthusiasm is not yet a business case and not yet a priority.
An opportunity becomes project-relevant only after it survives at least three questions: Is the effect real, is it reproducible, and does it improve the core goal more than the necessary change costs?
AI continuously produces fascinating side paths. A model may suggest a new function. An analysis may reveal an adjacent market. A prototype may accidentally serve another use case better than the original one. Any of this can be valuable. But if every interesting idea is integrated immediately, Mirum Beatum turns into feature creep very quickly.
A positive surprise therefore needs no less governance than a risk. It needs a different review attitude: not "How do we prevent this?" but "Under what conditions does this opportunity deserve a place in the project?"
Errors are not opportunities — but they can contain signals
Errors are an important edge case. It would be wrong to romanticize them as innovation. Most wrong results are initially exactly that: wrong. They must be detected, contained and corrected.
Yet an error can carry information. If an AI system repeatedly interprets a task differently than expected, the specification may be weak. If several models fail at the same point, the data foundation may be contradictory. If an unexpected output opens a completely different but plausible perspective, it may justify a hypothesis that should be tested separately.
● Members only
Read the full article and download all files with a membership.
Unlock full article + downloads → Subscribe0 comments
● Loading comments…