Hardware Reserve Fund & Capital Lifecycle

Executive Summary

The Underground Data Center's computational capacity (a 4-node GPU cluster drawing roughly 1.5 kW, plus servers, storage, networking, and power/battery systems) depends on hardware that depreciates on a 3-5 year lifecycle. A 10-year operational plan requires a full-stack refresh at Year 5 and again at Year 9-10. This document specifies:

1. A mandatory Hardware Depreciation Reserve Fund (HDRF) that allocates 15-20% of annual operating budget to hardware replacement.
2. A modular GPU deployment strategy that staggers capital expenditure across Years 1-4 and leverages Moore's Law price deflation for replacements.
3. A federated peer-to-peer hardware sharing model that distributes risk across multiple neighborhoods.
4. Patient capital investment covenants that align investor returns with long-term sustainability.

Over a 10-year cycle, this strategy ensures zero corporate cloud dependency, maintains local control, and preserves community ownership while managing hardware lifecycle costs.

I. The Hardware Depreciation Problem

Section 1.1: Hardware Lifecycle & Cost Reality

The compute stack has two lifecycles running at once:

• GPUs (RTX 6000 Ada class): ~$8K-$9K per card; a 4-card inference cluster is $34K-$36K; expected useful life 3-5 years. Performance falls relative to new hardware after Year 3; workload completion times lengthen.
• Servers, storage, networking, power and battery systems: the $195K "compute & storage" line of Phase 1 capital. Useful life 5-7 years; storage and batteries wear first.
• Full-stack refresh: replacing the GPUs, storage, and the worn portion of servers and batteries together costs roughly $100K-$120K at current prices, less at Year 5 and Year 9 as prices fall.

Section 1.2: The Capital Crisis

A traditional business model assumes:

• Year 0: Purchase hardware ($195K compute & storage, $35K GPUs).
• Years 1-4: Operate normally.
• Year 5: Hardware fails or becomes obsolete. Budget is exhausted paying operations. No reserve for replacement.
• Year 5+ (Crisis): Options are: (1) lease from AWS/Azure (corporate dependence, sovereignty lost); (2) take out debt (dilutes ownership, increases operating risk); (3) shut down (community loses AI infrastructure).

Mapleton Fall Creek cannot tolerate any of these outcomes.

II. Solution 1: Hardware Depreciation Reserve Fund (HDRF)

Section 2.1: HDRF Mechanics

• Allocation Rate: 15-20% of annual operating budget is deposited into a separate, locked Hardware Reserve Fund.
• Total Annual Operations Budget: $425K (Section 4, Main Proposal).
• HDRF Annual Deposit: $63,750-$85,000 (15-20% of $425K).
• 10-Year Gross Deposits: $637,500-$850,000 — sufficient for two full-stack refreshes with a substantial balance carried into the next decade.

Section 2.2: HDRF Governance

• Account Structure: HDRF is held in a separate bank account in the name of "Mapleton Fall Creek Community Data Trust" (see Data Firewall Trust Charter).
• Access Controls: HDRF may only be accessed for hardware purchases, upgrades, or emergency repairs. Withdrawal requires approval from: (1) Data Steward (operational decision-making); (2) Finance Committee (budget oversight); (3) Trustee (fiduciary verification that withdrawal aligns with resident interests).
• Annual Reporting: The HDRF balance is reported quarterly to the Governance Board and annually to residents in a public "Hardware Stewardship Report."

Section 2.3: HDRF Allocation Schedule (20% case, net of spending)

III. Solution 2: Modular GPU Deployment Strategy

Section 3.1: Phased Deployment (Avoiding Monolithic Hardware Purchase)

Instead of purchasing the full 4-node GPU cluster before residents have voted on local inference, Mapleton Fall Creek stages deployment:

Phase 1A (Year 1-2): Foundation Cluster (2 × RTX 6000 Ada-class nodes)

• Cost: $17K-$18K, from Phase 1 capital.
• Capacity: Handles roughly half of the target inference workload (~0.7 kW continuous).
• Use Case: Baseline inference, monthly census processing, proof-of-concept governance analytics, evaluation of candidate open-weight models.

Phase 1B (Year 3-4): Expansion Cluster (2 more nodes) — only if residents vote for local inference

• Cost: $17K-$18K, funded from operating surplus. The reserve is not touched.
• Capacity: Reaches the full 4-node cluster (~1.5 kW continuous), well inside the 32-40 kW passive earth-tube cooling envelope. No water consumed.
• Use Case: Neighborhood decision-support analytics, expanded census scope, nightly batch compute.

