• conforms_to::[[Pattern Form Contract]]
• in_domain::[[Deep Context Architecture]]
• authored_by::[[Deep Context Community]]
• has_lifecycle::[[Seed Stage]]
• has_curation::[[Working Draft]]

Convergent Motivation as Load-Bearing Signal

Heart

When four or more independent motivations converge on one architectural solution, the convergence is evidence the solution is structural rather than contingent. Count independence, not motivations -- a solution justified by four reasons that all share a single root is one reason in disguise.

Problem

A proposal to commit structure -- a new Decision, a new Contract requirement, a new pipeline capability -- usually arrives with motivation. The default review move is to weigh that motivation: a strong reason carries the proposal forward; a weak reason warrants pushback. But a strong single motivation can be wrong, can be deprioritized, or can describe a local optimization the proposer over-generalized. A proposal whose architectural commitment rests on one motivation is fragile -- if the motivation shifts, the commitment is left without justification, and its maintenance cost falls on contributors who did not share the original reason.

The graph's deferral discipline compounds the difficulty. The Adopt Minimum-Viable-Architecture Stance Decision asks contributors to defer capabilities until use surfaces their need. But "use surfaces the need" is not a binary signal. A single user request, a single Decision, a single Observation each cross some threshold of "surfacing" without clearly crossing the threshold of "warrants structural commitment." Without an explicit criterion, the line gets drawn arbitrarily, and the project alternates between under-committing (deferring capabilities the practice actually needs) and over-committing (building for one motivation that turned out to have been local).

Forces

• Single-motivation proposals can be right. The first contributor to surface a need is often the one who sees most clearly. Refusing structural commitment until four motivations accumulate is its own failure mode -- capabilities the practice needs get held back by an artificial threshold. The Pattern is not a rule against single-motivation commitments; it is a discipline against treating single motivations as sufficient evidence by default.
• Multiple motivations can collapse together. Four reasons that all trace to a single root are one reason. A proposer may list several apparent justifications and still be defending a single concern in different vocabularies. The Pattern's load-bearing claim depends on independence, not count -- and independence is harder to assess than count, which is why the diagnostic test matters more than the headcount.
• Convergence is observed, not engineered. A proposer who notices that four sessions arrived independently at the same need has observed convergence. A proposer who manufactures four motivations to clear the threshold has engineered it. The Pattern depends on convergence being a finding rather than a construction; otherwise it becomes a procedural hurdle that proposals route around rather than a discipline that produces durable structural commitment.
• Deferral has real cost. A capability the practice needs but does not have produces friction, lost contributions, and worked-around-by-convention surface that itself accumulates cost. The "wait for convergence" discipline must not become a permanent block on capabilities whose costs of deferral exceed the costs of premature commitment.

Solution

Apply the convergence count as a discipline at the moment of structural commitment, not at the moment of proposal. A proposer surfacing a need does not need to wait for four motivations before naming the need; the discipline applies when the project considers committing structure in response.

When considering structural commitment:

1. Enumerate the motivations. List the separate concerns the commitment would address. Each should be sourceable to a specific node, contributor request, or observed pattern, not to abstract reasoning about what might matter.
2. Test independence. For each motivation, ask whether the project would face this concern even if the others were withdrawn. Motivations that fail the independence test collapse together -- count them as one.
3. Apply the diagnostic. If removing any single motivation would cause reconsideration of the commitment, the motivations are not fully independent; the convergence is local rather than structural. Either find more independent motivations or treat the commitment as Provisional rather than Firm.
4. Name the convergence in the commitment record. When a Decision is made or a Contract requirement added, the Decision's Why or the Requirement's grounding cites the independent motivations explicitly. "Four independent motivations from separate sessions" is a stronger Why than "several reasons" -- naming the independence makes the convergence claim auditable.
5. When convergence is below threshold and deferral cost is rising, surface the gap rather than committing structure. Name the gap in the Decision Log or the Aspirations layer; the gap itself becomes information that may attract further independent motivations, at which point the convergence threshold can be re-evaluated.

Consequences

• Architectural commitments are more robust to motivation shifts. The project's architectural surface accumulates more slowly but more durably; no single motivation's withdrawal collapses a commitment built on convergence.
• Provisional and Firm Commitment become operationally meaningful. The convergence test gives the has_commitment:: predicate's two values practical content rather than only nominal scoping.
• Single-motivation proposals are held in productive tension rather than refused. The proposal is named, the gap is named, and the project waits for either further independent motivations or for the deferral cost to surface a stronger reason. The proposer's contribution is captured even when the architecture is not yet committed.
• The discipline can be defended structurally. When a contributor pushes back on deferral with "but this is the obviously correct architecture," the response is the convergence test rather than counter-argument from preference. The conversation moves from preference to evidence.
• The discipline can also be wrong. When applying the Pattern would block a load-bearing capability whose costs of deferral exceed the costs of premature commitment, the project may commit structure with Provisional Commitment and an explicit revisit condition that re-runs the convergence test once usage data accumulates.

Relations

• grounded_in::[[Adopt Minimum-Viable-Architecture Stance]]

  • The MVA stance asks "what is the minimum architecture the practice can run on, and what gets deferred?" This Pattern provides the operational test for when a deferred capability has accumulated enough independent motivations to return to scope. The Pattern is the discipline the Decision's Revisit Conditions implicitly invoke; the Decision is the standing commitment the discipline serves.

• grounded_in::[[Founding Vocabularies Constrain Later Participants]]

  • The Observation names the cost of premature architectural commitment at the vocabulary layer: founding choices calcify and constrain later participants who arrive with different concerns. The convergence test is one mechanism for slowing that calcification -- structural commitments wait for evidence that the concern is structural rather than founding-time-specific, which gives later participants room to surface concerns the founder did not see.

• composes_with::[[Treat Objection as Structural Contribution]]

  • Both Patterns belong to the curation-discipline cluster. Treat Objection captures dissent as durable graph content; this Pattern captures convergence as the evidence threshold for structural commitment. Together they navigate the tension between premature commitment (which Treat Objection resists) and unprincipled deferral (which this Pattern guards against).