Mutual Dependency Stabilization

Stabilize a necessary interdependency so neither side’s failure, exit, overload, or opportunism destabilizes the other.

Version

v1 · 2026-08-24 · History

Solution archetype #

659

Problem family

Fragility, Failure & Continuity Risk

Problem subfamily

Fault Containment & Bounded Service Loss

Essence

Mutual Dependency Stabilization protects a necessary reciprocal dependency from becoming a point of collapse. It applies when two or more parties, systems, or components genuinely rely on one another, but that reliance is fragile: a shortage, outage, exit, overload, or opportunistic move on one side can quickly destabilize the other.

The archetype does not merely recommend cooperation. It asks what each side depends on, where the dependency becomes critical, how failure would propagate, and what stabilizers should exist before stress arrives. Typical stabilizers include buffers, fallback paths, shared monitoring, risk-sharing rules, credible support commitments, escalation paths, and repair protocols.

Compression statement

When parties, systems, or components must depend on each other but the dependency is fragile, add buffers, fallback paths, credible commitments, shared monitoring, risk-sharing rules, and repair protocols so reciprocal viability survives stress.

Canonical formula: Mutual dependency + fragility diagnosis + stabilizers + fallback + shared repair → reciprocal continuity under stress.

When This Archetype Applies

Partial catalog groundingSome structural conditions are represented by existing abstractions, but no sufficient condition set is fully represented.

Diagnostic problem

A necessary reciprocal dependency is operationally, socially, ecologically, or strategically fragile: one side’s shock, nonperformance, withdrawal, overload, or opportunism can quickly damage the other side, yet the relation cannot simply be severed without losing important capability or value.

What this problem means

A mutually dependent relation can be useful in normal conditions but brittle under stress. One side may appear healthy while silently relying on the other side’s hidden slack, informal favors, unmeasured standby capacity, or willingness to absorb shocks. When disruption arrives, the relation fails as a whole because the dependency was never mapped, funded, monitored, or given a fallback path.

The structural tension is that coupling creates value and vulnerability at the same time. The parties cannot simply pretend to be independent, but they also cannot let shared fate become unmanaged fragility.

Applicability expression5 distinct conditions

Reciprocal material relianceandCascade-prone dependencyandAsymmetric burden transferandContinuity amid dependenceandWeak fallback arrangements

Algebraic1∧2∧3∧4∧5

3=3₁?3₂

3₁=∅

3₂=a

′ context guard? connective not recorded∅ no catalog witness yet

groundedpartly groundedopen

5 conditions, all required.

5Required in every casenumbered 1–5

These hold no matter which pattern applies.

1

Reciprocal material reliance · open

Each side materially relies on the other for continuity, capacity, legitimacy, access, information, protection, or maintenance. more

and — also required

2

Cascade-prone dependency · grounded

A valuable dependency is fragile enough that ordinary disruption can cascade across the relation. more

domainHyrum's Law— With enough users of an interface, every observable behaviour will come to be depended upon by someone regardless of the formal contract, so the cost of changing an observable is set by its dependent count, not its documented status.

AND both parts required

context guardThe de facto interface dependency is valuable enough to preserve.

suppliesThe dependency has sufficient value that preserving it is warranted.

How this was matched — 5 requirements, all needed

valuable fragile dependency can transmit ordinary disruption

All of

• roleTwo or more parties or components are connected by a dependency relation.
• modalityThe dependency has sufficient value that preserving it is warranted.
• polarityThe dependency is fragile under ordinary disruption.
• causalityDisruption at one part of the dependency can propagate harm across the relation.
• modalityCascade across the relation is possible rather than asserted as inevitable.

and — also required

3

Asymmetric burden transfer · 2 cases · 1 matched

Implicit¹ or asymmetric² obligations let one party transfer risk, delay, cost, or recovery burden to the other. more

This predicate enumerates 2 cases · 1 matched

• 1

  implicit obligations enable one-party burden transfer

  no catalog match yet

  Nothing in the catalog establishes this case yet

  Case 1 of 2 — what it requires — 4 shared + 4 branches

  All of

  • roleTwo parties are connected by obligations and one can impose a burden on the other.
  • polarityThe obligations are implicit.
  • modalityOne party is able to shift the burden to the other.
  • causalityThe implicit obligation structure enables the burden transfer.

  …and any one of

  • branchThe shifted burden is risk.
  • branchThe shifted burden is cost.
  • branchThe shifted burden is delay.
  • branchThe shifted burden is recovery burden.
