SYSE.27:5 - Archetypal Grounding

In an invented software-platform example, a workflow interface accepts timeout: 5. In version v1 the optional integer is an elapsed-time limit in minutes, measured from acceptance to completion; supported values are 1–30 and omission means 5. Several repositories pin v1, and one rarely used recovery workflow still carries the old template.

A contributor changes the implementation to interpret the same value as seconds. The request still parses and the contribution’s example passes because its job completes in three seconds. Existing users can now time out after five seconds instead of three hundred. The proposed change is a versioned break, not an internal optimization.

The provider and contributor compare three repairs. Retaining only v1’s external integer-minute input avoids the break but cannot express the new seconds-level use. An explicitly named seconds parameter can add that use while preserving v1’s meaning; the internal duration unit can remain minutes if conversion preserves the requested limit. A new incompatible interface can also work, but it requires consumer migration.

The selected constructed design preserves v1’s external timeout contract and gives the new interface a separate timeout_seconds input. The new input accepts 60–1800 seconds, including a new 90-second use. The adapter translates an accepted v1 request into a request that expresses duration only through timeout_seconds. It maps v1’s 1, 5 and 30 minutes to 60, 300 and 1800 seconds; an omitted value also becomes 300. Values 0 and 31 remain invalid v1 requests. In an adverse attempt, the new interface receives a request containing both timeout: 5 and timeout_seconds: 90. Because the old field specifies 300 seconds and the new one 90, the interface rejects the request as ambiguous rather than choosing either value. A constructed attempt that completes after 240 seconds meets the old five-minute limit and the adapter’s 300-second limit, but not the silently changed five-second limit. Consumer examples include the infrequent recovery workflow, not only the contributor’s fast demonstration.

The result is a bounded change with an exercised compatibility account. An actual maintainer still has to accept and support it, and the version reaching a consumer remains a configuration question. A passing example does not authorize the contributor to update every repository.

Another team proposes a new language-specific build extension. The contribution entry can state its expected inputs, output and maintenance need, but without a qualified build Method and supported recovery it remains an unqualified proposal. The interface mechanism does not supply that missing professional result.

For a physical bench, a replacement fixture may match the mounting holes while changing the locating datum. A component can fit yet be measured relative to the wrong reference. The consumed behavior therefore includes the datum and measurement relation, not just bolt compatibility. A qualified fixture/measurement result is needed before the replacement is represented as compatible.

What changes in practice is the acceptance question: “Does it parse or fit?” becomes “Does this consumer obtain the promised result under the supported conditions, and who will sustain that result?”