Dark Matter Docs

The atomic unit of compute-ready energy capacity. A ComputeSlot references a Position and adds MW capacity, interconnect topology, permit stack, fuel source, cooling profile, network backhaul, and stage-gate state.

Overview

A ComputeSlot represents a unit of compute-ready energy capacity — a quantity of power, measured in megawatts, that can be contracted, decomposed, and transferred. Each slot is paired with a Position that holds the legal and economic wrapper (typically a Compute SPV LLC); the slot holds the physical and operational facts.

The two are linked through the vertical_decoration hook on Position. See Verticals for how this layering works.

Core fields

Property	Type	Required	Description	Example
slot_id	string	Yes	Unique identifier. Lowercase-alphanumeric with hyphens, 3–64 chars.	—
position_id	string	Yes	Foreign key to the Position that wraps this slot legally and economically.	—
status	enum	Yes	Lifecycle: draft, land_secured, under_development, permit_complete, financed, under_construction, energized, tenanted, sub_let, decommissioned, voided.	—
site_class	enum	Yes	Physical class — see /docs/energy/concepts/fuel-source-class for the full enum.	—
capacity_mw	number	Yes	Atomic capacity in MW. The atomic decomposition unit is 1 MW; aggregations of 10 MW and 100 MW are standard reporting blocks.	—
jurisdiction	object	Yes	Country (ISO-2), regulatory bodies, and tax-stability regime (e.g. AR_RIGI). See /docs/energy/concepts/jurisdiction-codes.	—
interconnect	object	Yes	Topology: in_front_of_meter / behind_the_meter / hybrid / islanded; voltage class; queue position with grid operator.	—
stage_gate	object	Yes	Current gate + history. The nine-gate ladder LAND → ENERGY → PERMITS → SUBSTATION → TURBINES → FINANCE → BUILD → ENERGIZE → TENANT.	—
fuel_source	object	No	Primary class, carbon class, supply contracts, field/basin, heat content.	—
permits	array	No	Permit stack — land use, environmental impact, water draw, indigenous consultation, gas extraction, etc., each with status + authority + reference id.	—
cooling	object	No	Cooling type, water draw, water source, water rights id, ambient temperature envelope.	—
network_backhaul	object	No	Primary + secondary fiber providers, capacity, carrier diversity, subsea cable dependencies, peering hub, RTT latency.	—
tenant_assignment	object	No	Active tenant — participant id, allocated capacity, use class, term.	—
parent_slot_id	string	No	If this slot is the result of a decomposition, the parent's slot_id.	—
decomposition_tree	array	No	If this slot has been decomposed, the list of child slot_ids.	—

Example: Pampa JV Phase 1

{
  "slot_id": "slot-pampa-jv-phase1",
  "position_id": "pos-pampa-jv-phase1",
  "status": "under_development",
  "site_class": "gas_associated",
  "capacity_mw": 200,
  "ramp_to_capacity_mw": 5000,
  "ramp_to_months": 60,
  "jurisdiction": {
    "country": "AR",
    "subdivision": "Neuquén",
    "regulatory_bodies": ["ENRE", "CAMMESA", "ENARGAS"],
    "tax_stability_regime": "AR_RIGI",
    "tax_stability_certificate_id": "RIGI-2026-0042"
  },
  "fuel_source": {
    "primary_class": "associated_gas",
    "carbon_class": "fossil",
    "field_or_basin": "Vaca Muerta"
  },
  "interconnect": {
    "mode": "behind_the_meter",
    "voltage_class": "behind_meter_only"
  },
  "stage_gate": {
    "current_gate": "permits",
    "current_status": "in_progress",
    "overall_dev_pct": 0.15
  }
}

The complete fixture is at packages/fixtures/energy/sample-compute-slot.json and is validated end-to-end in Patient Energy Zero.

Decomposition

The atomic decomposition unit is 1 MW. A 200 MW slot can be split into 4×50 MW blocks for sub-team allocation, 20×10 MW blocks for multi-tenant arrangements, or 200×1 MW for maximum granularity. Decomposition uses the core Decomposition machinery and produces child slots that reference the parent via parent_slot_id. Each child can be independently tenanted, encumbered, and transferred.

Lifecycle vs. stage-gate

status is the lifecycle state of the slot as a registered entity (draft → tenanted → decommissioned). stage_gate.current_gate is the development state of the underlying physical project (land → tenant). They are related but not identical: a slot can be tenanted (status) while sitting in tenant (stage_gate) — the consistent state — and a slot can be under_construction while sitting in build gate. A slot in decommissioned status is terminal; a slot at the tenant gate is operational.

API endpoints

POST /v1/energy/slots — register a slot
POST /v1/energy/slots/{id}/decompose — split into child blocks
POST /v1/energy/slots/{id}/advance — advance the stage gate
POST /v1/energy/demand/{id}/match — match against tenant demand
POST /v1/energy/contracts — execute a contract referencing the slot

Position Object — the legal/economic wrapper
Verticals — how this decoration model works
CapacityContract — how a tenant binds capacity
DemandSpec — how a tenant expresses requirements
Stage gates — the development ladder

ComputeSlot