?how these combine is not recorded
• 2

  asymmetric obligations enable one-party burden transfer

  matched to the catalog

  Established by

  domainPostel's Law (Robustness Principle)— Postel's protocol-design maxim — be conservative in what you send, liberal in what you accept — which keeps a multi-vendor system interoperable by having every implementation produce tightly to spec while its acceptance window absorbs the realistic scatter of others.

  Case 2 of 2 — what it requires — 4 shared + 4 branches

  All of

  • roleTwo parties are connected by obligations and one can impose a burden on the other.
  • polarityThe obligations are asymmetric.
  • modalityOne party is able to shift the burden to the other.
  • causalityThe asymmetric obligation structure enables the burden transfer.

  …and any one of

  • branchThe shifted burden is risk.
  • branchThe shifted burden is cost.
  • branchThe shifted burden is delay.
  • branchThe shifted burden is recovery burden.

Within a case the abstractions are alternatives — any one establishes it. How the 2 cases combine with each other is not recorded in the source; the predicate reads as an alternation, but polarity can flip that reading, so it is marked ? above rather than guessed.

and — also required

4

Continuity amid dependence · grounded

The parties need credible continuity expectations while dependence and uncertainty remain unavoidable. more

domainFolk Theorem (Repeated Games)— Show that in a sufficiently long, patiently discounted repeated game, almost any mutually acceptable outcome can be held as an equilibrium by credible intertemporal punishment — so repetition both explains cooperation and destroys predictive determinacy.

AND both parts required

context guardThe repeated relation has an indefinite horizon whose termination remains uncertain.

suppliesThe parties cannot fully eliminate uncertainty about the relation.

How this was matched — 4 requirements, all needed

interdependent parties require credible continuity expectations under irreducible uncertainty

All of

• roleMultiple parties remain connected by a dependency whose continuity matters.
• modalityThe parties require credible expectations that the dependent relation will continue.
• polarityThe parties cannot fully eliminate uncertainty about the relation.
• polarityThe parties cannot fully eliminate their dependence.

and — also required

5

Weak fallback arrangements · 2 cases · 0 matched

Fallbacks are informal, untested, under-resourced, or concentrated² in tacit knowledge. more

Coverage

2 of 5 conditions grounded · 1 partly grounded · 2 open.

Read the methodology · Download the trigger-logic data

When to Use This Archetype

Use this archetype when the dependency is both valuable and dangerous. The relation should be worth preserving, but not safe to leave informal. It is especially useful when each side can name a function, resource, capacity, signal, or commitment it needs from the other and when failure would propagate faster than ad hoc improvisation can handle.

Do not use it simply because two parties cooperate. If the main problem is that the relationship lacks mutual benefit, use Symbiotic Alignment. If the main problem is technical incompatibility, use Interoperability Standardization. If the safest answer is to exit, decouple, or protect a weaker party from coercive dependence, stabilization may be the wrong intervention.

Structural Problem

A mutually dependent relation can be useful in normal conditions but brittle under stress. One side may appear healthy while silently relying on the other side’s hidden slack, informal favors, unmeasured standby capacity, or willingness to absorb shocks. When disruption arrives, the relation fails as a whole because the dependency was never mapped, funded, monitored, or given a fallback path.

The structural tension is that coupling creates value and vulnerability at the same time. The parties cannot simply pretend to be independent, but they also cannot let shared fate become unmanaged fragility.

Intervention Logic

The intervention begins by exposing reciprocal dependence. What does each side need from the other? How often? Under what conditions? What breaks first? Then it maps propagation: how does stress cross the boundary, and where are the critical thresholds? Only after that should the designer choose stabilizers.

A stable design usually combines several moves. Buffers absorb temporary stress. Fallback paths preserve continuity when the primary relation falters. Shared monitoring reduces surprise. Risk-sharing rules prevent one side from carrying all the cost. Commitments make support credible. Escalation and repair protocols turn crisis response from improvisation into a rehearsed pathway. Autonomy guardrails prevent stabilization from becoming lock-in.

Key Components

