The IIL methodology started as an attempt to write down a complete specification process. Every decision, every dependency, every constraint documented before implementation began. The idea was that a sufficiently complete specification would eliminate the integration surprises that had cost time on previous projects.
It did not work. The attempt to write complete specifications in advance produced either paralysis when the team waited for complete information that was not available, or false confidence when specifications were complete on paper, built on assumptions that turned out to be wrong. The problem was the assumption that complete specifications were achievable.
What Bounded Rationality Actually Means
Herbert Simon's concept of bounded rationality describes decision-making in conditions of limited information, limited time, and limited cognitive capacity. Decisions are made by satisficing. Finding an option that is good enough given the constraints on the decision process, not by optimising across all possible options.
This is not a failure mode. It is an accurate description of how complex decisions are actually made. Every engineering decision is made with incomplete information, under time pressure, by people whose working memory and attention are finite. Processes that assume otherwise are not rigorous. They are wrong about their operating environment.
Decision Points, Not Decision Completions
The shift I made in the IIL methodology was from trying to complete decisions before moving forward to structuring when decisions must be made by and what information they require.
A decision completion requirement says: this decision is made when the specification is complete. A decision point requirement says: this decision must be made before the team passes gate X, using whatever information is available at that time, with explicit acknowledgment of what is not known. The second approach produces worse specifications on paper. But the decisions get made at the right time, with honest acknowledgment of their basis.
A decision made with acknowledged uncertainty and a clear plan for what will trigger a revision is more useful than a decision deferred until certainty that never comes. Acknowledge the unknowns. Make the decision. Note what would change it.
The Role of Explicit Assumptions
The mechanism that makes this work is explicit assumption tracking. Every significant decision is made against a set of assumptions written down at the time the decision is made. When an assumption is invalidated by new information, the decisions that depend on it are flagged for review.
Mini-PLM was built partly around this idea. Decisions are linked to the file revisions they were based on. When a file revises, the system surfaces which decisions were made against the previous revision. The team can evaluate whether the new revision invalidates any of those decisions. The cost of staying aligned goes down because the information required to stay aligned is explicit and accessible.
When Specifications Are Genuinely Useful
This is not an argument against specifications. Specifications are essential. It is an argument for understanding what they can and cannot do.
A specification is useful when it captures decisions that have been made, makes their basis explicit, and defines what other decisions depend on them. The best specifications I have produced were written after the key decisions were made through the process of iterating and testing, not before. They captured what the iteration process discovered, made it legible to the rest of the team, and served as the stable reference that later decisions could build on.