Governed AI compute: campuses and data centres

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. A runner must hold a campus grant from your workspace before it can claim work routed to that site. A runner that only self-declares the capability is refused at claim time. An unenrolled runner cannot pull campus-bound work at all. Ask your LumenFlow contact to set up the grant for your workspace.

GPU attestation: verified, not just claimed#

Where a campus node supports confidential-compute attestation, LumenFlow cryptographically verifies the GPU/TEE attestation quote before counting it as verified — it does not take a self-reported claim at face value. A quote that fails verification, or that cannot be evaluated, is labelled unverifiable or self-asserted in the proof bundle, never silently upgraded to verified. The bundle reports which of these applies to each record it covers, so a recipient re-verifying it independently sees exactly how much trust each attestation earned, not a single blended "trusted" flag.

Propose, never actuate — even here#

Everything above — routing, capability grants, attestation, energy and residency proof — stops at governance and evidence. LumenFlow does not control facility power, cooling, physical scheduling, or the hardware itself; a campus capability grant authorizes a runner to claim work, not to actuate anything physical. That boundary holds regardless of what a node's attestation or capability grant says.