Programs Are Networks of Commitments Under Uncertainty

Open a program plan and you will usually find tasks. Somebody owns each row. Each row has a date. Some rows depend on other rows, and enough green rows produce a green milestone.

That is a useful representation. I am starting to think it represents the wrong primitive.

A program is a dynamic network of commitments under uncertainty.

The word “commitment” matters because it carries more than work. It connects an actor to an intended future condition, a beneficiary, a time, a set of assumptions, and some standard of evidence. It also carries the possibility that the future condition will not become true.

I am calling the resulting model a Commitment Network. This is working terminology. I have not validated it, and I am not claiming a new branch of organizational science. I am trying to name a structure that has been sitting underneath several ideas on this site.

The model grew out of the simulation-bias problem. If a program’s representation can drift from the work, the first question is what the representation is supposed to stay faithful to. A task is often too thin. A commitment retains who owes what to whom, under which conditions, and what evidence would show that the promise became true.

The row and the thing beneath it

Take a dependency that reads:

Storage team, capacity available, September 10.

The row is a compressed account of something richer. A provider has committed to make capacity available to a consumer by September 10. “Available” has conditions. The commitment probably assumes a forecast, a region, a configuration, and an approval. The consumer has a need date that may be different from the promised date. Somebody asserted the commitment. Some evidence supports it. Both the evidence and the assertion have an age.

The row hides most of that because manual program management has to compress. A person cannot maintain every condition and provenance chain across 400 dependencies by hand. Once software can carry more of the structure, the compression becomes a design choice instead of a hard limit.

The useful question changes from “is the dependency green?” to a more demanding set:

• Who committed to what, for whom?
• Under which conditions does the commitment hold?
• What evidence supports it, and when was that evidence observed?
• Does the asserting actor have authority to make the commitment?
• How uncertain is the outcome?
• Which other commitments change if this one changes?

That is more work upstream. It should be. Cheap querying depends on expensive semantics.

The same structure in different clothes

Program artifacts that look unrelated start to line up when viewed as commitments.

Requirement. A commitment about intended outcome or behavior. It defines what some part of the system is expected to make true for a user, customer, or downstream component.

Dependency. A commitment by a provider to a consumer. The dependency is satisfied when the promised condition is true, not when the provider closes a ticket.

Interface. A commitment about the form or condition of a handoff. An API contract is the obvious case. A receiving dock accepting a rack within a delivery window is also an interface.

Schedule. A network of temporal commitments. The dates are coupled because commitments consume the outputs, capacity, attention, or authority of other commitments.

Supplier date. An external delivery commitment. It may be commercially binding, informally stated, or merely forecast. Those should not have the same authority in the model.

Decision. An authorization that creates, changes, or retires commitments. The decision record matters because 6 months later the organization will remember the date and forget the assumptions.

Milestone. A condition dependent on a set of commitments becoming true. Declaring it complete without the underlying conditions produces a ceremonial milestone.

Risk. Uncertainty about whether 1 or more commitments will be satisfied, plus the consequence if they are not.

This does not make every object identical. A requirement and a supplier promise behave differently. The claim is narrower: commitment is a useful common primitive for reasoning about how they connect.

Evidence changes confidence, not history

A supplier writes that a shipment will leave September 10. That email is evidence of a claim. It is not evidence that the shipment has left.

Three days later, the supplier portal still shows September 10, but a component shortage appears in a call transcript. Now the program has 2 claims with different sources, ages, and authority. A clean status model wants 1 answer. A faithful model should first preserve the contradiction.

New evidence changes confidence in the commitment. It does not rewrite what was previously claimed, and it does not automatically change the authorized schedule. Those distinctions are important:

• Observed reality: what the evidence directly shows.
• Claimed reality: what an actor asserts.
• Derived reality: what reconciliation rules conclude.
• Authorized reality: what an accountable authority has accepted or changed.

A program can simultaneously derive that September 10 is no longer credible and retain September 10 as the official date. That is not a data-quality bug. It is a real state of organizational life, and the system should be able to hold it without choosing the tidier answer.

Changes propagate through commitments

Task plans usually handle change by moving dates and asking owners for impact. A commitment network should make some of the propagation explicit.

Suppose a supplier commitment moves 12 days. The immediate effect is obvious. The more useful effects are downstream:

1. The receiving team’s resource commitment may no longer align with delivery.
2. A lab reservation may expire.
3. An interface-validation window may overlap a code freeze.
4. A launch approval may now depend on an exception.
5. A customer commitment may need an authorized change.

The network is dynamic because commitments are created, revised, satisfied, breached, superseded, and retired. It is uncertain because much of the program points toward future conditions that have not happened yet.

If the model works, a commitment change should identify likely propagation paths earlier and explain why they matter. If it merely draws a more complicated dependency graph, it has not earned the extra vocabulary.

What Program as Code contributes

The Commitment Network describes the underlying system. Program as Code is the implementation philosophy for representing enough of it that software can inspect and act against it.

That means commitments need stable identities and types. Conditions need explicit forms. Evidence references need provenance and time. Authority boundaries need to be visible. Changes need versions. Unknowns and contradictions need values of their own instead of empty cells somebody will interpret as “probably fine.”

The goal is not complete formalization. An organization contains judgment, tacit knowledge, politics, and physical facts that will resist schemas. The goal is sufficient structure for the important parts of execution, with explicit boundaries around what remains outside the model.

How this model could fail

I can see at least 5 ways.

It could be a relabeled dependency graph. If commitments do not produce better questions, propagation, or interventions, the new term adds ceremony.

Commitments may be too broad a primitive. A requirement, a decision, and a supplier date may share a shape while differing enough in behavior that a common model hides more than it reveals.

The semantics may cost more than they return. A system that requires perfect contracts before work begins will become another program blocking the program.

Politics may defeat explicit authority. Organizational authority is negotiated, overlapping, and sometimes deliberately vague. A schema can document that condition. It cannot resolve it.

Measurement may change the commitments. Once fulfillment becomes a performance measure, actors will write safer commitments, split them, move the real promise to a private channel, or avoid committing at all. Goodhart arrives early here.

What would change my mind

This model earns its place if it helps detect propagation, preserve uncertainty, and produce better actions than a task or dependency graph under the same conditions.

I want to test it against programs with contradictory supplier statements, stale ticket state, ambiguous engineering language, missing evidence, and facts that change over time. Can the model avoid unsupported certainty? Can it show which downstream commitments are exposed? Can another person reconstruct why it reached that result?

Failure on those questions would be useful. A theory that cannot specify what would weaken it is only a naming exercise.

For now, Commitment Network is the best description I have for what a program fundamentally is. The Program Observability model explains how such a network might be sensed. The Program Operating System is the larger, provisional architecture through which it might be governed and executed.