LumenFlow’s campus governance layer lets a deployment reason about campus-scale compute — telemetry, tenant evidence, attested execution, and (in a later, explicitly-gated phase) energy — under three load-bearing boundaries. This page is the public, user-facing equivalent of the internal architecture decision that ratifies those boundaries.
Proposes, never actuates
Campus packs emit a proposal — a structured recommendation against physical power. The customer’s scheduler (a system outside LumenFlow’s trust boundary) is the only thing that actuates. No pack holds actuation capability over physical power.
Vendor-name-free
Governance reasons in opaque, semantic labels — capability_tier, provider_family,
data_egress_class — never concrete vendor brand strings. No vendor name appears in published
types or in branch logic.
Refuse over fallback
When a constraint cannot be met, the resolver refuses rather than silently downgrading. One
narrow, default-off, audited opt-out (allow_same_family_reviewer) is the only relaxation.
The hard line: campus packs propose, the scheduler actuates.
A campus pack may recommend an action against physical power — curtail this load, shift this batch — by emitting a proposal that carries the reasoning, the affected load, and the supporting evidence. It stops there. The customer’s energy scheduler reads the proposal, applies its own policy, and decides whether to act. Actuation lives with the scheduler, outside LumenFlow’s trust boundary.
power:curtail, power:dispatch, or power:set_setpoint capability in any
registry, and adding one requires a fresh decision an operator can read and
accept first.propose_curtailment,
which emits a proposal and returns. A negative test asserts the tool cannot
actuate physical power — the only observable effect of calling it is a proposal
record.This is the same evidence-based control-plane boundary LumenFlow applies to every state-mutating action: the framework surfaces a recommendation for an external decision-maker; it never reaches across the boundary and changes the governed system itself.
Campus governance reasons about compute in opaque, semantic labels:
| Label | What it describes |
|---|---|
capability_tier | What a compute source can do — not who provides it. |
provider_family | An opaque grouping for separation-of-duties (e.g. a reviewer must be outside the family that produced the work). |
data_egress_class | Where data may flow (e.g. campus_restricted vs. less-restricted classes). |
No vendor brand string appears in a published type, in resolver or policy branch logic, or in a registry/policy key. Where vendor identity must exist at all, it lives in opaque configuration values mapped behind the semantic labels — never in the type system and never in control flow. A negative test proves no vendor-name branch exists.
This is the campus-side application of the same principle LumenFlow uses for
agent surfaces and model routing: shared contracts express semantic intent,
and vendor-specific mapping is a workspace-owned translation layer, not a value
baked into the framework. Published @lumenflow/* exports stay stable across
vendor churn.
When a campus policy constraint cannot be satisfied, the resolver refuses. It
does not silently fall back to a weaker posture, pick the next-best option, or
downgrade data_egress_class to make the work fit. A silent fallback under a
governance regime runs work that should have been blocked, under a posture nobody
approved — the exact failure the regime exists to prevent.
The canonical case is family separation: a reviewer must be outside the
provider_family that produced the work. When no such reviewer exists, the
resolver refuses by default.
One narrow opt-out exists:
allow_same_family_reviewer is default-off. When an operator
explicitly enables it, the resolver may permit a same-family reviewer as
permit-with-audit-warning — the permit is recorded with a warning naming
the relaxed constraint, the family involved, and the operator decision that
enabled it. It is never a silent permit.The relaxation is tightly scoped: it applies to flexible-inference work only,
and is the single permitted exception. Energy work carries mandatory negative
tests proving it does not relax refusal for campus_restricted data or for
family-separation rules.