Phase 2 (Year 5-6): First Refresh

• Retire Phase 1A nodes; purchase next-gen GPUs (faster and cheaper than Year 1 equivalents). Replace worn storage and battery cells; refresh the oldest servers.
• Cost: $117K, from HDRF. Sell or hand down retired nodes to a partner neighborhood (recover $5K-$8K).
• HDRF after refresh: $308K.

Phase 2B (Year 7-8): Maintain & Replenish

• No major hardware purchases; operations smooth.
• HDRF grows +$85K/year to $563K by Year 8.

Phase 3 (Year 9-10): Second Refresh

• Retire Phase 1B nodes; purchase next-next-gen GPUs. Replace storage.
• Cost: $100K, from HDRF ($648K available before spending). Resale of retired nodes: $4K-$6K.
• HDRF at end of Year 10: $633K, ready for the next decade.

Section 3.2: Moore's Law Advantage

Historical GPU price/performance trends show 25-30% cost reduction per generation (every 18-24 months):

• RTX 6000 Ada class (2022-2024): $8K-$9K per card.
• Next-gen (2025-2026): ~$6K-$7K per equivalent performance.
• Next-next-gen (2027-2028): ~$4.5K-$5.5K per equivalent performance.

By staggering purchases across multiple years, Mapleton Fall Creek avoids the hardware cost cliff and benefits from declining prices. The GPUs become the cheapest line in each refresh; storage and batteries become the largest.

IV. Solution 3: Federated Hardware Sharing (Peer-to-Peer Redundancy)

Section 4.1: Cooperative GPU Network

Instead of relying solely on local hardware, establish formal partnerships with allied neighborhoods:

• Partner 1 (Pendleton): 2 nodes (Year 2).
• Partner 2 (Fountain Square): 2 nodes (Year 3).
• Partner 3 (Garfield Park): 2 nodes (Year 4).

Total Cooperative Cluster: 10+ nodes spread across 4 neighborhoods.

Section 4.2: Federated Compute Model

• Sovereignty Preserved: Each neighborhood maintains its own data, encryption keys, and governance. Data never leaves neighborhood servers (except for anonymized, encrypted backup).
• Workload Distribution: Computationally intensive jobs (model fine-tuning, batch inference) can be distributed across the cooperative network: MFC handles real-time census inference (speed-critical); Pendleton handles nightly batch processing; Fountain Square handles specialized analytics (housing market analysis, environmental monitoring).
• Hardware Redundancy: If MFC's cluster fails, Pendleton/Fountain Square clusters can temporarily absorb MFC's real-time workload (with lower performance, but no data loss).
• Cost Sharing: Each neighborhood funds its own hardware. Cooperative maintenance staff (1 FTE shared, $50K/year) manage all clusters, reducing per-neighborhood overhead.

Section 4.3: Cooperative Procurement Power

• By Year 4-5, a 4-neighborhood cooperative (10-16 nodes plus storage) becomes a meaningful buyer.
• Negotiate volume discounts with hardware vendors: 15-25% on bulk orders.
• Shared procurement reduces per-neighborhood refresh costs by $10K-$20K per cycle.

Section 4.4: Federated Hardware Financing

• Establish a "Cooperative Hardware Fund": a shared pool where each neighborhood contributes proportionally to purchase/replace hardware for the network.
• Governance: A "Hardware Council" with representatives from each neighborhood (via sortition) decides when to replace aging hardware, which new models to purchase, and how to allocate compute capacity during emergencies.
• This prevents any single neighborhood from being held hostage to hardware availability.

V. Solution 4: Patient Capital Covenants

Section 5.1: Return Structure (Tying Investor Returns to Hardware Sustainability)

Traditional patient capital models offer fixed returns regardless of operational performance. This misaligns incentives. Instead:

Covenant: Hardware-First Returns Model

• Year 1-3: Zero returns to investors. All operating surplus goes to HDRF and operational reserves.
• Year 4-7: Capped returns (5-7% annually) only if HDRF exceeds $300K.
• Year 8-10: Capped returns (10% annually) only if HDRF exceeds $500K.
• If HDRF falls below thresholds (e.g., due to unexpected hardware failure), investor returns are suspended until reserves are replenished.

Covenant: Hardware Replacement Clause

• Investors accept that 15-20% of operating budget is locked into hardware reserves. Investors cannot demand that this allocation be reduced to increase their returns.
• If a hardware replacement exceeds HDRF (e.g., catastrophic failure), investors commit to accepting diluted or deferred returns for 1-2 years while reserves are rebuilt.