Mutual Dependency Stabilization protects a valuable reciprocal relation from becoming a point of collapse by first making the dependency visible and then layering stabilizers around it. Diagnosis begins with the Reciprocal Dependency Map, which names what each side actually requires from the other — function, resource, capacity, signal, or commitment — in both directions rather than only the conventional vendor-to-client direction. The Critical Dependency Threshold marks where ordinary degradation begins to endanger the relation, so escalation triggers can be negotiated before stress arrives rather than during it. The Failure Propagation Map traces how shock, withdrawal, or opportunism on one side would cross the boundary and ripple into the other, including delayed and second-order effects. Together these three diagnostic components establish what is at risk and how failure travels, which is the precondition for choosing useful stabilizers rather than generic risk controls.

Four operational stabilizers absorb or reroute stress at the dependency interface. The Stabilizing Buffer adds slack, reserves, or redundancy so temporary disruption does not immediately become relational failure, while the Fallback or Substitution Path preserves continuity when the primary dependency cannot be satisfied without silently dissolving the relationship. The Shared Monitoring Signal gives both sides a common view of capacity, reliability, and early degradation, reducing surprise and blame when one side can see stress earlier than the other. The Risk-Sharing Rule allocates foreseeable disruption and recovery costs so one side is not quietly carrying all the dependency risk. The Commitment and Service Guarantee then converts goodwill into something planable: a credible expectation of minimum support, response time, or non-abandonment under stress, whether enforced legally, operationally, or reputationally.

The final two components convert stabilization from a static agreement into a live, ethical practice. The Escalation and Repair Protocol defines how the parties intervene when the dependency starts to fail — who is notified, what support activates, how repair is verified — so crisis response becomes a rehearsed pathway instead of negotiated improvisation. The Autonomy and Exit Guardrail prevents stabilization itself from becoming coercive lock-in by preserving enough independence, bargaining power, and graceful exit capacity that a weaker party is not trapped in an exploitative relation. The set holds together because each component answers a different failure mode: missing diagnosis produces blind dependence, missing buffers and fallbacks produce cascading collapse, missing monitoring and risk-sharing produce hidden cost transfer, missing commitments produce unfundable promises, and missing repair or exit produces brittle or captive relations.

Component	Description
Reciprocal Dependency Map ↗	Shows what each party, subsystem, or component depends on the other to provide, absorb, signal, maintain, or protect. This is the diagnostic core of the archetype. It distinguishes mutual dependency stabilization from ordinary risk management by making both directions of dependence explicit.
Critical Dependency Threshold ↗	Defines the point at which degradation in one side begins to endanger the other side or the shared relation. Thresholds help prevent vague concern from becoming either complacency or overreaction. They also make escalation and support triggers negotiable before stress arrives.
Failure Propagation Map ↗	Traces how overload, withdrawal, opportunism, nonperformance, or shock in one node would propagate into the other. The map should include delayed effects and second-order consequences, not only immediate operational breakpoints.
Stabilizing Buffer ↗	Adds slack, reserves, time, redundancy, or capacity at the dependency interface so temporary stress does not immediately become relational failure. Buffers are not the archetype itself. They are a common stabilizer chosen after the dependency and failure pathway are understood.
Fallback or Substitution Path ↗	Specifies what either side can temporarily use, invoke, or switch to when the normal dependency cannot be satisfied. A fallback path keeps dependency from becoming captivity. It should preserve continuity without silently dissolving the relationship.
Shared Monitoring Signal ↗	Gives the interdependent parties a common view of capacity, reliability, stress, obligations, and early degradation. Shared monitoring reduces surprise and blame. It is especially important when one side can see stress earlier than the other.
Risk-Sharing Rule ↗	Allocates foreseeable costs, reserves, disruptions, or recovery burdens so one side is not left carrying all dependency risk. The rule may use proportional sharing, role-based sharing, insurance-like pooling, or explicit compensation for standby capacity.
Commitment and Service Guarantee ↗	Creates credible expectations about minimum support, response time, continuity, or non-abandonment under stress. The guarantee need not be legal; it can be operational, relational, technical, or reputational. What matters is that future support becomes credible enough to plan around.
Escalation and Repair Protocol ↗	Defines how the parties intervene when the dependency starts to fail, including who is notified, what support is activated, and how repair is verified. Without a repair path, stabilization degrades into a static agreement that works only in normal conditions.
Autonomy and Exit Guardrail ↗	Preserves enough independence, bargaining power, and graceful exit capacity that stabilization does not become coercive lock-in. A stabilized dependency should reduce fragility, not trap weaker parties in exploitative or unsafe relationships.

