Repairability

slug: repairability

one_liner: The scored design property of a physical artefact measuring how cheaply and reliably a failed instance can be restored by component replacement rather than whole-unit replacement — a conjunction of accessible disassembly, modularity, documentation, parts availability, and software support.

core_idea: Repairability is the design property of a physical artefact that determines how cheaply, quickly, and reliably a failed instance can be returned to functioning condition by replacement of faulty components rather than replacement of the whole unit. The property is not a single design choice but a conjunction of concrete physical, informational, and economic commitments: fasteners that are accessible and removable without destructive force (as opposed to adhesive bonding, welding, or ultrasonic welding that prevents non-destructive disassembly); a modular architecture with standardized interfaces that allow individual components to be identified, removed, and replaced without disturbing unrelated parts; documented diagnostics and service manuals that allow a technician to localize the fault; spare parts availability at a price ratio low enough that repair is economically rational compared to replacement; and tooling requirements within the reach of the target repair population (independent shop, consumer, or field technician). The canonical composite measure is the repairability index introduced by France in 2021 and adopted in EU ecodesign regulation, which scores a product across disassembly (fastener type, layer count, specialized tool requirements), documentation (availability and completeness of repair manuals and diagnostic tools), spare-parts availability (availability period and price ratio), and software support. The design discipline that produces repairability is *design for repair* or *design for serviceability*, part of the "design for X" tradition in engineering, which treats the repair scenario as a design constraint alongside manufacturing cost, performance, and reliability. The political economy of repairability is inseparable from the property: manufacturers have systematic incentives to minimize repairability (shorter replacement cycles, captive service revenue, software-locked serialized parts) that are countered by right-to-repair regulation, independent-repair-access requirements, and eco-modulation of extended-producer-responsibility fees that reward higher repairability scores. The property is specific to the geometry and material continuity of physical artefacts — it does not transfer as a mechanism to software, biological tissue, or social institutions, where the operations of disassembly and component replacement do not apply with the same content.

scope_of_application:
Because repairability is a scored *design property* of physical artefacts — whether a failed instance can be cheaply restored by component replacement — rather than a causal mechanism, it applies wherever the artefact's geometry and material continuity permit disassembly and replacement. The product classes below are genuine instances of the same property (one substrate at many scales); it does *not* transfer to software, tissue, or institutions, where "disassemble/reassemble" has no matching content — those are metaphor, and the portable skeleton there is the parent set (modularity + maintenance + accessibility + design-for-lifecycle-adaptability).

- **Design for X / serviceability** — the home discipline, with design-for-disassembly, modular product architectures, and fastener/joint selection treating repair as a design constraint.
- **Consumer electronics** — iFixit teardown scoring, Fairphone's modular phone, and the right-to-repair movement, where the repairability index is most visible.
- **Environmental and circular-economy policy** — the EU Right to Repair Directive, France's repairability index, and eco-modulated extended-producer-responsibility fees rewarding higher scores.
- **Automotive** — independent-repair access (Massachusetts Right to Repair), OBD-II diagnostic standardization, and third-party parts/service ecosystems.
- **Aerospace and medical devices** — line-replaceable units, field-replaceable modules, and MRO economics, where replacement is uneconomic so repairability is engineered in.
- **Public infrastructure** — roads, bridges, and water systems designed for inspection and repair as a lifecycle-cost lever.

structural_signature:
**Sig role-phrases:**

- **the physical artefact** — a device whose geometry and material continuity permit disassembly and component-level replacement
- **the accessible disassembly** — fasteners removable without destructive force (screws, clips, pull-tabs) rather than adhesive bonding, welding, or potting, with a low layer count and ordinary tooling
- **the modular architecture** — standardized interfaces letting individual faulty components be identified, removed, and replaced without disturbing unrelated parts
- **the documentation** — service manuals and diagnostics that let a technician localize the fault
- **the spare-parts availability** — parts stocked over a guaranteed horizon at a price ratio low enough that repair is economically rational versus replacement
- **the software support** — the absence of locks on serialized parts, so a swapped component will actually function
- **the target repair population** — the parameter indexing who does the repair (independent shop, consumer, field technician), since the same device can be repairable by one and not another
- **the composite index** — the scored vector (disassembly, documentation, parts, software support) rolled into one auditable repairability score
- **the repair-versus-replace verdict** — the outcome read off the scores: repair economically rational, or replacement forced
- **the anti-repair counter-incentive** — manufacturer incentives (shorter replacement cycles, captive service revenue, software-locked parts) that depress the scores, countered by right-to-repair regulation and eco-modulated producer-responsibility fees

what_it_is_not:
- **Not durability.** Durability is resistance to *failing in the first place*; repairability governs *recovery after* failure. The two are independent — a device can be highly durable and barely repairable (a rugged glued enclosure), or fragile and trivially repairable (a flimsy clip-together case). Conflating them hides that a long-lived product may still be unrecoverable once something breaks.
- **Not fault tolerance.** Fault tolerance keeps a system running *through* a failure without intervention (redundancy, graceful degradation); repairability is *intervention-based* recovery after the system has stopped working. One avoids the need to act; the other governs how cheaply someone can act once action is required.
- **Not modularity alone.** A modular architecture is necessary but not sufficient: repairability requires modularity *plus* accessibility, spare-parts availability, and documentation. The load-bearing case is the modular board sealed behind glue — high on decomposition, low on disassembly — which is modular yet unrepairable. Reading modularity as enough for repairability is the characteristic error the property guards against.
- **Not a single design choice or a vague "build quality."** Repairability is a *conjunction of scored sub-criteria* — disassembly (fastener type, layers, tooling), documentation, spare-parts availability and price ratio, software support — made auditable by the repairability index. "Well made" or "user-serviceable" names nothing measurable; each anti-repair choice (a proprietary screw, a software-locked serialized part) registers as a deliberate debit on a specific scored axis.
- **Not a substrate-spanning mechanism.** Repairability is built on the geometry and material continuity of *physical artefacts*; the operations "disassemble" and "replace a component" do not apply with the same content to software (you edit source or ship a patch), tissue, or institutions. "Institutional repairability" is metaphor unless it actually imports the disassembly–replacement–reassembly structure; the portable skeleton is the parent set — modularity, maintenance, accessibility, design-for-lifecycle-adaptability — not this named property.

clarity:
Naming repairability collapses a diffuse and unfalsifiable design conversation — "good build quality," "user-serviceable," "long-lasting" — into a conjunction of measurable sub-criteria: disassembly step count, fastener type, spare-parts price ratio, documentation completeness, software support period. The repairability index is exactly this move made operational: it forces the vague virtue to resolve into scores a regulator can audit and a buyer can compare. The sharper consequence is that anti-repair design stops being invisible. A glued enclosure, a proprietary screw, a software-locked serialized part — once repairability is a named and scored property, these read not as neutral engineering choices but as *deliberate optimization against repair*, which is precisely what makes the political economy of captive service revenue legible as a design decision rather than an accident of manufacturing.

The concept also sharpens repairability against the family of lifecycle properties it is constantly conflated with. *Durability* is resistance to failing in the first place; repairability is what governs recovery *after* failure — a device can be highly durable and barely repairable, or fragile and trivially repairable. *Fault tolerance* keeps a system running through failure without intervention; repairability is intervention-based recovery. *Modularity* is the architectural decomposition into swappable parts, but repairability requires modularity *plus* accessibility, parts availability, and documentation — a modular board sealed behind glue is modular and unrepairable. Holding these apart lets a designer ask the load-bearing question — not "is this well made?" but "when a component fails, can the target repair population economically restore function?" — and ties the answer directly to lifecycle cost, e-waste, and right-to-repair obligations that the diffuse vocabulary could never reach.