Covenant: Community Priority

• If MFC must choose between paying investor returns and funding hardware replacement, hardware replacement takes absolute priority.
• Investors acknowledge this hierarchy in writing. Returns are subordinate to operational continuity.

Section 5.2: Sunset Investor Role

• Patient capital is structured as a 10-year covenant, not perpetual ownership.
• After 10 years, investor rights are either (a) bought out by MFC, or (b) capped returns continue in perpetuity at 5% annually (no principal return).
• By Year 10, HDRF will hold $633K after two refreshes, sufficient to repay patient capital investors and transition to community ownership.

VI. Financial Projections & Sensitivity

Section 6.1: Base Case (20% HDRF Allocation)

Total Refresh Spend from HDRF: $217K over 10 years. Total Operating Spend: $4,250K ($425K × 10 years). Hardware refresh as % of operating budget: 5.1%.

Section 6.2: Stress Case (Storage and Server Failure in Year 4)

Suppose the primary storage array and one server fail unexpectedly in Year 4, before the planned refresh:

• Emergency cost: $60K replacement + $10K emergency repairs.
• HDRF available: $340K.
• Action: Tap HDRF; remaining reserve = $270K. Year 5 refresh is re-scoped to GPUs and batteries only ($60K).
• Impact on investors: HDRF dips below the $300K threshold; Year 4 returns are deferred (per covenant).
• Recovery: By Year 6, HDRF is above $350K; operations continue.

Conclusion: Even with unexpected failure, the 20% HDRF allocation ensures continuity without corporate cloud fallback.

Section 6.3: Upside Case (Moore's Law Acceleration)

If GPU price deflation is steeper than projected (e.g., 35% per generation instead of 25%), the Year 5-6 refresh costs $95K-$105K instead of $117K, and the reserve grows faster. Surplus can fund a Phase 2B expansion (add 2-4 more nodes) or be distributed as a community dividend.

VII. Governance & Monitoring

Section 7.1: Hardware Stewardship Committee

A 5-member committee (3 residents via sortition, 1 Data Steward, 1 Finance Officer) meets quarterly to:

• Review HDRF balance and spending.
• Forecast hardware lifecycle and replacement needs (12-24 month horizon).
• Evaluate new GPU models and open-weight LLMs for performance/cost.
• Negotiate with suppliers.
• Monitor hardware utilization and plan for upgrades.

Section 7.2: Annual Hardware Report

Each year, the community publishes a "Hardware Stewardship Report" that includes:

• Current HDRF balance and 10-year projection.
• Hardware utilization (GPU%, memory%, storage%), energy draw, and water consumption (expected: zero).
• Lifecycle status of each node (age, remaining useful life).
• Planned replacements for next 3-5 years.
• Cooperative network status (partner neighborhoods, redundancy capacity).

Section 7.3: Integration with Patient Capital Reporting

Quarterly investor reports include HDRF status and hardware lifecycle forecast. This transparency builds investor confidence that hardware sustainability is taken seriously.

VIII. Integration with Cooperative Bylaws

Section 8.1: Amendment to Financial Charter

Insert into Cooperative Bylaws, Financial Governance Section:

Section 4.3: Hardware Depreciation Reserve Fund (a) A minimum of 15% and maximum of 20% of annual operating budget shall be allocated annually to the Hardware Depreciation Reserve Fund (HDRF). (b) HDRF is held in a separate bank account in the name of the Community Data Trust and is accessible only for hardware purchases, upgrades, repairs, and emergency infrastructure expenses approved by the Hardware Stewardship Committee. (c) HDRF balance and allocations are reported quarterly to the Governance Board and annually to residents in a public Hardware Stewardship Report. (d) Patient capital investor returns are subordinate to HDRF allocations. In years when HDRF falls below $300K, investor returns are suspended until reserves are replenished. (e) The cooperative may not incur debt to finance hardware replacement. All hardware purchases shall be funded from HDRF or operating surplus approved by the Hardware Stewardship Committee.

IX. Next Steps

1. Immediate: Establish the HDRF bank account (separate from operational accounts) before accepting first patient capital investment.
2. Phase 1A (Months 1-12): Procure the two-node foundation cluster from Phase 1 capital; begin evaluating open-weight models against the census workload.
3. Phase 1B (Year 2): Begin outreach to partner neighborhoods (Pendleton, Fountain Square) for federated cooperative formation.
4. Ongoing: Publish quarterly HDRF reports; build resident understanding of hardware lifecycle and capital planning.