Common Mechanisms

10 catalogued mechanisms: 9 documented across 6 implementation forms; 1 awaits an authored page and reviewed form classification.

The grouping reflects forms represented among the mechanisms currently documented for this archetype; an absent form is not necessarily an impossible implementation.

Experiment, Test & Rehearsal · 1 mechanism

• Cross-Training and Role Shadowing — Builds partial substitutability by having each side learn enough of the other's critical work to understand, assist, or temporarily cover it when the usual person is gone.

Monitoring, Sensing & Alerting · 1 mechanism

• Shared Monitoring Dashboard — Gives interdependent parties one common, live view of capacity, reliability, queues, and obligations, so degradation is seen early by everyone who depends on it.

Organization, Role & Governance · 2 mechanisms

• Fallback Supply or Service Contract — Keeps a pre-arranged, independent secondary supplier on standby so one party's failure does not immediately cascade into the other — and no one becomes captive to a single source.
• Shared Reserve Pool — Maintains a jointly funded stock of money, materiel, or capacity that either side can draw down when its dependency is stressed, then replenish.

Protocol, Workflow & Routine · 1 mechanism

• Escalation Ladder and Repair Review — Turns dependency-stress response into a rehearsed ladder of named owners, time limits, and a verified repair review — so a crisis is worked, not improvised.

Representation, Specification & Plan · 1 mechanism

• Joint Contingency Plan — Predefines, for each dependency-stress scenario, the actions, authorities, communication paths, and fallback modes both sides will use — written in calm, before the crisis.

Rule, Policy & Commitment · 3 mechanisms

• Bilateral Service-Level Guarantee — Binds both parties to measured minimum-service commitments in each direction — with named thresholds and reciprocal penalties — so neither side can quietly let the other down.
• Co-Insurance or Risk-Pooling Arrangement — Spreads the cost of a dependency disruption across the parties who benefit from the stable relation, so no single side is left carrying the whole loss.
• Reciprocal Support Pact — A standing relational promise that each side will step in when the other is vulnerable — made credible through trust and reciprocity rather than metered penalties.

Not Yet Form-Classified · 1 mechanism

• Mutual Aid Agreement — An agreement that grants participating parties contingent access to each other's resources under defined overload or emergency conditions.

Parameter / Tuning Dimensions

• Dependency Criticality (dependency_criticality): How severe is the consequence if one side cannot provide the function, resource, access, signal, or support the other relies on?
• Coupling Tightness (coupling_tightness): Should the parties remain tightly coupled for performance, or loosen coupling to reduce propagation of failure?
• Buffer Depth (buffer_depth): How much slack, inventory, time, redundancy, or standby capacity is worth carrying to prevent cascading instability?
• Fallback Independence (fallback_independence): How independent must fallback paths be so they are not impaired by the same shock that stresses the primary dependency?
• Risk-Share Ratio (risk_share_ratio): How should prevention, standby, disruption, and recovery costs be divided among parties that benefit differently from the stable relation?
• Monitoring Cadence (monitoring_cadence): How often should dependency health be checked, and which thresholds require immediate escalation rather than ordinary review?
• Exit Reversibility (exit_reversibility): Can either party reduce or end the dependency without catastrophic harm, and what transition path preserves continuity?

These parameters prevent over- and under-stabilization. Too little stabilization leaves the relation brittle; too much can create bureaucracy, moral hazard, or coercive dependence.

Invariants to Preserve

• Reciprocal Continuity (reciprocal_continuity): The relation should continue through ordinary disruption without one side’s stress immediately disabling the other.
• Non-Cascading Failure (non_cascading_failure): Failure in one node should be slowed, absorbed, isolated, or rerouted before it becomes a wider relational collapse.
• Visible Dependency Health (visible_dependency_health): Critical signals about capacity, stress, reliability, obligations, and degradation must be observable by those who depend on them.
• Fair Risk Distribution (fair_risk_distribution): The costs of stabilizing the dependency should not be invisibly imposed on the weaker, less visible, or more replaceable participant.
• Preserved Autonomy (preserved_autonomy): Stabilization should not eliminate exit, bargaining power, fallback capacity, or independent safety.

