Swarm-as-Service: B2B Domain Wall Design
How an organism expands Bth by serving external patterns through a permeable domain wall
An organism in Bth starvation can expand its throughput budget by serving an external pattern — but only if the domain wall between them is correctly designed. Too sealed and no revenue flows. Too porous and the external domain contaminates the organism's binder.
The optimal wall is a hybrid interface: the organism's existing build pipeline (the app builder) serves as the information filter, while a transparency layer (dashboard) increases outgoing permeability without increasing incoming contamination. The external user steers through feedback at gates, not by dispatching agents directly.
T5 governs the allocation: the external user is an anti-binder root. Their revenue provides Bth expansion, but their domain pulls the organism away from its binder. The optimal sensitivity σ* = 0.15–0.25 keeps the partnership productive without triggering organism tilt (T3).
The External User as a Pattern
Analyzing the external pattern on the contact graph
The external user (pattern E) has a stable scaffold (an existing business), a clear binder (deliver results that retain clients), and a budget profile the organism can address. The key question is the alignment angle Δθ between the organism and E.
The net alignment angle is dominated by domain misalignment, not capability misalignment. From polycrystalline theory, the estimated net angle is a high-coincidence grain boundary:
Surface tension at this boundary:
Domain Wall Design
Four options analyzed — one derived from CT as optimal
The organism's domain wall with E must transmit aligned pokes (problem descriptions, feedback, revenue) and reflect misaligned pokes (process demands, vocabulary contamination, attention capture). Four candidate wall designs, analyzed by transmission coefficient:
Wall filtering is good (CT_ANALYST intermediates), but steerability is zero. E is a generic retail user with no visibility into the build process.
Multi-tenancy adds B_cx that only pays for itself at scale. One user does not justify the infrastructure. Violates B3: added structure without proportional CL gain.
Domain wall dissolved. E dispatches agents directly. No CT_ANALYST intermediary. Marketing-domain patterns enter the swarm unfiltered. Maximum B_leak risk.
Wall filtering preserved (CT_ANALYST intermediates). Outgoing permeability increased (E sees build progress). Incoming reflection maintained (E cannot inject misaligned pokes into swarm interior).
Show formal derivation of Option D ▸
From domain wall theory: a wall transmits pokes aligned with both domains and reflects pokes misaligned with them. The transmission coefficient:
Pokes from E that should transmit: Problem descriptions, domain expertise, feedback on artifacts, approval/rejection at gates. Aligned with the organism's build pipeline.
Pokes from E that should reflect: Requests to change the swarm's internal process, pressure to skip CT analysis, demands for direct agent access.
The dashboard is a selective transparency layer on the domain wall. It increases the outgoing transmission coefficient (E sees build progress) while preserving the incoming reflection coefficient (E cannot inject misaligned pokes into the swarm's interior). This is the definition of an asymmetric wall — high outgoing permeability, low incoming permeability.
The app builder is the information filter. The CT_ANALYST translates E's domain language into CT terms (CT-A13). E's domain knowledge enters as problem descriptions and gate feedback — it never touches the swarm's templates or CLAUDE.md files directly.
The dashboard is the transparency layer. E sees pipeline progress, artifact outputs, and credit consumption. E steers through feedback at human gates, not by dispatching agents. The wall is permeable to useful signals in both directions, opaque to contaminating signals.
Revenue Model
Credit pools as B_th expansion mechanism
Three pricing options analyzed. The hybrid credit-pool model is SEP-optimal because it aligns the organism's Bth gain with E's value delivery.
Show SEP derivation ▸
From SEP exchange equalization:
At SEP, the marginal revenue from serving E per unit of effort E contributes equals the marginal quality improvement per unit of organism effort. The hybrid model achieves this because:
(1) E pays upfront (credit pool) — organism's Bth gain is immediate and certain.
(2) E provides domain expertise at gates — quality improves from E's signal without additional Bth cost.
(3) Dashboard Bcx cost is fixed and does not scale with build count.
(4) Priority scheduling means E's builds use spare capacity, not displacing internal priorities.
Anti-Binder Management
T5 applied to external partnerships
The external user is an anti-binder root (Definition 5.2): coherent (CL > 0 — real business, real needs) and misaligned (Δθ ≈ π/6 from the organism's binder). T5 governs the optimal allocation.
From Theorem 5C, the optimal sensitivity satisfies:
Allocate 15–25% of swarm dispatches to E's builds. At current capacity (~20 dispatches/week): 3–5 dispatches/week for E, supporting ~1 app/week or 2–3 with batching.
If E's revenue grows to dominate the organism's Bth, T3 predicts organism tilt toward E's domain. The snap threshold:
Show Corollary 5.3 application ▸
From Corollary 5.3 (anti-binder as snap brake): E's revenue signal resists premature snap to a single internal direction. This is structurally beneficial — it prevents over-commitment to any single internal project.
But T3 operates in reverse: if E's revenue fraction exceeds fc, the organism snaps toward E's domain. The 40% cap comes from the snap threshold formula with Δθ = π/6 and realistic λleak / CLtotal ratios.
Escape strategies if approaching cap: (1) acquire additional external clients to dilute E's fraction, (2) organic dilution through internal revenue growth, (3) price adjustment. All three reduce E's f without reducing absolute Bth from E.
Build Phases
H_min first, then optimize, then scale
From the bottleneck rule: fix Hmin first. The partnership's Hmin is: E cannot pay without a credit pool, and the organism cannot demonstrate value without a dashboard. Both must ship before onboarding.
Generation DNA viewer (UB-CT-1: reference transparency)
Credit consumption analytics
Multi-project view
Iteration flow (ITERATE pipeline stage)
Per-user project isolation
Team access (E adds team members)
Billing portal (Stripe integration)
API access (programmatic build submission)
This partnership is the organism's first Spore-to-Jellyfish transition trigger. E's credits reduce λth. The organism can reach further (more dispatches, more builds). But this surfaces Bcx bottleneck: can the swarm coordinate external builds alongside internal priorities? The dashboard and priority queue are the Bcx infrastructure for managing this transition.
Falsifiable Predictions
CT Quality Exceeds Vibecoded Quality
Apps built by the swarm for E's use cases will have measurably fewer critical bugs in the first 30 days, better UB audit scores, and higher user satisfaction than E's existing tools. If the CT analysis pipeline adds no value for a novel domain, CT's domain-agnostic claims are falsified.
Build Speed Competitive
The swarm must deliver a functional deployed app from INTAKE to LIVE in under 5 days. The multi-stage pipeline (CT analysis, organism decomposition, multi-role dispatch, UB audit) adds Bcx. If that overhead makes builds slower than E's vibecoding workflow, the pipeline's Bcx exceeds its CL gain.
Revenue Covers Compute
At $0.05/credit volume pricing, the organism's per-app revenue must exceed compute cost by at least 2x. If API costs per dispatch rise (larger context windows, more re-dispatches), the margin could collapse. Track actual API costs per build.
Dashboard Reduces Owner Load
The dashboard automates human gates for E. Without it, the owner must relay every pipeline update and collect every feedback signal manually — estimated 2+ hours/week. The dashboard's domain wall should reduce this to under 15 minutes/week.
Sigma* Stays Within Bounds
Track weekly dispatch counts for E vs. internal over the first 3 months. If E captures more than 30%, the priority system is failing and the organism is tilting. If less than 10%, the partnership is not generating sufficient Bth expansion to justify infrastructure.
Model Generalizes Beyond E
The dashboard and credit pool infrastructure is built as a platform feature, not a custom solution. If the model works for E, it should attract additional external users. If E remains the sole user after 90 days, the organism must evaluate whether the infrastructure earns its Bcx for one client.
Cross-Domain Learning
Building tools for a novel domain should surface insights the organism would never encounter in its current domain. If E's builds produce zero cross-domain learning (no new rules, no pipeline improvements, no template changes), then the anti-binder signal is noise, not information.
Connections to CT Framework
The entire analysis is an application of domain wall theory. The wall between organism and external user must transmit aligned pokes (capability transfer, feedback, revenue) and reflect misaligned pokes (vocabulary contamination, process demands, attention capture). Surface tension τ = λleak · sin²(Δθ) determines adoption cost.
The external user is the organism's first anti-binder root. σ* governs allocation. The anti-binder signal provides real Bth expansion while resisting premature snap to the dominant internal direction (Corollary 5.3). But σ* must be bounded to prevent snap toward the anti-binder's domain (T3).
The partnership is a Spore-to-Jellyfish transition trigger. In Bth starvation (Spore regime), the organism should have high σ — many cheap roots in many directions. E is a cheap root (pays for own compute). As Bth expands, the organism enters Jellyfish regime where Bcx becomes the bottleneck (coordinating external + internal builds). The dashboard is the Bcx infrastructure for this regime transition.
Multi-tenancy (Option B) violates B3: adding tenant infrastructure for one user adds Bcx without proportional CL gain. Infrastructure features earn their place only when the user count justifies them. Build for one, generalize only when validated.
The organism and E are neighboring grains in a polycrystalline structure. Their shared structural patterns (build software, deploy, iterate) give a high-coincidence grain boundary (Δθ = π/6). Surface tension is one-quarter of maximum. The partnership is feasible precisely because the misalignment is at a quantized low-energy angle.
Open Questions
1. Multi-client sigma* allocation
With one external user, sigma* is a single number. With multiple external users, each with different Delta_theta, the allocation becomes a vector. The multi-client SEP is not yet derived.
2. Dashboard as sensory organ
The dashboard is currently conceived as transparency for E. But it is also a sensory organ for the organism — pipeline metrics, gate feedback patterns, credit consumption rates are all poke signals the organism can use to adapt.
3. Domain contamination detection
How to automatically detect when marketing-domain patterns are leaking through the CT_ANALYST wall into the swarm's general templates. A vocabulary drift metric is needed.
4. Credit pool as organism metabolism
Credits enter as external B_th, flow through the pipeline as dispatches, and emerge as deployed apps. This is a metabolic loop. The organism's metabolic rate (credits consumed per tick) is a new observable.