Scenario Engine and Follow-On Strategy

Why a follow-on model should not tell you what to do

The Scenario Engine does not commit capital, does not optimize a portfolio, and does not hold a standing view between sessions. Those are design choices rather than gaps, and the reasoning behind each one is worth stating plainly.

Where the line sits

The Scenario Engine produces a recommendation, an allocation, a timing signal, and a rationale. It does not commit capital, it does not reserve an allocation, and it does not tell anyone at the fund that a decision has been made. Nothing it produces has any effect until a General Partner acts on it, and acting on it happens entirely outside the platform.

That boundary is a design choice rather than a limitation waiting to be lifted. A follow-on decision is a fiduciary act taken on behalf of limited partners, and the reasoning behind it needs an owner who can be asked about it later.

Four things the module does not do

It does not execute. There is no path from a recommendation to a wire, a signed document, or a commitment. The output is a reading.

It does not optimize a portfolio. The module evaluates one company in one proposed round. It does not rank the portfolio, does not distribute a reserve pool across positions, and does not compute an allocation that is optimal in any sense. Running scenarios on eight companies gives you eight independent readings, not a plan.

It does not hold a standing recommendation. Each scenario is a point-in-time evaluation against the inputs as they stood when it ran. A run from March does not update itself in June, and it is not withdrawn when circumstances change. It remains a record of what the evidence supported on the day, which is what makes it useful to look back at and what makes it wrong to treat as current.

It does not evaluate new deals. In its first version the module runs on existing positions only, and only where the position is still live. A company the fund has fully exited or written off does not generate scenarios, because there is no live decision to support.

Why not go further

The obvious next step, and the one most often asked for, is an optimizer: hand the module a reserve pool and a portfolio and let it allocate. The reason not to build that is not technical.

An optimizer has to assume its inputs are complete, and here they are not. The module reads what the platform can see: marks, stage progression, round terms, reserve capacity, exposure. It cannot see the conversation with the founder last week, the co-investor quietly looking for the exit, the hire that just fell through, or the General Partner's read on whether this team recovers from a bad quarter. Those are frequently the deciding factors, and an allocation computed without them would carry an authority it has not earned.

The honest version of this instrument makes the part it can see explicit and leaves the rest where it belongs. That is why the rationale exists in the shape it does: the module tells you what it weighed so that you can tell how much of the decision it was actually in a position to inform.

What this means in practice

A General Partner who reads a recommendation, disagrees with it, and does the opposite has used the module correctly. So has one who agrees with it and would have reached the same answer unaided, because the run is now a record of the reasoning at the time, and follow-on decisions are among the hardest to reconstruct honestly two years later.

The model does not rate the decision afterwards either. There is no scoring of whether a General Partner followed the recommendation, no record of agreement rates, and nothing in the Colibrí Architecture model that reads a firm differently because it disagreed with its own Scenario Engine.

Take it to your own fund

Run the model on your own fund.

The platform reads the Colibrí Architecture model against your own firm and funds.