The most important invariant is that stabilization must preserve legitimate reciprocal continuity without erasing autonomy. A dependency can be made safer without making either party captive.

Target Outcomes

• Lower Cascade Risk (lower_cascade_risk): Disruptions in one side are less likely to propagate quickly or unexpectedly into the other.
• Higher Relational Reliability (higher_relational_reliability): Each party can plan around the dependency because minimum support, visibility, and fallback expectations are credible.
• Faster Repair After Stress (faster_repair_after_stress): When dependency stress occurs, the parties know how to escalate, coordinate, recover, and learn rather than renegotiate under pressure.
• Reduced Opportunistic Withdrawal (reduced_opportunistic_withdrawal): Commitments, shared risk, and visibility make sudden abandonment or cost shifting less attractive and easier to detect.
• Improved Trust Without Blind Dependence (improved_trust_without_blind_dependence): The relationship becomes more dependable while retaining enough fallback capacity to avoid coercive or brittle lock-in.

If the archetype works, the relation becomes more dependable without pretending that failure is impossible. The parties know what stress looks like, which stabilizers activate, who carries which risks, and how recovery proceeds.

Tradeoffs

• Stability versus flexibility: Commitments and buffers improve continuity but can make adaptation slower.
• Redundancy cost versus cascade risk: Reserves and fallback paths cost money or attention, but they reduce the chance of relational collapse.
• Trust-building versus verification burden: Monitoring can increase confidence, but excessive verification can become surveillance or bureaucracy.
• Mutual support versus moral hazard: Guaranteed help can reduce fragility while also weakening incentives to maintain local capacity.
• Dependency preservation versus autonomy: Stabilizing a relation can preserve value but may entrench dependence unless exit guardrails remain real.

Failure Modes

• Stabilized exploitation: A stronger party uses stabilization to preserve an unfair dependency. Mitigate with autonomy guardrails, fallback rights, and power review.
• Hidden single point of reciprocal failure: The dependency map misses a shared supplier, infrastructure layer, data source, or informal role. Mitigate with stress tests and second-order propagation mapping.
• Buffer complacency: Parties add slack and ignore the underlying instability. Mitigate by pairing buffers with review, accountability, and capacity improvement.
• Unfunded stabilization promise: Agreements are not backed by resources or authority. Mitigate by linking commitments to budgets, owners, and realistic service levels.
• Correlated fallback failure: Backup paths depend on the same conditions as the primary path. Mitigate by checking fallback independence.
• Overcoupling through stabilization: Shared processes become so dense that the relation grows more brittle. Mitigate with coupling calibration and decoupling where mutual dependence is not needed.

Neighbor Distinctions

• Symbiotic Alignment: Designs mutual reinforcement and shared value. Mutual Dependency Stabilization protects a necessary dependency from fragility and cascade risk.
• Buffering: Adds slack. This archetype may use buffers but also includes dependency mapping, commitments, monitoring, fallback, repair, and autonomy guardrails.
• Failover: Switches to an alternate path after failure. This archetype manages the reciprocal relation before, during, and after stress.
• Bulkhead Isolation: Blocks propagation through separation. This archetype preserves a valuable coupling while making it safer.
• Dependency Exposure: Reveals hidden dependencies. This archetype uses that exposure to install stabilizers.
• Payoff Restructuring: Changes incentives. This archetype focuses on continuity under reciprocal fragility, though it may use incentive-like commitments.

Cross-Domain Examples

• Supply chains: A buyer and supplier create shared forecasts, reserve inventory, emergency capacity commitments, and fallback sourcing for critical components.
• Municipal emergency response: Neighboring jurisdictions pool equipment and define mutual aid thresholds before overload occurs.
• Software operations: Interdependent service teams define shared health indicators, deprecation guarantees, incident escalation, and fallback modes.
• Community care: A hospital and home-care network coordinate capacity signals and contingency support to prevent overload from cascading between them.
• Ecological management: Restoration efforts protect both pollinator habitat and host plant availability because decline on either side destabilizes the relation.

Non-Examples

