Provider Load Split Table¶
Allocation artifact — instantiates Dependency Concentration Control
The concrete allocation sheet that names what share of demand each provider is meant to carry, turning a diversification target into intended percentages and tiers.
Provider Load Split Table is the concrete answer to "so where should the load sit?" It names each provider and the share of demand — traffic, spend, inventory, cases, authority — it is meant to carry, and it sorts providers into tiers (primary, secondary, warm standby) with the criteria that qualify one for each. Its defining move is to make allocation a decision made in advance rather than an accident of procurement history: it is the explicit target state the rebalancing steers toward, distinct from the policy that constrains it and the metric that measures where load actually is. A rule says "no provider above 50%"; this table says "Processor A: 50, B: 35, C: 15" — the specific split that satisfies that rule.
Example¶
A merchant routes card transactions through one acquirer that, over years of least-cost routing, quietly grew to carry ≈85% of volume. The load split table resets the intent: Processor A 50%, B 35%, C 15%, with routing rules mapping card types and regions to processors, and tiers that keep C a warm tertiary held at 15% precisely so it stays exercised rather than theoretical. Cost optimization had concentrated the flow; the table re-optimizes it for resilience without abandoning cost as a factor. What was an emergent 85% becomes a designed 50/35/15 that the rebalancing executes against and the drift monitor checks reality against.
How it works¶
- Assign intended shares. List providers and give each a target share of the chosen load unit; the shares are the plan, not a description of today.
- Tier and qualify. Sort providers into primary / secondary / standby with explicit qualification criteria, so a fallback is not discovered to be unqualified mid-incident.
- Encode the routing that realizes the split. Specify which slices of demand (card types, regions, product lines) go where, so the target is executable rather than aspirational.
- Hold it as the target, not the truth. The table states where load should sit; the policy above it sets the limits, and the live measure below it reports the gap.
Tuning parameters¶
- Number of active providers and evenness — a flatter split is more resilient but sheds volume discounts and adds coordination overhead.
- Tier depth — how much sits in warm standby vs. active service; idle standby costs money but stays proven, cold standby is cheap and untrustworthy.
- Load unit — split by raw volume vs. revenue-at-risk vs. capability; the unit decides what "balanced" means.
- Rebalancing speed — an abrupt cutover vs. a glide path toward the target; faster reaches safety sooner but stresses the receiving providers.
- Routing granularity — one coarse split for all demand vs. fine per-segment rules; finer buys precision at the cost of complexity.
When it helps, and when it misleads¶
Its strength is that it makes allocation an explicit, ownable decision and hands the rebalancing and drift-monitoring steps a concrete target to work against, instead of leaving the split to whoever signed the last contract.[n1]
Its failure mode is the gap between intended and realized: demand swings, price changes, and outages pull the actual allocation off the sheet, so a split trusted rather than reconciled against measured share is a comforting fiction. Two traps recur — a tertiary parked at 0% "for emergencies" is untested capacity that will fail when called, and a split written purely on price silently re-concentrates onto the cheapest provider (the run-backwards version: drafting the table to ratify the incumbent's dominance). The discipline is to reconcile intended against realized share on a cadence and to keep every standby tier warm enough to trust.
How it implements the components¶
Provider Load Split Table fills the where-should-load-sit side of the machinery:
load_rebalancing_plan— the table is the target allocation the rebalancing moves demand toward.tiered_provider_portfolio— it structures providers into primary / secondary / standby tiers with explicit qualification criteria.
It does not mandate the minimum number of sources or the maximum any one may hold (concentration_limit_band) — that is the Multi-Sourcing Rule and Concentration Cap Policy — nor prove the planned shift is actually executable (shadow_capacity_reserve, segmentation_or_firebreak_boundary), which is the Substitution Drill; this artifact plans the split those constrain and validate.
Related¶
- Instantiates: Dependency Concentration Control — it is the concrete allocation that a diversification target is executed through.
- Consumes: Top-K Exposure Share for the current shares it must move away from, and the Concentration Cap Policy for the band it must satisfy.
- Sibling mechanisms: Substitution Drill · Top-K Exposure Share · Multi-Sourcing Rule · Concentration Cap Policy · Weighted Dependency Graph · Portability Checklist · Effective Independent Provider Count · Dependency Concentration Heatmap · Common-Mode Dependency Audit · Dependency Concentration Stress Test · Residual Concentration Risk Register
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Provider Load Split Table operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it the concrete allocation sheet that names what share of demand each provider is meant to carry, turning a diversification target into intended percentages and tiers.
Independent corroboration: The frozen evidence defines Provider Load Split Table as 'The concrete allocation sheet that names what share of demand each provider is meant to carry, turning a diversification target into intended percentages and tiers', so its operative form is Representation, Specification & Plan.
Nearest alternative: Decision, Gate & Allocation — Provider Load Split Table includes features of a case-specific gate, selection, routing, prioritization, or resource disposition, but its defining operation is a static representation, map, specification, schema, or prospective plan that externalizes information.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Logistics & Supply Chain Management
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Allocating demand shares across providers is a supply-chain sourcing and capacity-planning artifact.
Related originating lineages:
- Operations Research — Optimization and capacity-allocation methods materially shaped quantitative load splits.
Review resolution: Both blind reviewers agree on logistics_supply_chain as the primary origin. Explicit reconciliation resolves origin_mode_disagreement, encyclopedia_synthesis_disagreement. The merged alternate lineages retain only domains the reviewers identified as materially formative; domain_reach=multi_domain records later applicability separately from origin breadth.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Second-sourcing (dual- or multi-sourcing) is the long-standing supply-chain practice of deliberately qualifying and carrying more than one provider for a critical input; the split table is where that practice is made numerically explicit rather than left as a general intention. ↩