What is a Binding Date?

Every plan carries one date on its cover, and the cover date is usually a negotiation, not a derivation. Someone wanted the quarter boundary. Someone conceded a fortnight. Behind that single date sit the real ones: the date the people are ready, the date the systems talk to each other, the date the contract allows. Enterprise software almost never stores those dates as objects in their own right, so the cover date floats free of the constraints that will actually decide it.

A binding date makes the real dates first class. A binding date is the date at which one binding constraint stops blocking a course of action, and an option’s overall date is the latest of its binding dates: the worst constraint decides. If the people clear in early September, the technology clears in mid September and the contract cleared in August, the option is possible in mid September. Not on the average of the three, and not on the date anyone prefers.

One date per constraint, not one date per plan

A constraint is binding when the option cannot proceed without it. Enough trained people is binding; a preferred office layout is not. Each binding constraint carries its own clearing date, derived from the facts that describe it, and only binding constraints get one. Preferences, ambitions and nice-to-haves stay out of the calculation, which is precisely what makes the calculation trustworthy. The overall date is then a computation, the maximum of the set, rather than a judgement call.

This entry defines the object. The argument for why the maximum is the only honest aggregate, and why averages flatter a plan into fiction, is made in Why the worst constraint decides. The two ideas are inseparable: without binding dates there is nothing for the principle to operate on, and without the principle the dates collapse back into negotiation.

How ONX derives binding dates

In ONX, binding dates are computed, not typed. Facts are versioned and published onto the commitment spine, and per-domain evaluators read them: the workforce dimension yields the date enough trained people are ready, the technology dimension yields the date the systems are integrated, the contract dimension binds where a clause fixes what is allowed. A shared evaluator converges the dimensions, and an option’s overall date is the maximum of the dates at which each binding constraint clears. Every candidate option carries the earliest date it clears every binding constraint, and a Decision Room ranks the options by exactly that date. When a fact version changes, the binding dates recompute and the ranking reorders. Nobody edits a date; evidence moves it.

One concrete example

Clearly illustrative, with no customer implied. A services firm of a few hundred people agrees to take over part of a client operation. Three constraints bind: trained people, an integration into the client systems, and a contractual notice period. The workforce facts clear in early September. The notice period cleared in August. The integration clears in the third week of September, so the option’s overall date is the third week of September, and everyone can see which constraint set it. Then a measured fact lands: a dependency of the integration is further along than the modelled estimate assumed. The technology binding date moves forward a week, the workforce date now clears last, and the binding constraint changes hands. The date on the plan moved, and the record shows exactly which constraint moved it and on what evidence.

What the object changes

When dates are derived from constraints, the argument in the room changes shape. You can no longer attack the date directly, because the date is a computation; you can only attack the constraint behind it or the evidence behind the constraint. That redirects effort to the only two moves that genuinely change an outcome: relieve the binding constraint, or improve the evidence that describes it. A team that wants an earlier date must show which binding date moves and how, which is a far more productive conversation than the one where the loudest voice picks a Friday.

It also gives optimism nowhere to hide. Wishful dates survive in most organisations because no single constraint is ever named as the reason; the plan is late in general and therefore in nobody’s lane. A binding date names the constraint, the owner and the evidence, which is the working discipline of Enterprise Decision Intelligence: options priced against the constraints that actually bind them, not the dates a room can be talked into.

A deadline is what the business wants. A binding date is what the world allows. Keeping the two distinct, and knowing at every moment which constraint sets the gap between them, is most of what it means to commit honestly.