manages_complexity: Whether a failed product is worth repairing rather than discarding depends, in full, on a tangle of incommensurable particulars: the joining method at every interface, the layer count and disassembly path to each component, the tools a given repair population owns, the price and stocking horizon of each spare, the completeness of diagnostics, the software locks on serialized parts — and these vary product by product, component by component, and repairer by repairer. Adjudicating it case by case means re-deriving the whole repair scenario for every device and every fault. Repairability compresses that tangle by naming a single design *property* and resolving it into a fixed, scored set of sub-criteria — disassembly (fastener type, layers, special tools), documentation, spare-parts availability and price ratio, software support — that the repairability index makes into one auditable composite. The regulator, designer, and buyer then track a small vector of scores, or even one rolled-up number, instead of the unbounded physical-economic detail of each repair, and read the qualitative outcome — repair economically rational, or replacement forced — off that compressed measure. The compression is what makes the otherwise-invisible legible as a small set of decisions: each anti-repair choice (glued enclosure, proprietary screw, locked serialized part) now registers as a movement on a specific scored axis rather than a neutral detail buried in the bill of materials, so "optimization against repair" becomes a readable pattern in the scores rather than a suspicion. The same compression sorts repairability cleanly against the lifecycle properties it is constantly fused with, via a small branch structure rather than case analysis: durability is failure-resistance (whether the artifact fails), repairability is post-failure recovery (whether it can be restored), fault tolerance is uninterrupted operation through failure (no intervention), and modularity is mere architectural decomposition — so a device can sit at any combination of these, and the designer reads which property is at issue from which axis is in play (a modular board sealed in glue scores high on decomposition and low on disassembly, and is therefore unrepairable despite being modular). And because the property is scored, the downstream couplings the diffuse vocabulary could never reach become functions of the same small vector: lifecycle cost, e-waste volume, and right-to-repair compliance all read off the disassembly-documentation-parts-software scores. So a per-device, per-fault adjudication spanning physical geometry, parts economics, and service politics reduces to tracking a handful of scored axes, from which the repair-versus-replace outcome, the anti-repair design pattern, and the lifecycle and regulatory consequences are all read rather than reconstructed.

abstract_reasoning:
Repairability licenses reasoning moves a product designer, regulator, or repair technician runs on any physical artefact, all conducted on a small vector of scored axes — disassembly, documentation, spare-parts availability and price ratio, software support — that stands in for the unbounded physical-economic detail of an actual repair.

The economic-rationality move runs from the scored axes to a repair-versus-replace verdict for a given fault. The reasoner asks not "is this well made?" but "when a component fails, can the target repair population economically restore function?", and computes the answer from the axes: the disassembly path and tooling determine labor, the spare-parts price ratio against the cost of a new unit determines whether repair is cheaper than replacement, the documentation determines whether the fault can even be localized, and the software locks determine whether a swapped serialized part will function. The prediction is binary — repair economically rational, or replacement forced — and it reads off the compressed measure rather than a fresh case analysis, with the *target repair population* a parameter: the same device may be repairable by an independent shop with specialized tools and unrepairable by a consumer, so the verdict is indexed to who is doing the repair.

The diagnostic move reads anti-repair *intent* off the scores. Once repairability is a named and scored property, the reasoner treats a glued enclosure, a proprietary screw, or a software-locked serialized part not as a neutral engineering detail buried in the bill of materials but as a *deliberate movement on a specific scored axis* — a debit on disassembly, on parts availability, on software support. This licenses an inference from the pattern of low scores to *optimization against repair*, which in turn makes the political economy legible: a product that scores low precisely on the axes that gate independent service is read as engineered for captive service revenue or shortened replacement cycles, not as an accident of manufacturing. The move is to infer the manufacturer's incentive from where the scores were sacrificed.

The boundary-drawing move sorts repairability against the lifecycle properties it is constantly fused with, by asking which axis is in play, and it guards a characteristic error. The reasoner distinguishes *durability* (resistance to failing in the first place — a property of *whether* the artefact fails) from repairability (recovery *after* failure), *fault tolerance* (running through failure without intervention) from repairability (intervention-based recovery), and *modularity* (architectural decomposition into swappable parts) from repairability (which requires modularity *plus* accessibility, parts, and documentation). The load-bearing case is the modular board sealed behind glue: it scores high on decomposition and low on disassembly, so the reasoner predicts it is *unrepairable despite being modular* — the error the distinction prevents is reading modularity as sufficient for repairability. A device can occupy any combination of these properties, and the reasoner identifies which one is at issue from which axis the question touches.

The interventionist move treats each axis as a lever and predicts the downstream effect of moving it. Because lifecycle cost, e-waste volume, and right-to-repair compliance all read off the same disassembly-documentation-parts-software vector, the designer or regulator forecasts the consequence of a design change as a movement on a specific axis: replacing adhesive with a pull-tab raises the disassembly score, which is predicted to raise independent-repair rates and extend service life; publishing the service manual raises documentation; shortening the guaranteed spare-parts horizon lowers parts availability and is predicted to force replacement once stocks lapse. The reasoning runs from a scored-axis change to its predicted effect on repair behavior and on the coupled lifecycle and regulatory outcomes, so the policy lever (eco-modulation of producer-responsibility fees rewarding higher scores, mandated parts availability) and the design lever (fastener choice, interface standardization) are reasoned about as operations on the same small vector rather than as separate, incommensurable interventions.

