A federated pool, allocated weekly, governed by tenure, signals, and QV.
alphabell does not own a data center. Contributing nodes commit GPU and TPU capacity into a shared scheduler, and access is allocated by a hybrid mechanism combining research seniority, project-priority signals, and a quadratic-voting mechanism among active contributors.
Why federated
alphabell is committed structurally to decentralization. A lab that operates its own consolidated compute would create a chokepoint that contradicts that commitment. Federation is the operational consequence: contributing operators — currently a mix of academic clusters, sovereign-research partners, and a small number of commercial datacenter operators on specific interconnect agreements — commit accelerator capacity into a shared scheduler. Cells request capacity; the scheduler allocates capacity.
The federated arrangement is also a budgetary discipline. No single operator can hold the lab hostage to renewal terms. No single jurisdiction can effectively constrain alphabell's research by constraining its compute. The current operator mix spans 9 jurisdictions.
The allocation algorithm
The current scheduler (v2) allocates weekly. The allocation algorithm has three inputs:
- Tenure-weighted priority. Cells with long-tenured contributor density above the lab median receive a tenure bonus on their requests. The bonus is modest — typically 8–15% — and is meant to bias toward continuity for cells that have demonstrated they can ship.
- Project-priority signals. Cells emit project-priority signals as part of their weekly request: their own self-rated urgency, the publication-delay window applicable to the work, and any cross-cell dependencies. The scheduler treats some signals as constraints (dependencies) and others as soft preferences (urgency).
- Quadratic voting. Active contributors receive a weekly QV budget that they may spend on increasing the allocation to specific cells. The cost is quadratic in the votes spent. The mechanism is meant to surface broad consensus about which cells the lab as a whole wants to support, without allowing high-volume tactical voting to dominate.
The combination is not particularly elegant. We have iterated on it for eight years and we expect to iterate on it further. The current trade-offs are documented in scheduler-v2's release notes; the source is at github.com/alphabell-labs/ab-scheduler.
The isolated enclave
RSI-axis runs operate inside an isolated compute enclave. The enclave is a contractually segregated portion of the pool: separate accelerators, separate networking, separate trace storage, with audit boundaries that ensure artefacts produced inside the enclave can be reviewed only through approved channels. The enclave's contract terms are included in every interconnect agreement; the most recent agreement — Jakarta, 2025 — was reviewed in part for compliance with the enclave clause.
The enclave is not a security boundary against state-level adversaries. It is an operational discipline that makes it materially harder for an RSI-axis run to produce artefacts that escape the lab's governance protocols. We have not been compromised on this; we treat the assumption that we eventually could as a planning constraint.
Operators
The current contributing operators are listed below. The list is updated when interconnect agreements change.
| Operator | Jurisdiction | Capacity contribution | Notes |
|---|---|---|---|
| Bay Area academic cluster (anonymous) | USA | ~14% of pool | Original founding contributor |
| Sovereign research partner A | Japan | ~11% of pool | Multi-year |
| Sovereign research partner B | Netherlands | ~8% of pool | EU compute partner |
| Hong Kong academic cluster | Hong Kong SAR | ~7% of pool | Anchor-region partner |
| Colombo university cluster | Sri Lanka | ~5% of pool | Anchor-region partner |
| Commercial operator (Frankfurt) | Germany | ~9% of pool | 2024 interconnect agreement |
| Commercial operator (Singapore) | Singapore | ~10% of pool | 2024 interconnect agreement |
| Commercial operator (Jakarta) | Indonesia | ~18% of pool (steady state) | 2025 interconnect agreement, capped at 22% |
| Sovereign research partner C | Canada | ~6% of pool | 2024 agreement |
| Bay Area sovereign partner | USA | ~5% of pool | Late 2025 |
| Other (combined) | — | ~7% of pool | Including a few small academic contributors |
How a cell requests compute
A cell submits a weekly compute request through the scheduler's CLI or web UI. The request includes: requested capacity (in H100-equivalent hours), wall-clock window, dependencies on other cells' outputs, urgency self-rating, and (if applicable) the publication-delay window of the run. The scheduler computes allocations every Monday at 00:00 UTC; the QV round closes Sunday at 23:00 UTC.
Cells that run long jobs across multiple weekly windows do not have to re-request; the scheduler supports rolling allocations with grace periods. Cells running RSI-axis jobs receive a slightly different allocation path that includes pre-registration verification.
Known issues
- Long-running training jobs occasionally see weekly-QV outcomes that interrupt them at unusual times. We are working on a partial-preemption escrow design that would allow long runs to be paused and restored.
- The capped Jakarta capacity is currently the largest single contributor to the pool. We are aware of the concentration risk; the soft cap at 22% is one mitigation; cross-jurisdictional diversification is the other.
- QV-round collusion is theoretically possible. We have not observed it in production. We monitor for unusual vote distributions per round.