Specification-by-Absence

A Derived Failure Pattern of Implicit Rules and Unverifiable Expectations

Summary

Specification-by-Absence is a Failure Pattern in which, when explicit specifications do not exist, "what is not written" itself is treated as de facto specifications.

What this Pattern addresses is not the problem of not writing specifications sufficiently. It is a structure in which, amid uncertainty and pressure for change, documenting specifications is postponed, and that void is filled by implicit expectations and conventions.

---

Context

In software under operation, defining all specifications in advance is not realistic.

Especially regarding the behavior of existing functions and exceptional cases, the fact "it has been working this way" tends to be treated as a substitute for documented specifications.

In such situations, even though specifications are not made explicit, only expectations become fixed.

Forces

The main dynamics that generate this Pattern are as follows:

• High cost of specification description
  Writing precise specifications requires time and agreement, and in environments where changes occur frequently, it is easily postponed.

• Dependence on existing behavior
  Running code is referenced as de facto specifications, and the intent of behavior is not articulated.

• Asymmetry of confirmation costs
  Compared to the cost of making specifications explicit, proceeding on the assumption of implicit expectations looks cheaper in the short term.

• Localization of changes
  Changes that limit scope of impact accumulate, and the overall specification image is no longer shared.

Failure Mode

Because specifications are not made explicit, discrepancies between expectations and implementation cannot be verified after the fact.

As a result, the following forms of breaking proceed simultaneously:

• Expectations appear after code review
  Only after implementation, it is pointed out as "different from assumptions."

• Specification confirmation is replaced by reference to past behavior
  The basis of correctness depends on history and memory.

• Changes are treated as the basis for specifications
  Implementation that happened to be entered becomes fixed as a reference point for subsequent specification decisions.

Consequences

• The distinction between specification changes and bug fixes becomes ambiguous
  (Part I: What Breaks — Responsibility / Data)

• Decision criteria are not shared, and discussions flow toward impressions
  (Part II: Why It Breaks — Context Erosion)

• New members and AI have no choice but to guess correctness
  Because assumptions and constraints are not made explicit, use as decision support is limited.
  (Part II: Why It Breaks — Context Erosion)

• Trust in specifications is gradually lost
  (Part I: What Breaks — Data / Responsibility)

Countermeasures

The following are not a list of solutions, but counter-patterns for changing dynamics with minimal intervention against Failure Mode.

• Explicitly handle what has not been decided
• Differentiate and articulate facts and expectations of behavior
• Do not try to write everything, but leave minimal specifications needed for decisions

Resulting Context

Specifications remain incomplete, and not everything is documented.

However, by making visible the parts that are undefined, discrepancies between expectations and implementation can be addressed early.

As a result, specifications function not as fixed deliverables, but as reference points that support decisions.

See also

• Context-Blind Change
  The foundational pattern in which absence of specifications becomes fixed as a structure when assumptions are not shared during changes.

• Test-Passing Illusion
  A derived pattern in which, in environments where explicit specifications do not exist, verification success tends to be treated as a substitute for correctness.

---

Appendix: Conceptual References

• Requirements & Knowledge
  Background of structures in which prerequisite knowledge needed for decisions is not treated as specifications.
• Information Hiding & Boundaries
  Background of failure structures in which undefined assumptions leak into implementation and behavior.
• Feedback, Measurement & Learning
  Background of dynamics in which verification results do not lead to learning without specifications.

Appendix: References

• Pamela Zave, Michael Jackson, Four Dark Corners of Requirements Engineering, 1997.
• Barry W. Boehm, Software Engineering Economics, 1981.
• Gojko Adzic, Specification by Example: How Successful Teams Deliver the Right Software, 2011.