knowledge_transfer:
Within engineering design-for-X and its adjacent product and policy fields the property transfers *as mechanism*, and what carries is the whole apparatus: the scored-axis vector (disassembly, documentation, spare-parts availability and price ratio, software support), the repair-versus-replace verdict indexed to the target repair population, the diagnostic that reads anti-repair intent off where the scores were sacrificed, and the interventionist treatment of each axis as a lever with downstream lifecycle and regulatory consequences. The precondition is a *physical artefact* whose geometry and material continuity permit disassembly and component replacement, and across product classes each is a genuine instance of the same property rather than a likeness — consumer electronics (iFixit scoring, Fairphone's modular phone), automotive independent-repair access (OBD-II standardization, parts catalogues), aerospace and medical line-replaceable units and MRO economics, and public infrastructure designed for inspection and repair as a lifecycle-cost lever. The transfer is mechanism-preserving because these are *one substrate* — physical artefacts with the disassembly/replacement operations — at many product scales, so the index, the verdict, and the levers carry intact, not by analogy.

Beyond physical artefacts the report is twofold, and the boundary is sharp because the property is built on physical structure. (1) The named property does **not** transfer as a mechanism to software, biological tissue, or social institutions: the operations "disassemble" and "reassemble" do not apply there with the same content — software "repair" is editing source, deploying a patch, opening an API, a structurally different operation — so calling those "repairability" is *metaphor*, and "institutional repairability" is metaphor unless it actually imports the disassembly–replacement–reassembly structure rather than just the vibe. Such uses should be marked as analogy. (2) The genuinely portable content is one level up and is already owned by parent primes that travel across substrates in their own right: the general skeleton — *engineer the artefact so that intervention-to-restore-function is locally accessible and cheap* — decomposes into `modularity` (decomposition into independently swappable parts), `maintenance` (sustained intervention that keeps intended function intact against degradation), `accessibility` (the cost of reaching the point of intervention), and `design_for_lifecycle_adaptability` (planning for change over the lifecycle). Stripped of physical-artefact context, repairability *is* "modularity for replacement plus easy access for intervention," so the cross-domain lesson should carry those parents, not the name "repairability," whose distinctive cargo (the repairability index and iFixit scoring, fastener-type tables and parts-availability schedules, and the manufacturer/independent-shop/consumer political economy of right-to-repair and post-warranty access) is mechanical-engineering-and-consumer-protection furniture that does not and should not travel. Mechanism within physical-artefact design (one substrate at many product classes); metaphor beyond, with the genuine portable skeleton resident in the *parent primes* (modularity + maintenance + accessibility + design-for-lifecycle-adaptability) it instantiates rather than in this named property. This is exactly the boundary *Structural Core vs. Domain Accent* draws.


Replacement Relation

one_liner: Record that a distinct successor resource takes over a predecessor's canonical standing and flags it obsolete, as a bidirectional machine-routable link, so consumers read currency off the chain rather than inspecting the artifacts themselves.

status: draft

core_idea:
A replacement relation is a directed, time-asymmetric assertion that one resource — the *successor* — supersedes another — the *predecessor* — for a stated function or context, with the predecessor simultaneously marked obsolete and downstream consumers directed to migrate. Three structural roles are always present: predecessor (the thing being replaced), successor (the thing doing the replacing), and role-context (the function for which the successor now stands in). The defining feature is *role-transfer with a deprecation flag*: this is not the same resource revised in place (revision), not a second name added to the same resource (aliasing), and not a sequentially numbered edition with no obsolescence claim (versioning) — it is a *new resource taking over a prior resource's canonical standing*, with the prior resource explicitly retired from that standing. Operationalized in Dublin Core / DCMI Terms as the bidirectional pair `dcterms:isReplacedBy` (on the predecessor) and `dcterms:replaces` (on the successor), making the relation machine-routable in both directions.

The mechanism is the same across substrates: ISO 9001:2015 carries `isReplacedBy` pointing to the next edition and `replaces` pointing to ISO 9001:2008; RFC 8446 headers list "Obsoletes: RFC 5246"; a Python library deprecates a function with `@Deprecated(replacement = "newFn")`; a clinical-decision-support registry marks CDS-127 superseded by CDS-340 with a transitional banner for legacy charts. In each case the replacement relation encodes a governance decision — *hard* replacement (predecessor immediately invalid, forcing migration) or *soft* replacement (a transitional coexistence window) — and the choice between them trades migration disruption against fragmentation risk. The bidirectional pair lets any consumer either follow the chain forward to the current canonical resource or walk it backward to predecessors for archival, reproducibility, or legacy-compatibility purposes.

scope_of_application:
A replacement relation is a recorded metadata link rather than a mechanism, so it appears wherever its precondition holds: a *distinct* successor resource takes over a predecessor's canonical standing, the predecessor is flagged obsolete, and consumers need a machine-routable forward/backward edge to find the live resource or recover what it retired. The habitats below are genuine uses of the same construct (the directed `dcterms:replaces` / `isReplacedBy` pair, or its domain equivalent), not analogies; its edge is the precondition — the broader metaphor of one *thing* superseding another (paradigm change, S-curve generations, species succession) belongs to a more general supersession pattern, not to this recorded relation.

- **Standards and regulations** — a core habitat. ISO 9001:2015 carries `isReplacedBy`/`replaces` against the 2008 edition with a transitional period; an RFC's "Obsoletes:" header points to the standard it supersedes; a new regulation supersedes an older directive.
- **Software versioning and deprecation.** API v2 over v1, Python 3 over Python 2 with migration tooling, and source-level annotations like `@Deprecated(replacement="newFn")` all record a successor and retire the predecessor.
- **Technical-document and dataset versioning.** A v2.0 release supersedes v1.0 while v1.0 is preserved for reproducibility, with the obsolescence recorded on the link rather than the artifact.
- **Taxonomic revision.** Nomenclatural databases record a senior synonym superseding a junior one when a synonymy is resolved, with the predecessor retained in the literature record.
- **Industrial and product lifecycle.** Parts catalogues maintain replacement links from a decommissioned part to its successor to support continued service.
- **Policy and procedure governance.** An updated SOP supersedes an older one with a recorded cut-over date, marking the predecessor no longer canonical for the role.

structural_signature:
**Sig role-phrases:**

- **the predecessor** — the resource being superseded and stripped of its canonical standing
- **the successor** — the distinct resource taking over the predecessor's role
- **the role-context** — the stated function for which the successor now stands in (allowing partial, per-context obsolescence)
- **the deprecation flag** — the obsolescence mark on the predecessor; *role-transfer-plus-deprecation* is the defining feature that picks replacement out
- **the bidirectional pair** — `dcterms:replaces` / `dcterms:isReplacedBy`, making the relation machine-routable forward (live successor) and backward (predecessors)
- **the four-way cut** — the boundary distinguishing replacement from revision (in-place edit), aliasing (added name, no time-arrow), and versioning (editions, no obsolescence claim)
- **the hard/soft governance choice** — the recorded decision: hard (predecessor immediately invalid, forced migration) versus soft (transitional coexistence window), trading migration disruption against fragmentation risk
- **the read-currency-off-the-chain affordance** — consumers judge authority by traversing the relation, not by inspecting artifact content
- **the cycle failure-check** — a replacement cycle (A replaces B, B replaces A) visible in the chain as a modelling error (or a signal to inspect governance history)
- **the governance-convention limitation** — DCMI machinery and lifecycle naming, not a substrate-independent force; off-substrate the content belongs to substitutability plus an emergent supersession pattern

what_it_is_not:
- **Not revision.** Revision modifies the *same* resource in place; replacement introduces a *distinct* successor that takes over the predecessor's canonical standing and explicitly retires it. The test is whether the predecessor still holds its role (revision) or has been stripped of it (replacement) — and mislabeling a true supersession as a revision leaves obsolete resources presenting as current.
- **Not versioning.** Versioning issues sequentially numbered editions of one resource family with *no obsolescence claim*; replacement carries a deprecation flag that marks the predecessor no-longer-canonical for the role. Numbered editions without an arrow of retirement are versioning, not replacement.
- **Not aliasing.** Aliasing adds a *second name* to the same resource and is time-symmetric — neither name supersedes the other. Replacement is directed and time-asymmetric: predecessor → successor, with the predecessor demoted. An added name is not a role-transfer.
- **Not substitutability.** Substitutability is the *symmetric* property that one component can fill another's role under a shared interface (interchangeable parts, polymorphic types); replacement is *directed supersession* carrying an arrow of time and a deprecation flag substitutability lacks. Mere role-fillability with no obsolescence and no time-order is not a replacement claim.
- **Not dependency or inheritance.** A successor may normatively *reference* its predecessor, but the replacement relation is the *succession* claim itself, not the reliance; and inheritance is a child taking *structure* from a parent, whereas replacement is a successor taking a *role* with the predecessor's obsolescence. The succession arrow is neither a dependency edge nor a structural-inheritance edge.
- **Not a substrate-independent supersession force.** The role-takeover content sits with `substitutability` and a broader (still-emergent) `supersession` pattern that would unify document replacement with paradigm change, technology S-curves, and species succession. The replacement relation is the document- and standards-*governance* instance with its `dcterms:replaces`/`isReplacedBy` pair and transitional-banner machinery; the time-asymmetric, obsolescence-flagged qualification is a lifecycle convention, not a new structural force, so the cross-domain lesson belongs to those parents.

clarity:
Naming a change as *replacement* — rather than the loose "update" or "new version" — separates four moves on a resource over time that governance practice constantly conflates. *Revision* is the same resource modified in place; *aliasing* adds a second name to the same resource with no temporal direction; *versioning* issues sequentially numbered editions of one resource family with no obsolescence claim; *replacement* introduces a *distinct* resource that takes over a prior one's canonical standing while explicitly retiring it from that standing. The defining feature that picks replacement out is *role-transfer with a deprecation flag* — and recognizing it tells a steward whether the predecessor still holds its role (revision, versioning) or has been stripped of it (replacement). Mislabeling here has teeth: treating a true supersession as a mere revision leaves obsolete resources presenting as current, and consumers acting on retired guidance.

The relation also makes a lifecycle *navigable in both directions*, which sharpens the questions a consumer can ask. Because obsolescence is recorded on the relation rather than only on the resource, one can resolve forward — "what is the live successor?" — to reach current canonical standing, or walk backward — "what did this replace?" — for archival, reproducibility, or legacy-compatibility purposes, and can express *partial* obsolescence where a predecessor stays valid for some contexts while retired for others. It further forces an explicit governance choice the field is built to encode: *hard* replacement, invalidating the predecessor at once and forcing migration, versus *soft* replacement, allowing a transitional coexistence window. Stating that choice in the relation turns "migration disruption versus fragmentation risk" from an implicit cost into a decision a registry can record and a consumer can read.

manages_complexity: The history of an evolving artifact — successive standards editions, deprecated APIs, dataset versions, superseded rules — is, without an explicit relation, an undifferentiated pile of documents from which a consumer holding any one reference must somehow determine whether it is still authoritative and, if not, what now carries its standing, by reading and comparing the artifacts themselves. The replacement relation compresses that pile into a directed, navigable chain governed by a small fixed vocabulary. Each link records exactly three roles — predecessor, successor, role-context — plus an obsolescence flag, and because the relation is stored as the bidirectional `dcterms:replaces` / `dcterms:isReplacedBy` pair, the whole lifecycle becomes machine-routable in both directions. A consumer no longer inspects the artifacts to judge currency; he follows the chain forward to resolve the live canonical successor, or walks it backward to recover predecessors for archival, reproducibility, or legacy use, reading currency off the chain rather than re-deriving it from content. The relation also reduces the open question "how should this change be handled?" to a single recorded governance choice with a fixed branch structure: *hard* replacement invalidates the predecessor at once and forces migration, *soft* replacement opens a transitional coexistence window — and that one flag, plus an optional context-scope for partial obsolescence, is what the steward sets and the consumer reads to know whether to migrate now, migrate within a window, or keep using the predecessor for the contexts where it remains valid. The same reduction also exposes a clean failure check: a replacement *cycle* (A replaces B, B replaces A) is visible directly in the chain as a modelling error. So the high-dimensional "is this current, what superseded it, and must I move?" problem collapses to three roles per link, one hard/soft flag, and forward/backward traversal of a directed chain — and the chain's distinctness from revision, aliasing, and versioning, which the Clarity section draws, is exactly what keeps each tracked artifact in the right one of those four buckets so the traversal means what it says.

abstract_reasoning:
The replacement relation licenses a set of reasoning moves built on two structural facts: that the relation is *directed and time-asymmetric* (predecessor → successor, with an obsolescence flag), and that it is stored as a *bidirectional* pair, so the lifecycle can be traversed and reasoned over in both directions.

*Diagnostic — read currency off the chain, not the artifact, and resolve forward or backward as the need dictates.* The characteristic inference refuses to judge an artifact's authority by inspecting its content. Holding any one reference, the analyst follows the `isReplacedBy` edge forward to resolve the live canonical successor, or walks `replaces` backward to recover predecessors for archival, reproducibility, or legacy use — reading currency off the relation rather than re-deriving it from the documents. Because obsolescence is recorded on the *relation* rather than only on the resource, the move supports a sharper read than "current or not": a predecessor can be *partially* obsolete, retired for some contexts (current production, new contracts) while still valid for others (reproducing a historical recommendation, legacy compatibility), so the analyst infers validity *per context* from the relation's scope rather than treating the artifact as wholesale live or dead. The inference runs from "I have a reference" to "the chain tells me whether it still holds its role, and if not, what does."

*Diagnostic of change-type — classify the move as replacement only when role-transfer-plus-deprecation is present, and route the other three elsewhere.* The concept's sharpest move is to pick replacement out of four look-alikes by testing for its defining feature. Revision is the same resource modified in place; aliasing adds a second name with no temporal direction; versioning issues sequentially numbered editions with no obsolescence claim; replacement introduces a *distinct* resource that takes over a prior one's canonical standing while explicitly retiring it. The inference runs from the structure of the change to the right bucket: ask whether the predecessor still holds its role (revision, versioning) or has been stripped of it (replacement). The stakes are operational — mislabeling a true supersession as a mere revision leaves obsolete resources presenting as current and consumers acting on retired guidance — so the move is to withhold the replacement classification unless both role-transfer and the deprecation flag are present, and to route in-place edits, added names, and obsolescence-free editions to their own categories.

*Interventionist — encode the hard/soft governance choice in the relation, and predict the trade-off each branch forces.* Because the relation is where the governance decision lives, the move is to set the obsolescence flag deliberately and predict its consequences. A *hard* replacement invalidates the predecessor at once and forces migration, predicting eliminated fragmentation at the cost of migration disruption; a *soft* replacement opens a transitional coexistence window, predicting reduced migration shock at the cost of an extended maintenance burden and fragmentation risk. The choice is read as a position on "migration disruption versus fragmentation risk," and the move turns that implicit cost into a decision a registry can record and a consumer can read — so a steward sets hard-or-soft (plus an optional context-scope and transitional window), and every downstream consumer reads off whether to migrate now, migrate within a window, or keep using the predecessor where it remains valid.

*Boundary-drawing and failure-check — separate succession from symmetric substitution, and detect cycles as modelling errors.* Two further moves. First, the boundary against symmetric interchangeability: replacement is *time-asymmetric supersession with deprecation*, distinct from the symmetric property that one component can fill another's role under a shared interface — so the move is to reserve the replacement analysis for a directed succession claim and not conflate it with mere role-fillability that carries no obsolescence and no arrow of time. It is likewise distinct from a successor merely *depending on* its predecessor (the succession claim is not the reliance) and from transformation *of the same artifact* (replacement introduces a new artifact). Second, a clean failure-check the directed structure exposes: a replacement *cycle* (A replaces B, B replaces A) is visible directly in the chain as a modelling error, and the move is to flag it — while recognizing that real systems do produce them (a deprecation reversed after community pushback, a standard re-instated after a failed successor), so the cycle is read as a signal to inspect the governance history, not merely as malformed data.

knowledge_transfer:
Within resource governance and versioning the discipline transfers *as mechanism*, intact. The role-transfer-plus-deprecation test, the four-way cut that picks replacement out of revision, aliasing, and versioning, the read-currency-off-the-chain diagnostic, the hard-versus-soft governance choice, and the bidirectional forward/backward traversal carry without translation across any artifact ecosystem with a successor-supersession lifecycle: standards and regulations (ISO 9001:2015 replacing 9001:2008 with a transitional period; an RFC's "Obsoletes:" header; a regulation superseding a directive), software versioning and deprecation (API v2 over v1, Python 3 over 2 with migration tooling, `@Deprecated(replacement=...)`), technical-document and dataset versions (a v2.0 superseding v1.0 while preserving v1.0 for reproducibility), taxonomic revision (a senior synonym superseding a junior one while the predecessor remains in the literature), product lifecycle (a replacement part with catalogue links to support service over decommissioning), and policy/SOP cut-overs. The vocabulary (transitional period, deprecation notice, migration tooling, backward-compatibility window) travels with structure preserved, and a particularly clean within-domain transfer is software's semantic-versioning convention ("major increment = breaking replacement; minor/patch = revision") being adopted, under other names, by standards bodies governing dataset and document lifecycles. These are co-substrate governance/lifecycle settings, so the transfer is genuine.

Beyond resource governance the honest account is the third category, with thin daylight: the substrate-independent structural force — *time-asymmetric supersession with an obsolescence flag* — sits adjacent to existing primes and points at a more general one, while the entry's own DCMI machinery stays home. The role-takeover part is `substitutability` (one component filling another's role under a shared interface) — except that substitutability is *symmetric* and replacement is *directed*, carrying an arrow of time and a deprecation flag substitutability lacks; the time-asymmetric, obsolescence-flagged qualification is more a governance/lifecycle convention than a new substrate-independent force. The genuinely cross-domain pattern, if surfaced, is a broader `supersession` parent prime that would unify document/standard replacement with Kuhnian paradigm change (a theory superseding its predecessor), technology-generation S-curve replacements, biological-fitness displacement, and ecological species succession — co-instances in which one thing takes over another's canonical standing and the prior is retired. Where that cross-domain lesson is wanted it should be carried by `substitutability` (for the role-transfer) plus the emergent supersession pattern (for the directed obsolescence), *not* by "replacement relation" as named, whose distinctive cargo (`dcterms:replaces` / `dcterms:isReplacedBy`, the four-way revision/aliasing/versioning/replacement vocabulary, transitional banners, migration channels) is document- and standards-governance furniture. The entry's own negative-space limit confirms this: its distinction discipline ("do not collapse persistence, replacement, revision, and aliasing") operates at the level of *resource-lifecycle naming conventions*, a governance practice, not at the level of a substrate-independent pattern. So the replacement relation is the document-governance instance; the substrate-spanning content belongs to substitutability and the broader supersession pattern it would instance — exactly the split drawn in *Structural Core vs. Domain Accent*.


Representativeness Heuristic

one_liner: Judge how probable, frequent, or generatively plausible an outcome is by how closely it resembles a category prototype or expected process pattern, so typicality silently replaces the target quantity and becomes systematically misleading when base rates, sample size, or set inclusion disagree.

origin_subdomain: judgment

core_idea:
The representativeness heuristic estimates probability, frequency, or category membership from how closely a case resembles a prototype or an expected generating process. Typicality silently substitutes for the target quantity, creating predictable errors when base rates, sample size, or set inclusion disagree with resemblance.

The canonical identity is narrower than the phrase’s everyday use. There is a probabilistic or categorical target, a salient prototype or process image, a resemblance judgment, substitution of that judgment for the target computation, and insufficient correction for formal constraints.

scope_of_application:
Diagnosis, hiring, investing, forecasting, and everyday judgment preserve one human cognitive shortcut. The domains vary; the psychological mechanism does not become substrate-neutral when moved among them.

A shared label or downstream consequence is insufficient; the load-bearing roles must survive.

structural_signature:
- A human reasoner is asked for a probability, frequency, classification likelihood, or generative-process judgment that is not immediately available.
- A case, sequence, or scenario has an accessible resemblance to a category prototype or to the pattern the reasoner expects a process to emit.
- The judge silently substitutes that resemblance or typicality assessment for the requested probabilistic quantity.
- The substitution is rapid and usually unregistered, so the answer feels like a direct probability judgment rather than a proxy response.
- The proxy can be ecologically useful when resemblance tracks the target, but it produces a signed error when base rates, sample size, regression, or set inclusion oppose the resemblance cue.
- The mechanism is broader than any one resulting error: omitted priors, conjunction-order reversals, and short-sequence balancing expectations are distinct manifestations.
- A corrective must restore the displaced formal structure, such as an explicit prior, nested-set decomposition, natural-frequency frame, or independence and sample-size audit.

what_it_is_not:
Attribute substitution is the broader mechanism. Base-rate neglect and conjunction fallacy can be consequences. Availability substitutes ease of retrieval rather than resemblance. Stereotyping is a social-category application but not the entire heuristic.

- Representative sampling concerns whether a selected subset mirrors a target population; no judging mind or typicality substitution is required.
- Generic pattern recognition can correctly identify resemblance without reporting it as probability or frequency.
- Stereotyping supplies one possible social-category prototype but representativeness also operates on event sequences, occupations, diseases, and abstract scenarios.
- Availability substitutes retrieval ease rather than typicality and is a sibling mechanism under attribute substitution.
- Attribute substitution is the broader operation and includes affect, availability, and other accessible attributes besides resemblance.
- A sound model using an explicitly chosen similarity feature does not instantiate the heuristic unless the target-proxy swap is unregistered in a reasoning agent.

clarity: Representativeness Heuristic separates a specific relation from neighboring ideas that can produce similar observations. Attribute substitution is the broader mechanism. Base-rate neglect and conjunction fallacy can be consequences. Availability substitutes ease of retrieval rather than resemblance. Stereotyping is a social-category application but not the entire heuristic.

manages_complexity: The abstraction compresses recurring cases into one inspectable model. An analyst can track the structural roles, compare mechanisms, and locate exactly which missing commitment invalidates an analogy.

abstract_reasoning: Identify the candidate roles, test the defining relation, then challenge the nearest boundary case. Using resemblance as evidence inside a correctly calibrated Bayesian classifier is not the heuristic if base rates and likelihoods remain explicitly integrated.

knowledge_transfer: Diagnosis, hiring, investing, forecasting, and everyday judgment preserve one human cognitive shortcut. The domains vary; the psychological mechanism does not become substrate-neutral when moved among them. Transfer is warranted only when the same causal, formal, or relational work survives.

notes: _(Canonical first draft from the adjudicated missing-node gate. Queued for Claude house-style re-authoring and independent citation review; no citations have been fabricated.)_


Request-Response

one_liner: Treat any bounded network exchange as one shape — an initiator's addressed request causally paired to one responder's reply over a return path — so the same fixed checklist of addressing, correlation, retry, idempotency, and error handling applies regardless of payload.

core_idea:
Request-response is the distributed-systems interaction pattern in which one party (the *initiator*) sends an addressed message — the request — carrying a need, a command, or a query, and the addressed party (the *responder*) returns a paired message — the response — carrying the answer, acknowledgement, or error. The four structural commitments that define the pattern are: (a) *role asymmetry* — the two parties occupy distinct, non-interchangeable positions for the duration of the exchange, the initiator starting and the responder replying; (b) *causal pairing* — each response is produced in direct causal consequence of exactly one request and is correlated to it through a shared identifier, session context, or reply-to address; (c) *return path* — the responder possesses or can derive a channel back to the initiator, so the response can be routed; (d) *one-shot scope* — the unit of exchange is the paired (request, response) and is complete when the response is delivered, even if multiple such units are chained into longer interactions.

The pattern is foundational to network-services engineering because *whenever two parties must coordinate around a discrete, bounded information exchange across an unreliable network, the same set of engineering problems arises regardless of the application domain*: addressing the responder, correlating the response to the originating request, distinguishing a missing response from a negative response, determining how long to wait before retrying, ensuring a retry does not produce duplicate effects, and classifying error conditions by their type (transport failure, application error, semantic error). These problems are solved, in the distributed-systems substrate, by the mechanism-family that HTTP, RPC, REST, gRPC, SOAP, and database client/server protocols all implement: request identifiers or idempotency keys for correlation, timeout deadlines with exponential backoff for retry discipline, structured error envelopes with layered status codes, and idempotency tokens to make retry-safe what would otherwise be stateful operations.

HTTP instantiates the pattern in its canonical form: a client sends a method-plus-URI request with optional headers and body; a server returns a status code, headers, and optional body; the TCP connection or an explicit request identifier correlates them. REST builds a resource-oriented application layer on top of this exchange primitive. gRPC uses protocol-buffer framing and HTTP/2 multiplexing for the same underlying pattern. In each case the engineering discipline for handling timeout ambiguity, retry safety, and error classification is shared across applications because it derives from the pattern's structure, not from application semantics.

scope_of_application:
Request-response lives across the distributed-systems family, in the protocols and services that coordinate an addressed, causally-paired, one-shot exchange across an unreliable network; its reach is within that family, because the engineering discipline that gives it substance (correlation IDs, retry-with-idempotency, timeout backoff, error envelopes) only has content where those network hazards are present. The same exchange *shape* recurs in law, medicine, and conversation, but that travels via the parent `interaction_pattern` / `adjacency_pair` primes, not via "request-response" with its discipline attached.

- **HTTP and the REST layer above it** — the canonical instantiation: a method-plus-URI request answered by a status-code response, with the resource-oriented application layer built on the exchange primitive.
- **RPC frameworks** — gRPC (protocol-buffer framing over HTTP/2 multiplexing), SOAP, and JSON-RPC, the same paired exchange under different framing.
- **Query protocols** — GraphQL queries and database client/server protocols, where the response carries a result set or a structured error.
- **Enterprise message queues** — request/reply over messaging middleware, inheriting the same correlation, timeout, and idempotency discipline.

structural_signature:
**Sig role-phrases:**

- **the initiator** — the party that originates the exchange with a need, command, or query (the request)
- **the responder** — the addressable party that produces a paired reply (the response)
- **the role asymmetry** — the two parties occupy distinct, non-interchangeable positions for the exchange's duration: one starts, the other replies
- **the causal pairing** — each response is produced in direct consequence of exactly one request, correlated through a shared identifier, session, or reply-to address
- **the return path** — the channel back to the initiator the responder possesses or can derive, so the reply can be routed
- **the one-shot scope** — the unit of exchange is the paired (request, response), complete on delivery, even when chained into longer interactions
- **the timeout ambiguity** — the central hazard: a missing reply is indistinguishable among request-lost, responder-slow, response-lost, and responder-failed
- **the retry-safety/idempotency condition** — the correctness requirement that a resent request be detected as a duplicate or produce the same effect as one (so at-least-once becomes effectively-once)
- **the error classification** — the partition of a non-success reply into transport failure, application error, and semantic error, separating "no answer yet" from "the answer is no"
- **the interaction-pattern branch** — the prior classification (request-response versus publish-subscribe, streaming, fire-and-forget, event-driven) that selects which engineering checklist is even live

what_it_is_not:
- **Not just "one party asks, the other replies" wherever that shape appears.** The exchange *shape* recurs in law, medicine, and conversation, but the engineering discipline that gives request-response its substance — correlation IDs, retry-with-idempotency, timeout backoff, error envelopes — does not follow, because the unreliable-network hazards that motivate it are absent. Calling a court motion a "request" is harmless but changes no practice; importing the apparatus there is metaphor.
- **Not inherently synchronous or blocking.** One-shot scope describes the *unit* (a reply causally paired to one request), not the calling style: the same structure is implemented blocking, with callbacks, or via promises/futures. Treating request-response as "the synchronous pattern" confuses the exchange unit with one way of waiting for it.
- **Not a case where a missing reply means the responder failed.** At the initiator a missing response is a genuine *four-way* ambiguity — the request was lost, the responder is slow, the response was lost, or the responder failed — and these are indistinguishable from the initiator's vantage. Collapsing "the call didn't return" to "it failed" hides exactly the fork the design must resolve.
- **Not a pattern where "no answer" equals "the answer is no."** A *missing* response and a *negative* response (a structured error envelope) are distinct: the former routes to retry discipline, the latter to error handling. Conflating "no answer yet" with "the answer is no" mishandles both.
- **Not safe to retry by default.** Because the initiator cannot tell whether the responder already acted, a resent request must be detected as a duplicate via a correlation/idempotency key or produce the same effect as a single request — otherwise resending a stateful operation double-charges or double-applies. Retry-safety is a correctness condition to engineer (idempotency), not a free property of the pattern.
- **Not a dialogue or a transaction.** A dialogue is a multi-turn ongoing exchange with topic management; request-response is the one-shot paired unit dialogues are partly *composed of*. A transaction adds atomicity and isolation guarantees on top of an exchange; request-response carries no such guarantees. Equating it with either over-reads the bounded pair.

clarity:
Naming request-response carves it cleanly out of the space of interaction patterns it is easily confused with, and the boundaries are load-bearing for design. It is not *publish-subscribe* (the producer broadcasts to subscribers it need not address, with no paired reply), not *streaming* (a continuous flow rather than a bounded one-shot pair), not *fire-and-forget* (a request with no response expected), and not *event-driven* reaction (the responder acts on events rather than on an addressed request). Fixing which of these an exchange is tells an engineer immediately which problems they own: a request-response exchange must address a responder, correlate the reply to its originating request, and decide what a missing reply means — questions that simply do not arise for a fire-and-forget emit or a broadcast.

The deeper clarification is that the engineering hazards of request-response are properties of the *pattern*, not of any application's semantics — so naming the pattern makes those hazards askable up front rather than discovered in production. The sharpest is *timeout ambiguity*: a missing response is genuinely indistinguishable, at the initiator, among "the request was lost," "the responder is slow," "the response was lost," and "the responder failed" — and recognizing the exchange as request-response is what surfaces that four-way ambiguity as something the design must resolve, rather than letting it hide behind "the call didn't return." That single recognition forces the connected questions into view — how long to wait before retrying, and whether a retry is *safe* (idempotent) or will double-charge — and separates a *missing* response from a *negative* one (an error envelope), so that "no answer yet" and "the answer is no" stop being conflated. The label thus turns "design this network interaction" into a fixed checklist of structural questions — addressing, correlation, retry discipline, idempotency, error classification — that every HTTP, RPC, or gRPC exchange inherits regardless of what it is transporting.

manages_complexity:
Every networked application presents, on its surface, a different coordination problem: a payment charge, a database query, a file fetch, a remote procedure call, an inventory lookup, an authentication check. Approached application by application, each looks like a fresh exercise in getting two machines across an unreliable network to agree on what happened — and the engineering required (how to address the far party, what to do when nothing comes back, whether resending is safe) seems to have to be reasoned out anew from the semantics of charging a card versus reading a row versus locking a file. Request-response collapses that apparent diversity to a single recognition: all of these are the *same* exchange shape — one initiator, one addressed responder, a reply causally paired to exactly one request over a return path, complete in one shot — and therefore raise *exactly one* set of engineering problems, fixed by the shape and independent of what the message carries. The sprawl of distinct application interactions reduces to one structural unit whose hazards are known in advance.

What the engineer then tracks is not the application's meaning but a small fixed checklist that the pattern emits the moment an exchange is classified as request-response: addressing, correlation of reply to originating request, retry discipline, idempotency, and error classification. Each item has a known mechanism-family — request identifiers or idempotency keys for correlation, timeout deadlines with exponential backoff for retry, structured error envelopes with layered status codes — so designing a new interaction is reading down that list and instantiating each slot, not deriving the requirements from scratch. The payoff is sharpest at the pattern's central hazard, *timeout ambiguity*: a missing reply is genuinely indistinguishable among request-lost, responder-slow, response-lost, and responder-failed, and instead of confronting that four-way fork freshly per service, the engineer reads it as a fixed property of the unit, resolved once by the same retry-plus-idempotency discipline everywhere — and the related fork, "no answer yet" versus "the answer is no," is settled by the error-envelope slot rather than rediscovered.

The compression's branch structure lives one level up, in *which* interaction pattern is in play, and it is what bounds the work. Fixing an exchange as request-response — rather than publish-subscribe, streaming, fire-and-forget, or event-driven — selects the checklist that applies and, just as usefully, discharges the questions that do not arise: a broadcast has no reply to correlate, a fire-and-forget emit has no timeout to resolve, a stream is not one-shot. So the analyst makes a single classifying decision and inherits a closed, finite set of owned problems with off-the-shelf mechanisms for each, the same across HTTP, RPC, and gRPC regardless of payload. An unbounded landscape of bespoke network-coordination puzzles reduces to one classified exchange unit, a five-item checklist with a known fix per item, and a one-step branch on interaction type that says which items are even live.

abstract_reasoning:
Request-response licenses a set of reasoning moves in network-services engineering, all flowing from its four structural commitments (role asymmetry, causal pairing, return path, one-shot scope) and from the fact that its hazards belong to the *pattern*, not to any application's semantics.

The signature *classification / boundary-drawing* move fixes which interaction pattern an exchange is, and from that determines which engineering problems the designer owns and which are discharged. Identifying an exchange as request-response — rather than publish-subscribe (a broadcast with no paired reply to correlate), streaming (a continuous flow, not a bounded one-shot pair), fire-and-forget (no response, hence no timeout to resolve), or event-driven reaction — selects the applicable checklist and simultaneously rules out the non-questions: a broadcast has nothing to correlate, a fire-and-forget emit has no missing-reply to interpret, a stream is not one-shot. The reasoner makes one classifying decision and inherits a closed, finite set of owned problems.

The *checklist-derivation / predictive* move reads the engineering requirements off the classification rather than re-deriving them from what the message carries. The moment an exchange is request-response, the pattern emits a fixed checklist — addressing the responder, correlating the reply to exactly one originating request, retry discipline, idempotency, error classification — each with a known mechanism-family (request identifiers or idempotency keys for correlation, timeout deadlines with exponential backoff for retry, structured error envelopes with layered status codes). Designing a new interaction is reading down that list and instantiating each slot, and the reasoner predicts that the same discipline applies across HTTP, RPC, and gRPC regardless of payload, because it derives from the shape and not from the application.

The central *diagnostic* move resolves *timeout ambiguity*. When no reply arrives, the reasoner does not read "the call didn't return" as a single condition but as a genuine four-way ambiguity at the initiator — the request was lost, the responder is slow, the response was lost, or the responder failed — that is indistinguishable from the initiator's vantage and that the design must resolve. Recognizing the exchange as request-response is exactly what surfaces this fork as something to handle up front, and it forces the connected inferences: how long to wait before retrying, and what a retry will do. A second discrimination rides alongside it — separating a *missing* response from a *negative* one (an error envelope) so that "no answer yet" and "the answer is no" are never conflated, the former routed to retry discipline and the latter to error handling.

The *retry-safety / interventionist* move reasons from the four-way ambiguity to a correctness condition on retries. Because the initiator cannot tell whether the responder already acted, a retried request must either be detected as a duplicate via a correlation or idempotency key, or be made to produce the same effect as a single request — otherwise a resend of a stateful operation double-charges or double-applies. The reasoner therefore predicts which operations are retry-safe as-is (idempotent reads) and which require an idempotency token before retry can be enabled, and prescribes the token precisely where the operation is stateful, with the predicted effect that the at-least-once delivery a retry produces becomes effectively-once. A related *error-classification* move partitions a non-success response into transport failure, application error, and semantic error — three causes that can all yield a "non-200" — so the reasoner routes each to its appropriate handling (retransmit, surface to the caller, reject as malformed) rather than treating every failed exchange alike.

knowledge_transfer:
Within the distributed-systems family request-response transfers *as mechanism*. The classification move (fix the exchange as request-response versus publish-subscribe, streaming, fire-and-forget, or event-driven, and inherit the applicable checklist while discharging the non-questions), the checklist derivation (addressing, correlation, retry discipline, idempotency, error classification, each with a known mechanism-family), the timeout-ambiguity diagnostic (the four-way request-lost / responder-slow / response-lost / responder-failed fork), and the retry-safety and error-classification interventions all carry intact across the protocols that share the substrate. They apply unchanged to HTTP, RPC, REST, gRPC, SOAP, JSON-RPC, GraphQL queries, database client/server protocols, and enterprise message queues, because — exactly as the Core Idea states — the discipline derives from the exchange *shape* and not from application semantics, so an idempotency key, a timeout-with-backoff, or a layered error envelope means the same thing whether the payload is a payment, a row read, or a file fetch. The transfer is mechanical here because each is the same substrate — addressed, causally-paired, one-shot exchange across an unreliable network — so the five-item checklist refers to the same machinery throughout.

Beyond the distributed-systems family the situation is the sharpest *shape-travels-mechanism-stays* case in this batch, and it is predominantly case (A) **metaphor** with a real case (B) residue. The structural *shape* — role asymmetry, causal pairing, a return path, one-shot scope — genuinely recurs across substrates: a legal motion answered by a ruling, a presenting complaint answered by an assessment-and-plan, a support ticket answered by a reply, a prayer or oracle consultation answered by a response, and the question-answer adjacency pairs of conversation analysis (Schegloff and Sacks). But what travels in these is only the shape; the *engineering discipline* that gives request-response its substance — correlation IDs, retry-with-idempotency, timeout backoff, error envelopes, circuit breakers — does *not* follow, because the unreliable-network hazards that motivate it are absent. A litigator filing a motion is not helped by reasoning about correlation IDs, and a theologian is not helped by exponential backoff; calling a court motion a "request" and a ruling a "response" is true and harmless but changes no practice, so importing the distributed-systems apparatus to these settings is metaphor and should be marked as such. The real case (B) residue is that the recurring shape *is* a genuine pattern, but it is carried by *other, more general* primes than request-response: the bare exchange structure belongs to `interaction_pattern` and, in the human-exchange setting, to `adjacency_pair` / `turn_taking` (the load-bearing prime for the one genuine cross-substrate transfer the source records — conversation analysis influencing dialogue-system and voice-assistant turn-taking design); and the portable primitives it rests on — `addressability`, pairing, and correlation — are already named elsewhere and apply equally to broadcasts and streams. So the honest cross-domain lesson is to carry those parents (interaction pattern / adjacency pair / addressability), not "request-response" with its engineering discipline attached. Strip the distributed-systems vocabulary and request-response is "one party asks; the other replies" — true, but it does not do the structural work a prime does, and the cross-substrate force it gestures at lives in the more general primitives — which is exactly why it is a domain-specific abstraction (best filed under `protocol`/`interaction_pattern`). The engineering content does not and should not travel beyond the distributed-systems family; only the shape does, and the shape belongs to its parents. (See *Structural Core vs. Domain Accent*.)


Requirements Churn

one_liner: A project pathology in which the specification changes faster than the execution organization can absorb it — a control-theoretic case where the reference signal outruns the controller's bandwidth, so no spec lives long enough for work to consolidate against it.

core_idea: Requirements churn is the project-management pathology in which the specification of what is being built changes repeatedly, substantially, or both, *faster than the execution organization can stably incorporate the changes into in-flight work*. Each new wave of requirement amendments lands while the prior wave is still propagating through design, build, test, and integration. The execution machinery is perpetually adapting to a moving target: artifacts in flight are reworked, scrapped, or shipped against stale specifications; no version of the spec lives long enough for work to complete and consolidate against it; throughput collapses not because the team is slow but because its velocity is consumed by re-touching work that the specification has already made obsolete. The structural commitment is that *the cadence of specification change exceeds the bandwidth of the execution loop* — a control-theory framing in which the reference signal varies faster than the controller can track it. This distinguishes churn from three commonly conflated phenomena: *iteration*, in which small, scoped change is the designed input to a controlled feedback loop; *late binding*, in which decisions are deliberately deferred to gather information; and *underspecification*, in which the spec is incomplete but stable. Churn is specifically the case where the change rate is the active bottleneck, not execution capacity. The measurement move is direct: track the rate of specification amendment against the rate of work completion; when the former exceeds the latter, the team is not the constraint. The corrective interventions address the inflow, not the execution: change-control governance that slows the rate at which amendments enter the work queue, scope freezes that hold a specification stable for a defined period, sprint commitment ceremonies that price the cost of mid-sprint scope changes, sign-off gates, and contract architectures that price change-orders into project economics in ways that make the change cadence visible to the stakeholder driving it. The pattern recurs across software delivery, construction megaprojects, regulatory-implementation programs, and research grants — wherever a complex artifact is produced under stakeholder-defined requirements and the stakeholders' priorities, compliance environment, or competitive context can change faster than the executing organization can absorb.

scope_of_application:
Requirements churn lives across the sectors of organizational delivery where a complex artifact is built under stakeholder-defined requirements; these are sectors of one substrate, not structurally distinct ones, and the cadence comparison and inflow-control toolkit port across them intact, while the substrate-neutral control-bandwidth-shortfall pattern (the reference signal outrunning a bandwidth-limited controller) is the side-captured emergent that carries the cross-substrate weight, not this name.

- **Software delivery** — sprint plans turning over weekly as stakeholders reprioritise, each story touched multiple times before it ships.
- **Construction megaprojects** — owner change-orders outrunning the contractor's integration capacity, producing standby costs, rework, and disputed claims.
- **Policy implementation** — a rule amended faster than affected entities can reach a stable compliance posture, cycling them through partial implementations.
- **Research programs** — funder priorities, deliverables, and reporting requirements shifting faster than the team can resettle its design.
- **Defense acquisition, drug development, curriculum reform, and M&A integration** — further delivery sectors where stakeholder requirements can change faster than the executing organization absorbs them.

structural_signature:
**Sig role-phrases:**

- **the specification stream** — the reference signal delivering amendments to the in-flight work at some cadence (additions, removals, substitutions)
- **the execution loop** — the design→build→test→integration machinery that processes work to consolidation at some bandwidth
- **the cadence-bandwidth gap** — the load-bearing condition: the amendment rate exceeds the rate at which work consolidates against a stable spec, so the reference signal outruns the controller
- **the consolidation failure** — no spec version living long enough for any work item to complete against it before the next change arrives
- **the rework amplification** — each amendment wave rippling back into in-flight artifacts before the prior wave has finished propagating, multiplying touches per item
- **the throughput collapse** — output collapsing even though per-unit-of-stable-work capacity is unchanged (the team is not the bottleneck)
- **the inflow corrective** — change-control governance, scope freezes, sprint-commitment pricing, sign-off gates, and change-order economics that slow the amendment rate to within the loop's bandwidth, making the cadence visible to whoever drives it

what_it_is_not:
- **Not the team being slow.** Every visible symptom — missed milestones, rework on rework, falling velocity, burnout — indicts execution, but the binding constraint is the change cadence, not per-unit speed. When amendments enter the queue faster than work consolidates against a stable spec, the inflow is the bottleneck *by definition*; a team doing immense work while nothing ships is the fingerprint of a reference signal outrunning the loop, not of a slow team.
- **Not iteration or late binding.** Iteration is small, scoped change that is the *designed input* to a controlled feedback loop; late binding is deliberate deferral to gather information. Both are healthy and want *more* agility. Churn is change arriving *faster than the loop can absorb* and wants *less* change inflow — routing a change-control fix at iteration would suppress exactly the agility that was working.
- **Not scope creep.** Scope creep is monotonic *expansion*; churn nets to zero scope as often as not, because it counts removals and substitutions alongside additions. A scope-control lever aimed at expansion misses churn, whose problem is the *rate* of change rather than its direction.
- **Not underspecification.** Underspecification is an incomplete but *stable* spec, against which work can at least complete and consolidate. Churn is the opposite: the spec may be complete at every instant but never holds still long enough for any work item to finish against it. One is a feasibility-of-completion problem from missing detail; the other is a stability-over-time problem from change rate.
- **Not a bottleneck.** A bottleneck is a single throughput-limiting stage; churn is a system-wide statement about two *competing cadences* — amendment inflow versus work-completion throughput. It is not localizable to one station, and relieving any single stage does not address a reference signal moving faster than the whole loop can track.
- **Not a delayed-feedback oscillation.** Feedback-loop-with-delay produces oscillation from a *delayed signal inside* the controller; churn is the *reference signal's rate* exceeding the controller's tracking bandwidth. The failure is a setpoint moving too fast to follow, not a lagged correction overshooting — so the control-theoretic diagnosis, and the fix, differ.

clarity:
Naming requirements churn pries apart three states that a project lead otherwise lumps together as "the spec keeps changing": *iteration* (small, scoped change that is the *designed input* to a controlled feedback loop), *late binding* (decisions deliberately deferred to gather information), and *churn* proper (change arriving faster than the execution loop can absorb). The distinction is load-bearing because the three call for opposite responses. Iteration and late binding are healthy and want *more* of the agility that produced them; churn wants *less* change inflow, or slower. So the vocabulary lets a lead say "we are in churn, not iteration" and route the fix to the inflow — change-control governance, scope freezes, change-order pricing — rather than to execution, where adding engineers or pushing velocity only buys more rework. Crucially, the concept relocates blame: the diagnosis says the team is *not* the bottleneck even though every visible symptom (missed milestones, rework, burnout, falling velocity) points at it.

What makes that relocation defensible rather than a convenient excuse is the measurement the label crystallizes: track the *rate of specification amendment* against the *rate of work completion*. When amendments enter the queue faster than items consolidate against a stable spec, the change cadence is the active constraint by definition, regardless of how hard the team is working. That single comparison is the sharp question the concept hands a practitioner, and it also fixes the boundaries against neighbors that share symptoms: churn is *not* scope creep (which is monotonic *expansion* — churn nets to zero scope as often as not, since it counts substitutions and removals too), *not* underspecification (an incomplete but *stable* spec, against which work can at least complete), and *not* a bottleneck (a single limiting stage, where churn is a system-wide statement about two competing cadences). Holding "the spec is changing too fast to track" distinct from "the team is too slow" is what stops an organization from throwing execution capacity at an inflow problem.

manages_complexity:
A delivery lead watching a project deteriorate confronts a pile of symptoms that all seem to point in different directions and all seem to indict the team: missed milestones, rework piling on rework, test suites written against specs that no longer exist, velocity falling quarter over quarter, burnout, declining quality, stakeholder thrash. The reflex is to treat each symptom as its own problem with its own fix — add engineers, tighten estimates, push harder, run a quality initiative — and that scattershot triage is the sprawl. Requirements churn collapses it to a single regularity expressed as a relation between two cadences: *the rate at which the specification changes versus the rate at which the execution loop can absorb change*. The analyst stops cataloguing symptoms and instead tracks one comparison — amendment inflow against work-completion throughput — reading the project's true state off which cadence is faster rather than off how hard the team appears to be struggling.

The compression works because it identifies the right variable and makes it measurable. The naive view treats execution capacity as the thing to optimize and reads every symptom as evidence the team is slow; requirements churn reframes the situation in control-theoretic terms — the reference signal is varying faster than the controller can track it — so the binding constraint is the change cadence, not the team's per-unit speed. The measurement is direct and decisive: when amendments enter the work queue faster than items consolidate against a stable spec, the change rate is the active bottleneck *by definition*, and the qualitative outcome follows — throughput will collapse, work in flight will be reworked or shipped stale, and no version of the spec will live long enough to complete against, regardless of how much execution capacity is added. One cadence comparison substitutes for an open-ended audit of every visible failure.

The relation also installs the branch structure that the shared symptoms hide, because the concept's first job is to pry apart states that look identical from the outside. The primary fork is *change-inflow problem versus execution problem*, and it routes the fix to opposite places: an inflow problem calls for change-control governance, scope freezes, sprint-commitment pricing, and change-order economics that make the cadence visible to whoever is driving it; an execution problem would call for capacity — and throwing capacity at an inflow problem only buys more rework. A second set of distinctions keeps the analyst from misrouting at the fork: churn is *not* iteration (small scoped change that is the designed input to a controlled loop and wants *more* agility), *not* late binding (deliberate deferral to gather information, also healthy), *not* scope creep (monotonic expansion, where churn nets to zero scope as often as not because it counts removals and substitutions), and *not* underspecification (an incomplete but *stable* spec, against which work can at least complete). Naming the case where change *rate* is the constraint is what lets a lead say "we are in churn, not iteration" and act on it. A sprawling, team-blaming pile of project pathologies thereby reduces to one cadence comparison feeding a clean inflow-versus-execution branch that tells the organization to slow the change stream rather than push the team.

abstract_reasoning:
Requirements churn licenses reasoning moves that all rest on one cadence comparison — specification-amendment rate versus work-completion rate — read through the control-theoretic framing that the reference signal is varying faster than the controller can track.

*Diagnostic* (infer an inflow constraint from symptoms that all point at the team): the central move is counterintuitive — every visible symptom (missed milestones, rework on rework, falling velocity, burnout, test suites written against vanished specs) indicts execution, yet the analyst infers *from* their co-occurrence *to* an inflow problem by running the cadence comparison. The decisive measurement is direct: track the rate at which amendments enter the work queue against the rate at which items consolidate against a stable spec; when the former exceeds the latter, the change cadence is the active bottleneck *by definition*, regardless of how hard the team is working. The signature that confirms churn rather than slowness is consolidation failure — *no version of the spec lives long enough for work to complete against it*, so artifacts are perpetually reworked or shipped stale. The analyst reasons that a team doing immense work while nothing ships is the fingerprint of a reference signal moving faster than the execution loop's bandwidth, not of low per-unit speed.

*Interventionist* (name the change and predict its effect, including the backfire): because the binding constraint is the change cadence, the predicted-effective interventions all act on the *inflow*, not on execution — change-control governance that slows the rate at which amendments enter the queue, scope freezes that hold a spec stable for a defined period, sprint-commitment ceremonies that price mid-sprint changes, sign-off gates, and change-order economics that make the cadence visible to whoever is driving it. Each is predicted to restore throughput by bringing the amendment rate back under the execution loop's bandwidth so work can consolidate. The frame makes a strong negative prediction that overrides the reflex: adding engineers or pushing velocity is predicted to buy only *more rework*, because raising execution capacity does not slow the reference signal — throwing capacity at an inflow problem leaves the cadence gap intact. The interventionist reasoning is therefore to measure which cadence is faster and, if it is the inflow, to widen the gap from the inflow side, pricing change so the stakeholder generating it confronts its cost.

*Boundary-drawing* (prying apart states that look identical from outside): the concept's first job is to distinguish churn from three healthy or different neighbors, because they share symptoms but demand opposite responses. *Iteration* is small, scoped change that is the *designed input* to a controlled feedback loop and wants *more* agility; *late binding* is deliberate deferral to gather information, also healthy; both are the wrong target for change-control. *Scope creep* is monotonic *expansion*, whereas churn nets to zero scope as often as not because it counts removals and substitutions too — so a scope-control lever aimed at expansion misses churn. *Underspecification* is an incomplete but *stable* spec, against which work can at least complete, so it is an execution-feasible state churn is not. And churn is *not* a bottleneck (a single limiting stage) but a system-wide statement about two competing cadences. The analyst draws the line by asking whether change *rate* is the constraint; only then does "we are in churn, not iteration" hold, and the regime in which the diagnosis applies is precisely where amendment cadence exceeds execution bandwidth.

*Predictive / order-of-events*: the control framing predicts the failure trajectory — each amendment wave ripples back into in-flight artifacts before the prior wave has finished propagating through design, build, test, and integration, multiplying touches per item, so throughput collapses even though per-unit-of-stable-work capacity is unchanged. Reasoning forward from a measured cadence gap, the analyst predicts that work in flight will be reworked or shipped stale, that no spec version will reach consolidation, and that velocity will keep falling until the inflow is slowed — and predicts that the gap will *not* close by itself, since nothing in the execution loop throttles the reference signal.

knowledge_transfer:
Within project and delivery practice requirements churn transfers *as mechanism*, because the cadence comparison (amendment rate versus work-completion rate) and the control-theoretic diagnosis (reference signal outrunning controller bandwidth) are stated independently of the artifact being built. The diagnosis, the measurement, and the corrective vocabulary — change-control governance, scope freezes, sprint-commitment ceremonies, sign-off gates, and change-order economics that make the cadence visible to whoever drives it — carry intact across **software delivery** (sprint plans turning over weekly), **construction megaprojects** (owner change-orders outrunning the contractor's integration capacity, producing standby costs and disputed claims), **policy implementation** (a rule amended faster than affected entities can reach a stable compliance posture), and **research programs** (funder priorities shifting faster than the team can resettle its design), and on into defense acquisition, drug development, curriculum reform, and M&A integration. The seed is precise that these are *sectors of one substrate* — organizational delivery of a complex artifact under stakeholder-defined requirements — not structurally distinct substrates, so the breadth is many delivery flavours of one structure.

Beyond delivery the honest reading is **shared abstract mechanism** (case B), and requirements churn is an unusually clean instance because its core is a recognized control-theory pattern that genuinely recurs as co-instances on substrates that are not organizational at all. Stripped of project-management vocabulary, the mechanic is *the reference signal varies faster than the controller's tracking bandwidth, so the controlled variable cannot follow it* — setpoint tracking under a bandwidth-limited controller — and that same pattern reappears, as mechanism rather than metaphor, in cognition (attention switching faster than working memory can consolidate), biology (thermoregulation when ambient temperature swings faster than the homeostatic loop), public policy (voter preferences shifting faster than the electoral cycle can register them), markets (order flow churning faster than price discovery's settling time), pedagogy (curriculum redesign faster than teacher development can absorb), and machine learning (target-distribution drift faster than the retraining cadence). These are real structural recurrences of a substrate-independent pattern — *control-bandwidth shortfall* / *reference-cadence exceeds tracking bandwidth* — which is being side-captured as an emergent candidate in its own right. So the cross-domain lesson should carry *that* pattern, which transfers literally wherever a tracker must follow a reference that can move faster than its bandwidth; "requirements churn," as named, is the project-management-craft expression, and its home-bound cargo — change-control boards, scope freezes, sprint commitments, sign-off gates, change-order contract architecture — does not travel. Two boundaries are worth re-marking because they are easy to over-read: churn is *not* `scope_creep` (monotonic expansion; churn nets to zero scope as often as not, counting removals and substitutions), and it is *not* `feedback_loop_with_delay` (oscillation from a *delayed* signal in the loop, whereas churn is the reference signal's *rate* exceeding the loop's bandwidth) — importing either neighbor's lesson here would misfire. The cleanest disposition is the seed's: keep requirements churn as the delivery-management instance and let the control-bandwidth-shortfall pattern carry the cross-substrate weight.