NIMBUS Connect Reference Architecture

Heterogeneous artificial-intelligence work can cross local accelerators, remote model interfaces, private inference services, tools, protocol servers, rented capacity, and dedicated systems without becoming one homogeneous resource. That diversity creates a recurring architectural problem after authority has already been decided: how can a system place, supervise, retry, meter, reconcile, and return work without silently changing the permission, identity, data, time, capability, or economic bounds under which the work was authorized? Research offers context for disaggregated CPU and GPU resources, topology-aware scheduling, and heterogeneous serving, but those results do not establish the authority-preserving execution layer proposed here. Related work also frames inference demand as unpredictable and resource constrained, yet it does not provide the grant, profile, or reconciliation contracts needed by this architecture. Joint placement, scheduling, and allocation across heterogeneous computing layers likewise demonstrates the breadth of the coordination problem without proving that placement can preserve an externally issued authority envelope. This paper proposes NIMBUS Connect as a deliberately narrow governed-execution layer between an externally issued route grant and one or more heterogeneous execution endpoints. Its central claim is conditional and losable: a minimum execution stack can consume a bounded grant and place, supervise, meter, and reconcile heterogeneous work while making non-widening mechanically testable, provided the stack treats authority as attenuation-only, delivery as at least once, accepted effect as commitment scoped, duplicate use as immutable, and unresolved state as first class. NIMBUS does not decide whether work is authorized, set a price, determine a refund, or declare semantic truth. It receives authority from ARBITER, returns operational and usage evidence toward PRETIUM and later synthesis, and fails closed when the relevant projection cannot be compared. The proposed architecture contains a descriptive registry plane, C0, plus eight operational components, C1 through C8. C0 owns versioned provider, offer, endpoint, adapter, and execution-profile records but creates no eligibility. C1 projects the received grant; C2 holds an append-only commitment ledger; C3 translates without widening; C4 places and supervises; C5 records attempt lifecycles; C6 returns operational result, usage, and provenance; C7 handles bounded continuity, exit, and reconciliation transport; and C8 holds evidence, observability, conformance, audit, and negative controls. Separate commitment and attempt machines prevent a successful duplicate attempt from automatically fulfilling a commitment. A declared partial order makes a proposed target projection comparable to the source grant. Greater or incomparable projections are denied or quarantined rather than repaired through silent substitution. The strongest counter-thesis is that a distinct NIMBUS layer is unnecessary or incoherent. Existing gateways, schedulers, workflow engines, identity systems, and telemetry tools might be composed to preserve the same bounds. If so, an additional layer would add state, failure modes, and reconciliation work without earning a separate role. The proposal loses if it trusts provider enforcement as authorization, widens authority during failover, destroys provider-native capability through a lowest-common-denominator abstraction, hides duplicate resource use, coerces unknown state to success or failure, or rebuilds authorization inside an adapter. It also loses if provider exit cannot preserve the state needed for reconciliation. The paper develops proposed requirements, mechanisms, ten synthetic cases, capability-class alternatives, a disruptor matrix, and an evidence ladder. No synthetic case has been executed. The architecture is a falsifiable design hypothesis, not a product claim.