Real options under uncertainty in software engineering teams

The right to decide later

A real option is the right, without the obligation, to act later rather than now: to build, abandon, expand, switch, or wait. The right has value distinct from the value of the underlying thing, and that value comes from asymmetry — you exercise when conditions favour you, you walk away when they don't, and the most you ever lose by holding the right is the cost of holding it. Two variables set the price. One is volatility: how much the underlying situation might move. The other, easier to forget, is expected information arrival: how much you will actually learn before the decision has to be made. These are not the same thing. A situation can be wildly volatile and still make deferral worthless, if nothing between now and the deadline will tell you which way it moved. Waiting only pays when waiting is informative.

Stewart Myers named this at MIT in 1977, treating a firm's growth opportunities as call options on future investment, built on the option-pricing machinery Black, Scholes and Merton had supplied in 1973. Avinash Dixit and Robert Pindyck's Investment Under Uncertainty (1994) then explained a puzzle that had bothered economists for decades: why firms demand hurdle rates far above their cost of capital before committing to irreversible projects. The answer was that committing kills the option to wait, and that kill has a price, distinct from the project's own risk. Firms were not being irrational. They were pricing something real that conventional discounted cash flow left out entirely.

Why this prices intake, not just decisions

The premium on any option, above its bare intrinsic value, is the market's estimate of information not yet received. That reframes what "holding an option" actually requires: it requires an ongoing channel through which the resolving information can arrive. No channel, no premium, whatever the volatility on paper.

This is why the lineage from Large Language Model to Large World Model to Large Universe Model is, underneath the technical description, a lineage of option value. A Large Language Model holds beliefs frozen at a training cutoff. Every option implicit in those beliefs was priced once, at cutoff, and then never repriced, because no further evidence reaches the model to resolve what it left open. Its deferral value decays monotonically with the calendar, not because the model gets worse at reasoning, but because the world keeps moving and the model keeps not hearing about it. A Large World Model senses while a scene is in front of it, so it holds live, correctly priced options for the duration of that scene — and none beyond it. When the sensing stops, whatever was left undecided freezes, unexercised, at the last frame. A Large Universe Model is the arrangement in which the channel itself never closes: streams keep running, beliefs stay revisable, and provenance records which observation moved which belief, so the repricing is auditable rather than assumed.

That is the whole claim, and it is narrower than it sounds. It is not that more data is intrinsically better — a claim easy to refute, since more data raises cost, latency and the chance of spurious correlation. It is that flexibility has a price, that price is a function of expected information arrival, and cutting arrival to zero collapses the option to a static bet frozen at today's beliefs. Corpus, scene and unbounded stream are not points on a scale of ambition. They are the three classes of evidence a system can be permitted: past text, present sensation, ongoing anything. Once ongoing anything is granted, further gains are in fidelity, latency, coverage and trust in the provenance trail — real gains, but inside the class, not a fourth class beyond it.

Testing it against a dependency graph

Software engineering teams are a good place to stress this, because they already run on four continuous streams whose only job is to resolve uncertainty before it becomes a decision: the commit stream, CI results, the incident feed, and dependency advisories. Each stream is, in the options sense, the thing that makes deferral cheap to evaluate correctly. A team that could not observe any of them would still have the same underlying risks; it would simply have to decide blind, at the deadline, with no chance to have learned anything in the meantime.

Take the specific failure this domain produces reliably: a vulnerable transitive dependency ships and stays shipped for weeks, because the audit that would have caught it runs on a schedule — say, monthly — rather than on the advisory feed itself. The vulnerability existed the moment the dependency was pulled in. The team held, whether they knew it or not, a real option: patch now, or wait for more information about severity, exploitability, and whether a fix even exists yet. That option was correctly priced only for as long as the advisory feed was actually being watched. Once the audit cadence lapsed into "next month's job," the option didn't disappear — it just stopped being repriced, and repricing is the entire content of holding it. The team was carrying open exposure at a stale premium, functionally identical to a Large Language Model reasoning confidently about a world six weeks out of date.

The staff engineer who owns this is usually the one who can see the shape of the problem without being given the authority to fix its cause. They can triage a CVE score, cross-reference it against the actual call graph to see whether the vulnerable function is even reachable, and decide within an hour whether to patch, pin, or wait for upstream. What they typically cannot do alone is change the cadence at which the advisory feed is even consulted, because that is a process decision, not a code decision, and it sits above their formal remit even though the consequence of getting it wrong lands squarely in their area. This is the domain's version of Dixit and Pindyck's hurdle-rate puzzle: the organisation is demanding a far higher bar of certainty before revisiting its audit schedule than the underlying volatility of the CVE landscape would justify, because revisiting it is treated as a cost centre rather than as the price of holding a repriceable option.

The point of the table is not that continuous beats scheduled by definition. It is that a scheduled audit is a decision to close out the option at fixed intervals regardless of what the streams are saying in between, which is only correct if the streams are, in fact, uninformative between audits — and dependency advisories are not; they arrive when a researcher discloses, not when your calendar says.

The objection that does the most damage

Real options theory is notorious for overvaluing flexibility. Managers who price the option to wait often wait forever. Applied to continuous observation, this risks dressing up indefinite indecision — never quite finishing the audit, never quite committing to the patch — as economic sophistication.

The critique lands, and it lands specifically in this domain. "We're still watching the advisory" is an extremely convenient thing to say indefinitely, and Dixit-Pindyck-style irreversibility arguments have been used for decades to justify exactly that kind of paralysis, in capital budgeting as much as in engineering. But the argument here is not that watching is good. It is that the option to wait has a price, and that price is zero once no further information is going to arrive before the decision binds. A dependency with a published, high-severity, actively exploited CVE and no mitigating configuration is not a case where more observation helps — the advisory feed has already delivered its decisive signal, and continuing to "monitor" past that point is exactly the paralysis the objection describes, correctly. Continuous intake does not mean permanent deferral. It means deferral gets evaluated against real, current information rather than against a stale prior, and one of the most common correct outputs of that evaluation is patch immediately.

What the streams don't buy you

Most bytes in most streams are worthless. A team drowning in CI noise and dependency chatter may resolve no more uncertainty than one running six checks a week.

Also correct, and worth conceding without qualification: the failure mode of "watch everything" is alert fatigue, and any staff engineer who has sat through a CI channel screaming about a transitive dev-dependency with no production reachability knows this in their bones. The asymmetry that justifies breadth anyway is that you rarely know in advance which advisory, among the hundreds a month, is the one that matters. Log4Shell's severity was not obvious from the package's popularity; it was obvious only once someone correlated a specific advisory against a specific reachable code path, weeks before most audit calendars would have surfaced it on schedule. The economic case is for breadth of permission and quality of provenance — observe broadly, weight sparsely, and be able to reconstruct afterwards which observation triggered which decision — not for treating every stream as equally worth a human's attention every day. Cost discipline belongs at the processing layer. Intake breadth belongs at the permission layer. Confusing the two is how teams end up either drowning or blind, and rarely land anywhere sensible in between.