Campuses and data centres#
A campus — a dedicated AI data centre (data center / datacenter), GPU cluster, or compute facility, whether you operate it or a partner does — is a block of AI compute and its supporting infrastructure. LumenFlow does not own or run the hardware, and it is not a facility-management (DCIM) system: it does not manage power, cooling, networking, or hardware provisioning.
What LumenFlow adds is the layer most compute lacks: governance and tamper-evident proof of the AI work running on the floor — what ran, where, for whom, at what cost, and with what energy and carbon footprint. If you are building, running, or managing a data centre for AI workloads, that governance and proof layer is the part LumenFlow owns.
The proof bundle#
For any tenant connected to a campus, LumenFlow can produce a single sealed proof bundle covering four attested records for a time window:
- Utilisation — GPU-seconds consumed and the cost attributed to them.
- Residency — proof the work stayed in its pinned region.
- Carbon — emissions for the work, each figure tagged with how it was derived (measured, modelled, or estimated).
- SLA — target versus observed service windows, with any breach flagged.
The bundle rides the same evidence chain as the rest of LumenFlow: it is cryptographically anchored and passes chain verification before it leaves the system, so a recipient — an auditor, a customer, a regulator — can re-verify it independently. See Independently verifiable evidence.
Exporting the bundle requires a granted approval#
Exporting a tenant's proof bundle is gated: your workspace needs an active, operator-granted export approval before the export runs. Without one, the export request is refused with a structured decline receipt — it never falls back to a partial or redacted bundle. An operator grants the approval once through the standard approvals flow, and the export runs normally afterwards. This is a one-time governance step per workspace, not a per-export prompt.
Propose, don't actuate#
LumenFlow's campus role today is to govern and to prove. It surfaces what is happening and produces the evidence for it; it does not directly control physical power, cooling, or scheduling. That boundary is deliberate — it keeps LumenFlow a neutral record over the compute, not an operator of it.
Residency is enforced, not assumed#
Campus telemetry enters through the standard events ingest. Events classified as campus work carry a mandatory residency precondition: if the region routing isn't present, the event is refused rather than recorded in the wrong place. Residency is a gate, not a label.
Power and energy monitoring#
The same ingest carries the facility's power and carbon-intensity signals and its PUE (power usage effectiveness), and LumenFlow attributes the power and energy each run uses down to the token — so the proof bundle reports electricity use with measured / modelled / estimated provenance, not a guess (see Energy and carbon provenance). LumenFlow monitors and proves this; it never operates the electricity, power, or cooling.
Routing work to a specific campus#
Governed proof, residency enforcement, and which connected runner may claim a campus's work are all live: an operator grants a specific runner the campus-scoped capability, and only runners holding that grant can claim work routed to that site — an unenrolled runner cannot pull it. Talk to us about your rollout if you need help planning runner enrolment for a specific site.
info Campus governance is available to connected tenants today. If you operate or are planning a data centre or dedicated compute site and want governed proof over the AI compute on it, reach out.