• A company negotiates a lower price from a supplier without stabilizing reciprocal continuity.
• A platform publishes an API standard but does not address mutual dependency health or failure propagation.
• A household keeps emergency batteries; this is preparedness, not reciprocal dependency stabilization.
• A dominant organization locks a weaker partner into exclusivity with no exit path; that may intensify dependency rather than stabilize it ethically.

Related Abstractions

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (3)

• Coupling: Interdependence among subsystems.
• Resilience: Absorb shocks and adapt.
• Symbiosis: Mutual interdependence.

Also references 6 related abstractions

• Accountability: Responsibility for actions.
• Boundary: Defines system limits.
• Fault Tolerance: Continue operating under failure.
• Feedback: Outputs influence inputs.
• Functional Redundancy (Degeneracy): Multiple pathways fulfill same function.
• Observability: Infer internal state externally.

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Bilateral Dependency Stabilization · subtype · recognized

Stabilize a two-party reciprocal dependency with explicit commitments, buffers, monitoring, and fallback rights.

• Distinct from parent: The parent can cover multi-party networks; this variant emphasizes two-sided continuity and negotiated obligations.
• Use when: The relation is primarily between two parties or systems; Each side can name what it needs from the other; Failure on either side would materially harm the other.
• Typical domains: supplier relationships, interdepartmental service dependencies, technical service integrations
• Common mechanisms: bilateral service level guarantee, reciprocal support pact, joint contingency plan

Network Mutual Dependency Stabilization · scale variant · recognized

Stabilize reciprocal dependency across more than two parties where stress can propagate through a network.

• Distinct from parent: The parent includes any reciprocal dependency; this variant emphasizes many-node propagation and governance complexity.
• Use when: Several nodes rely on one another through shared capacity, standards, legitimacy, liquidity, or emergency support; Failure propagation is indirect or multi-hop; No single bilateral agreement is sufficient to stabilize the relation.
• Typical domains: regional emergency response, platform ecosystems, community care networks
• Common mechanisms: shared reserve pool, mutual aid agreement, shared monitoring dashboard

Opportunism-Resistant Dependency Stabilization · governance variant · candidate

Stabilize a dependency by reducing the ability of either side to abandon, exploit, or shift costs during stress.

• Distinct from parent: The parent covers many fragility modes; this variant centers credible commitment and anti-opportunism safeguards.
• Use when: The dependency fails because one side can gain by withholding support or moving risk onto the other; Trust is not enough to make continuity credible; Commitments, verification, and consequences are needed.
• Typical domains: strategic partnerships, supply contracts, platform governance
• Common mechanisms: performance bond, escrow, contractual step in right, public commitment register

Ecological Mutualism Stabilization · domain variant · recognized

Stabilize ecological mutual dependencies by protecting both sides of the relation and the conditions that connect them.

• Distinct from parent: The parent is cross-domain; this variant uses ecological monitoring and habitat interventions.
• Use when: Species, habitats, or ecological functions depend on each other; A decline in one side threatens the other side’s reproduction, nutrition, protection, or habitat maintenance; Intervention must preserve the relation rather than only one population.
• Typical domains: pollinator systems, reef restoration, forest regeneration
• Common mechanisms: habitat corridor plan, pollinator support planting, population monitoring protocol

Near names: Reciprocal Dependency Stabilization, Interdependency Stabilization, Mutual Dependency Hardening, Reciprocal Failure Prevention, Co-Dependency Stabilization.

Editorial Notes

Problem Classification

Classification: Fragility, Failure & Continuity Risk → Fault Containment & Bounded Service Loss

Problem kernel: one partner's failure propagates across a necessary reciprocal dependency

Rationale: One necessary partner's shock, nonperformance, exit, overload, or opportunism can propagate across the reciprocal dependency and disrupt the other's function, so continuity requires bounded failure, buffering, and repair. Common-mode loss requires nominally plural alternatives sharing one correlated cause; this record instead centers direct partner-to-partner failure propagation within one necessary relation.

Boundary considered: Fragility, Failure & Continuity Risk → Dependency Concentration & Common-Mode Loss

Why this classification prevailed: Fault containment governs bounding service loss when a necessary partner fails; common-mode loss governs multiple supposed providers or paths being removed together by shared concentration or correlation.

Review outcome: Adjudicated after independent review; high confidence.