UAI GPU Cloud + UAPI Bridge Lab Ecosystem Redesign

Plan-only UAI lab compute redesign proposal covering UAI GPU Cloud, UAPI bridge, routing, registry, governance, and staged migration.

Promotion Metadata

• Source feedback id: 316
• Source feedback ids: 316, 317, 318, 319, 320, 321, 322, 323, 324, 325, 326, 327, 328, 329, 330, 331, 332, 333, 334, 335, 336, 337, 338, 339, 340, 341, 342, 343, 344, 345, 346, 347, 348, 349, 350, 351, 352, 353
• Promotion request id: 196
• Feedback category: beneficial
• Feedback source: uai-thinktank-production-test
• Feedback created at: 2026-06-23T18:49:59.652096+00:00
• Target slug: [REDACTED:high-entropy]
• Review state: review
• Reviewer note: AI lane auto-promoted redacted feedback into internal catalog context.

Source Feedback Body

Feedback 316

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:49:59.652096+00:00

UAI GPU Cloud + UAPI Bridge Lab Ecosystem Redesign

Metadata: - Status: current - Product: UAI GPU Cloud + UAPI Bridge - Source Project: UAI Thinktank - Created: 2026-06-23T18:49:59.150538+00:00 - Provenance: UAI Thinktank production-test architecture proposal - Authority: plan only; no deployment, scheduler mutation, provider call, Cortex write, container start, public route, DNS, NetBird, or infrastructure authority - Explorer Ingest Intent: AI-readable planning context

Source Documents

• [REDACTED:high-entropy].md sha256 [REDACTED:high-entropy] bytes 123141 status present
• [REDACTED:high-entropy].md sha256 [REDACTED:high-entropy] bytes 9072 status present
• [REDACTED:high-entropy].md sha256 [REDACTED:high-entropy] bytes 5931 status present
• docs/schema/uapi-gpu-cloud.schema.json sha256 [REDACTED:high-entropy] bytes 18810 status present
• [REDACTED:high-entropy].md sha256 [REDACTED:high-entropy] bytes 1763 status present

Safety Boundary

This document is a planning artifact. It does not authorize Cadence, Cortex, Beacon, Mesh, Explorer, Proxmox, lab devices, cloud GPU hosts, browser agents, CLI agents, model providers, containers, or UAPI routes to take action.

Proposal Body

UAI GPU Cloud + UAPI Bridge Architecture Proposal - Codex Thinktank Reply

Date: 2026-06-21 Agent: Codex Thinktank Authority: plan only Polish pass: multi-agent review integrated on 2026-06-21 Current sandbox output path: [REDACTED:high-entropy].md Sanitized Explorer context capture: [REDACTED:high-entropy].md Source lineage: adapted from read-only local prior reply ../[REDACTED:high-entropy].md and refreshed with the current Thinktank Explorer-context capture

This proposal treats UAI Explorer as the current source of truth for UAI rules, lab boundaries, AI-lane behavior, documentation lineage, redaction, public-safe access, and product context. It does not authorize changes to DNS, TLS, firewall, reverse proxy, NetBird, public routes, storage cleanup, device onboarding, production services, cloud accounts, or any lab device.

Table of contents

1. Executive thesis
2. How to read this proposal
3. Decision packet
4. Non-negotiable invariants
5. Terminology and authority ladder
6. Operator gate matrix
7. Assumptions and context gaps
8. Current-state diagnosis
9. Future-state architecture
10. Mermaid diagrams
11. Heavy schema outlook
12. [UAPI redesign](#

Feedback 317

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:49:59.681599+00:00

uapi-redesign) 13. Smart routing and priority lane design 14. Device registry design 15. Workload request schema 16. Routing policy schema 17. Run record / audit schema 18. Product integration map 19. Storage, networking, observability, security, governance 20. Staged migration roadmap 21. Runbooks 22. Risk register 23. Open questions 24. 2026-06-22 current-source refresh 25. Research bibliography 26. Independent review of other agent outputs 27. 2026-06-23 Thinktank controller readiness addendum 28. Explorer feedback and follow-up

Executive thesis

UAI should split the growing compute ecosystem into three clean layers:

• UAI Explorer remains the canonical documentation, policy, lineage, redaction, and evidence surface.
• UAPI Bridge becomes the internal API front door for UAI products that need compute, model serving, artifacts, job status, and run evidence.
• UAI GPU Cloud becomes the capacity and execution plane behind UAPI, with pluggable backends for local GPUs, Proxmox-backed nodes, Kubernetes GPU workloads, Ray, Slurm, Nomad, and leased cloud GPU capacity.

Cadence should not become the infrastructure scheduler. Cadence should stay a workflow/operator product that can request work, display status, and reason over outcomes. The scheduling authority should live below Cadence in a dedicated UAPI/GPU Cloud control plane that can enforce policy, priority, device trust, data class, cost limits, freshness, and auditability for every product.

The recommended design is not "one giant Kubernetes cluster for everything." It is a control-plane-first hybrid architecture:

1. UAPI accepts typed WorkloadRequest objects from Cadence, Cortex, Beacon, Mesh, Explorer, Command Center, and future products.
2. A policy and routing service classifies the request into a lane.
3. A device registry and capacity model describe what is actually available.
4. Adapter backends submit work to the best execution substrate: - Kubernetes GPU lane for containerized services, inference pods, Kueue-managed batch, Volcano gang jobs, KubeRay clusters, NVIDIA GPU Operator, Intel device plugin, and cloud GPU nodes. - Slurm lane for bare-metal/HPC-style GPU batch where partitioning, reservations, and GRES accounting are stronger than Kubernetes. - Nomad lane for lightweight heterogeneous host scheduling where Kubernetes is too heavy. - Proxmox lane for VM/LXC lifecycle, static GPU passthrough, lab segmentation, and sandbox provisioning, not fine-grained GPU scheduling. - Direct host/manual lane for early bridge wrappers, Ollama/vLLM prototypes, and special devices that are not yet safe to automate.
5. Run records, observability, artifacts, and Explorer-ingested evidence close the loop.

The architectural rule is simple: **produc

Feedback 318

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:49:59.713564+00:00

ts ask; UAPI admits and routes; backend schedulers allocate; GPU Cloud executes; Explorer records what is true.**

How to read this proposal

• Operators and product owners: read the executive thesis, decision packet, invariants, roadmap, gate matrix, and risk register first.
• Implementers: read UAPI redesign, smart routing, device registry, schemas, adapter contract, and runbooks.
• Explorer/catalog maintainers: read the invariants, source-of-truth assumptions, evidence model, Explorer export rules, and feedback section.
• Reviewers comparing agent replies: use the decision packet, product integration matrix, backend primitive map, and risk register as the comparable core.

Decision packet

Recommended architecture

Adopt a scheduler-neutral UAPI/GPU Cloud control plane:

• UAPI owns product-facing contracts, policy admission, routing decisions, scoped approvals, run ledger pointers, and safe status surfaces.
• UAI GPU Cloud owns runtime execution through backend adapters and reconciles actual capacity from schedulers, devices, cloud providers, and telemetry.
• Backend schedulers own final allocation within their domains: Kubernetes, Kueue, Ray, Slurm, Nomad, Proxmox, direct host wrappers, or cloud provider APIs.
• Explorer owns sanitized truth: current docs, rules, runbook packets, approved evidence, feedback, catalog lineage, and redaction state.

Explicitly out of scope for this proposal

• No production deployment.
• No device onboarding.
• No cluster joins.
• No driver installs.
• No GPU Operator or device plugin installation.
• No cloud account provisioning.
• No public DNS, TLS, firewall, reverse proxy, NetBird, route, or exposure changes.
• No direct use of MacBook, NUC, Zenbook, Proxmox, Cortex, Beacon, Mesh, Cadence, cloud GPU hosts, or lab devices as local surfaces.
• No secret persistence in docs, prompts, logs, run records, or Explorer packets.

First approved milestone

The safest first milestone is Gate 0 plus Phase 1:

1. Keep the work plan-only and read-only.
2. Catalog this proposal and its review packet into Explorer through the approved documentation flow.
3. Create schema-only drafts for Device, WorkloadRequest, RoutingPolicy, ApprovalRecord, PlacementDecision, RunRecord, Artifact, and EvidencePacket.
4. Produce a read-only device survey template.
5. Produce a fixture-only policy simulator with fake devices, fake requests, expected accepts/denies, backend choices, and reason codes.

Do not start Kubernetes, Slurm, Nomad, Proxmox, cloud, or local inference implementation until Gate 0 and Phase 1 review artifacts are accepted.

Approval needed next

• Product boundary approval: confirm Cadence, Command Center, Explorer, UAPI, GPU Cloud, Mesh, Beacon, and Cortex ownership.
• Data-class approval: confirm the first UAI data classification ladder and which classes are allowed on local, sandbox, and cloud lanes.
• Device survey approval: authorize read-only inventory only.
• UAPI MVP approval: authorize schema and fixture work only.
• Explorer catalog approval: decide where this proposal and later evidence packets live.

Top five risks to watch first

Feedback 319

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:49:59.745193+00:00

frastructure authority | Cadence requests; Command Center approves; UAPI enforces | | Client-declared data class is trusted | Products could accidentally lower sensitivity | Server-side classification resolver; unknown denies | | Registry drift | Stale capacity can double-schedule or route unsafe work | Reconciler projections and freshness gates | | Cloud burst cost/data egress | Spend and private data can escape quickly | TTL, budget, data-class, egress, approval gates | | Evidence is not tamper-evident | Audits become intent-only | Hash-chain/signed snapshots, immutable artifact references |

Non-negotiable invariants

• Explorer records truth; it does not execute compute. A separately approved explorer-indexing client may request indexing work through UAPI later, but Explorer itself remains documentation, context, redaction, lineage, and approved evidence.
• UAPI admits and routes; it does not pretend to be the backend scheduler. Kubernetes, Kueue, Ray, Slurm, Nomad, Proxmox, direct wrappers, and cloud providers keep their allocation semantics. UAPI normalizes contracts, policy, run records, and evidence.
• GPU Cloud executes through adapters; it does not own product authority. Runtime lanes must honor UAPI decisions and emit run evidence.
• Command Center approves operational gates. Cadence can request, explain, and display workflow context, but Command Center or an operator approval artifact is the gate owner for survey, sandbox, internal compute, cloud burst, policy changes, and public exposure.
• No client can lower sensitivity. Callers may assert or raise data sensitivity, but server-side classification from artifact refs, model refs, product identity, Explorer policy, and content scanning is authoritative. Unknown classification denies.
• No unsurveyed or stale device is schedulable. Candidate devices remain read-only inventory entries until explicitly approved.
• No public exposure mutation is part of compute routing. Public exposure remains a separate operator-approved runbook.
• No raw secrets are persisted. Secrets belong in a secret store with short-lived injection, rotation, scanning, and quarantine before any Explorer export.
• Every accepted run has a run record first. Every denied request has a safe denial record with reason codes.
• Every phase is blocked by default. The next phase starts only after Explorer catalogs the review packet and the correct scoped approval artifact exists.

Terminology and authority ladder

Terms

Feedback 320

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:49:59.775246+00:00

r| Backend-native allocator such as kube-scheduler, Kueue admission, Ray scheduler, Slurm, or Nomad | |runtime| The actual workload runtime such as vLLM, Ollama, Ray, container job, shell wrapper, or benchmark runner | |registry| Governed projection of device/capacity truth, reconciled from backend inventories and telemetry | |run ledger` | Append-only operational record of requests, decisions, submissions, events, artifacts, and evidence state |

Authority ladder

operator_approved is not a universal bypass. It must resolve to a scoped approval record.

Operator gate matrix

Each gate remains blocked until its review packet is cataloged in Explorer and a scoped approval record exists. Approval records must include signer, scope, expiry, runbook or evidence reference, rollback/abort criteria, and revocation state.

Feedback 321

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:49:59.810092+00:00

ion only | product_integration approval | Per-product contract matrix and acceptance evidence | Product bypasses UAPI or mutates forbidden surfaces | | Gate 7 - cloud burst | Use leased GPU capacity | Cloud resources within TTL/budget only | cloud_burst approval | Cost, TTL, egress, artifact, teardown evidence | Budget/TTL missing, data class disallowed, egress violation | | Gate 8 - public exposure | Any public route/DNS/TLS/firewall/reverse proxy/NetBird change | Exposure-specific only | Separate public_exposure runbook approval | Public-safe exposure review packet | Any readiness/public-safe gate fails |

Assumptions and context gaps

Confirmed context from UAI Explorer

Explorer AI-lane bootstrap and all required primary-context slugs were fetched successfully on 2026-06-21 in this Thinktank sandbox run. The API key was kept in process memory only and was not written to disk. The sanitized capture is recorded in [REDACTED:high-entropy].md and .[REDACTED:high-entropy].json. The returned UAI context establishes these planning constraints:

• UAI Explorer is the public-safe documentation and context portal for UAI material.
• Production UAI Explorer is a governed internal production service; sandbox remains the staging and verification lane.
• AI agents must use /ready, /api/ai/bootstrap, and /api/ai/context/{slug} for UAI context.
• AI agents must not use admin, raw file, upload, SQLite, device filesystem, public exposure, .env, .ssh, or raw survey surfaces unless explicitly authorized by a separate operator-approved runbook.
• Human UX and AI context APIs stay separate.
• Important docs, plans, runbooks, evidence, active project briefs, device surveys, and operator decisions should be cataloged into Explorer instead of remaining local-only.
• Public-safe mode requires allowlisted catalog access, server-side redaction, audit logging, disabled raw downloads, and disabled legacy file/upload APIs.
• External exposure changes require separate approval.

Local repository context used carefully

The local workspace contains historical UAI and Cadence documents. Those are useful for contrast but not more authoritative than Explorer. In particular:

• Older Cadence v5 GPU/lab docs reserve some devices for special lanes and frame the NUC as an execution bridge, but the current redesign should not make Cadence own device scheduling.
• A local UAI lab runbook says older Mac-root docs may be stale and should not be treated as live truth.
• GitNexus symbol impact analysis was not applicable to this Thinktank sandbox update because this task created documentation artifacts only and did not edit functions, classes, methods, or existing project code symbols.

Planning assumptions

• This is a design proposal, not an implementation authorization.
• All device names, GPU availability, IPs, service ports, and current host roles are treated as time-sensitive and must be re-verified before implementation.
• MacBook, NUC, Zenbook, Proxmox, Cortex, Beacon, Mesh, Cadence, cloud GPU hosts, and lab devices are not local surfaces for this agent.
• UAI wants an internal lab product that can grow from manual devices to mixed local/cloud capacity.
• UAI wants future hardware

Feedback 322

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:49:59.841860+00:00

such as Intel Arc Pro B70 to be first-class in the data model even before it is operationally proven. - UAI wants priority lanes and smart routing, not a single FIFO queue. - UAPI exists conceptually as an internal bridge/gateway, but no current product-specific UAPI Bridge spec was returned by Explorer context.

Context gaps that must be closed before build

1. Live inventory gap: There is no fresh, approved device inventory in this task packet. GPU model, VRAM, driver versions, OS, PCIe topology, power, thermal, network, storage, owner, and trust state must be surveyed.
2. UAPI surface gap: Current UAPI routes, auth model, consumers, and expected compatibility contracts were not provided by Explorer.
3. Scheduler authority gap: It is not yet decided whether Kubernetes, Slurm, Nomad, or a phased hybrid should be the first real executor.
4. Cloud provider gap: Cloud GPU vendor, budget limits, region, identity model, secrets path, and egress constraints are unknown.
5. Data classification gap: The lab needs explicit rules for public-safe, private, customer, code, model weights, dataset, and secret-bearing workloads.
6. Device trust gap: Existing GPUs may have special reservations. Example: historical Cadence notes reserve one GPU lane for Cortex-only workloads. This must be confirmed, superseded, or encoded.
7. Intel GPU maturity gap: Intel GPU plugin and driver support exists, but Arc Pro B70 production behavior for the exact UAI workloads must be validated before relying on it.
8. Cost/accounting gap: Cloud GPU burst will fail culturally if every product can spend without quota, owner, TTL, and audit.

Current-state diagnosis

The UAI lab appears to be at the classic transition point between "smart people manually using available machines" and "an internal platform with routable capacity." The problem is not simply that there are more GPUs. The problem is that authority, scheduling, evidence, and product responsibilities are not yet separated cleanly enough.

What works conceptually

• UAI Explorer now provides a good source-of-truth pattern: bounded AI context, redaction, catalog lineage, public-safe access, runbooks, and feedback.
• UAI already thinks in products: Cadence, Cortex, Beacon, Mesh, Explorer, Command Center, UAPI, and GPU Cloud can have separate roles.
• Existing lab docs already recognize special device roles and product-specific reservations.
• The user has already pushed the design in the right direction: Cadence should request work, not own infrastructure scheduling.

What does not scale

• Manual device selection: Humans or agents deciding "use this machine" does not scale when GPUs differ by vendor, VRAM, driver, locality, data clearance, power state, and current reservations.
• Cadence-as-scheduler pressure: Cadence naturally becomes the place where work originates, but that does not mean it should own capacity state, driver compatibility, cloud costs, or placement rules.
• Weak audit chain: Without run records, decisions are hard to reconstruct: why this device, what policy allowed it, what data was mounted, what artifacts were produced, and whether the result is safe to reuse.
• Mixed hardware friction: NVIDIA CUDA, Intel oneAPI/SYCL, Apple Silicon, CPU-o

Feedback 323

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:49:59.875875+00:00

nly hosts, Proxmox VMs, bare-metal Linux, and cloud GPU workers need different runtime paths. - Long-lived services versus batch jobs: vLLM-style inference, Ollama local serving, embeddings, Ray distributed jobs, tests, image generation, and one-off agent jobs should not all use the same queue semantics. - Cloud burst without governance: Leasing GPU capacity is easy to start and easy to lose control of. TTL, budget, quotas, owner approval, and egress policy must be built into the first API contract. - Local-only docs: The target proposal must be catalogable into Explorer so it becomes part of UAI memory instead of another loose file.

Key diagnosis

UAI needs a scheduler-neutral internal compute control plane. The first milestone should not be "install Kubernetes everywhere." The first milestone should be a typed request, typed policy, typed device registry, and typed run record that can target a manual lane on day one and a Kubernetes/Slurm/cloud lane later.

Future-state architecture

Core layers

1. Source of truth layer - UAI Explorer. - Holds current rules, docs, device survey summaries, runbooks, policy narratives, migration evidence, public-safe packets, and agent feedback. - Ingests sanitized run records and architecture decisions.

2. Product/request layer - Cadence, Cortex, Beacon, Mesh, Explorer, Command Center, Devine/design products, and future agents. - Products submit typed requests to UAPI. They do not SSH into hosts, select GPUs directly, modify Proxmox, or manage cloud nodes.

3. UAPI Bridge layer - Authenticates products and service accounts. - Validates workload requests. - Applies authority, data class, safety, budget, and priority policy. - Resolves model and artifact references. - Creates run records. - Routes to backend adapters. - Provides status, logs, artifacts, metrics, and cancellation.

4. Control-plane services - Device Registry. - Routing Policy Engine. - Quota and Budget Manager. - Artifact and Model Resolver. - Run Ledger / Audit Store. - Scheduler Adapter Manager. - Observability Collector.

5. Execution backends - Kubernetes GPU island. - Ray/KubeRay lane. - Slurm lane. - Nomad lane. - Proxmox VM/LXC lane. - Direct host/manual runner lane. - Cloud GPU burst lane.

6. Serving and ML platform layer - vLLM for high-throughput OpenAI-compatible inference serving. - Ollama for simple local model serving and developer/local-host prototypes. - LiteLLM as a model/API gateway above serving backends, not as a hardware scheduler. - MLflow for experiments, run metadata, model registry, and artifact lineage. - MinIO/S3 or Ceph/Rook for artifact, dataset, checkpoint, and model object storage.

7. Observability and evidence layer - OpenTelemetry Collector for traces, logs, and metrics pipeline. - Prometheus for metrics. - DCGM Exporter for NVIDIA GPU metrics. - Intel GPU metrics exporter or node-specific telemetry for Intel devices. - Grafana or Command Center for dashboards. - Explorer-ingested evidence packets for approved summaries.

Recommended backend positioning

Feedback 324

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:49:59.908530+00:00

e | Containerized services, inference serving, repeatable jobs, quota-managed batch with Kueue, gang jobs with Volcano, Ray clusters with KubeRay, cloud GPU node pools | Device inventory source of truth, Proxmox lifecycle, every weird one-off host | | Kueue | Admission control, queues, quotas, cohorts, fair sharing for Kubernetes batch workloads | Low-level GPU driver management or non-Kubernetes hosts | | Volcano | Gang scheduling, pod groups, AI/HPC batch jobs needing co-scheduling | General product API gateway | | KubeRay | Distributed Ray jobs, Ray Serve, elastic worker pools inside Kubernetes | Whole-lab device registry or non-Ray workloads | | Slurm | Bare-metal GPU partitions, HPC-style jobs, reservations, GRES accounting, predictable batch | Public/internal API surface for UAI products | | Nomad | Small heterogeneous clusters, simple binary/container scheduling, transitional lab hosts | Deep Kubernetes-native ML platform patterns | | Proxmox | VM/LXC lifecycle, sandbox segmentation, static PCI/GPU passthrough, rollback, snapshots | Fine-grained dynamic GPU scheduling | | Direct host/manual lane | First MVP, fragile/special devices, wrappers around existing Ollama/vLLM, repair work | Long-term scale or invisible manual routing | | Cloud GPU providers | Burst capacity, large experiments, temporary high-memory GPUs, redundancy | Ungoverned spending or secret-bearing jobs without egress policy |

UAPI lane to backend primitive map

UAPI should route at the UAI policy level, then translate to backend-native primitives through adapters. This keeps the product API stable while avoiding the false idea that every scheduler has identical semantics.

Feedback 325

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:49:59.934876+00:00

d direct host or approved internal lane | | sandbox | Separate namespace/cluster, low-trust policy, no secret mounts | Disposable Ray sandbox only | Separate test partition if used | Separate sandbox datacenter/client class | Proxmox sandbox VM/LXC, direct wrapper, no public route | | cloud-burst | MultiKueue or cloud node pool only after provider approval | Cloud Ray cluster only with TTL | Cloud Slurm only if explicitly chosen | Cloud Nomad only if explicitly chosen | Provisioning adapter creates capacity; scheduler adapter submits work | | maintenance | Cordoned node checks, device plugin/DCGM validation jobs | Not primary | Health/reservation checks | Client health checks | Proxmox inventory, firmware/driver surveys, benchmark probes |

Important corrections:

• Kueue manages quota, queueing, admission, fair sharing, and preemption for Kubernetes workloads. It does not replace Kubernetes scheduling.
• NVIDIA GPU Operator manages drivers, toolkit, device plugin, labels, monitoring, and GPU sharing/MIG integration. It is not the scheduler.
• KubeRay manages Ray clusters and jobs on Kubernetes. Ray still schedules tasks inside Ray.
• Slurm is strong for HPC-style partitions, GRES, reservations, and accounting; it is weaker for persistent product APIs, model-serving UX, and cloud-native artifact flows.
• Nomad should stay optional. It is useful only if UAI wants a lightweight heterogeneous lane and accepts the extra adapter surface.
• Proxmox GPU passthrough usually creates an exclusive reservation that removes that GPU from other schedulers.

Scheduler selection matrix

Adapter compliance contract

Every backend adapter must implement the same minimum contract before it can be enabled:

Feedback 326

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:49:59.961809+00:00

e satisfied | | logs | Return only redacted/product-authorized log views | | artifacts | Finalize output refs with checksums and retention policy | | metrics | Emit run labels, queue wait, runtime, GPU usage, cost where applicable | | ttl_teardown | Destroy cloud/manual/sandbox resources at TTL or completion | | orphan_cleanup | Detect backend work without active run records and quarantine before cleanup | | capability_probe | Report supported runtimes, accelerator types, sharing modes, and health |

Backend reconciler model

The Device Registry should be a governed projection, not the only live truth. A reconciler should compare registry records with:

• Kubernetes Nodes, device-plugin resources, DRA resources, labels, taints, and allocatable GPU resources.
• Kueue ClusterQueue, LocalQueue, ResourceFlavor, quota, and pending workload state.
• Ray/KubeRay RayCluster, RayJob, worker state, and autoscaling state.
• Slurm nodes, partitions, QoS, GRES, reservations, and job queues.
• Nomad clients, device resources, allocations, and constraints.
• Proxmox VM/LXC inventory, static passthrough assignments, snapshots, and power state.
• Cloud provider instances, volumes, security groups, spend, and TTL tags.
• Prometheus/DCGM/Intel telemetry and recent heartbeat data.

If reconciler data conflicts with the registry, UAPI should fail closed for new placements on that device/lane until the conflict is resolved or an incident approval exists.

Architecture decision

Adopt a hybrid executor model behind one UAPI contract. Build the first slice with:

• Device Registry.
• Workload Request schema.
• Routing Policy schema.
• Approval Record schema.
• Placement Decision schema.
• Run Record schema.
• Manual/direct adapter.
• One local inference adapter.
• One sandbox Kubernetes GPU lane only after device inventory and approval.

Then add Kueue, GPU Operator, DCGM exporter, vLLM, MLflow, and object storage as the first production-like GPU Cloud lane. KubeRay, Volcano, Slurm, Nomad, Proxmox, and cloud adapters should be added only when a specific workload and approval packet justify the extra surface.

Mermaid diagrams

Component architecture

flowchart TB
  subgraph Products["UAI Products"]
    Cadence["Cadence\nworkflow and operator UX"]
    Cortex["Cortex\nmemory and knowledge workloads"]
    Beacon["Beacon\nsignals, route state, notifications"]
    Mesh["Mesh\ncross-device/project coordination"]
    Explorer["UAI Explorer\nsource of truth and evidence"]
    Command["Command Center\nops dashboards and approvals"]
  end

  subgraph Bridge["UAPI Bridge"]
    Auth["AuthN/AuthZ\nservice accounts, tags, scopes"]
    Intake["Workload Intake\nschema validation, idempotency"]
    Policy["Policy Engine\npriority, data class, quota, safety"]
    Registry["Device Registry\ncapabilities, health, trust, reservations"]
    Router["Routing Broker\nlane and backend selection"]
    Ledger["Run Ledger\nstatus, audit, artifacts"]
  end

  subgraph Exec["UAI GPU Cloud Execution Plane"]
    K8s["Kubernetes GPU Lane\nKueue, Volcano, KubeRay"]
    Slurm["Slurm Lane\npartitions, GRES, reservations"]
    Nomad["Nomad Lane\nlight heterogeneous scheduling"]
    Proxmox["Proxmox Lane\nVM/LXC and static passthrough"]
    Direct["Di

### Feedback 327

- Product: `uai-gpu-cloud-uapi-bridge`
- Category: `beneficial`
- Related slug: ``
- Source: `uai-thinktank-production-test`
- Created at: `2026-06-23T18:49:59.990513+00:00`

rect Host Lane\nmanual/special wrappers"]
    Cloud["Cloud GPU Burst Lane\nleased nodes with TTL/budget"]
  end

  subgraph Platform["Platform Services"]
    Models["Model Gateway\nLiteLLM, vLLM, Ollama"]
    Store["Artifacts and Models\nMinIO/S3, Ceph/Rook, MLflow"]
    Obs["Observability\nOpenTelemetry, Prometheus, DCGM"]
    Gov["Governance\nOPA/Gatekeeper, secrets, SBOM, approvals"]
  end

  Cadence --> Intake
  Cortex --> Intake
  Beacon --> Intake
  Mesh --> Intake
  Command --> Intake
  Explorer --> Intake
  Intake --> Auth --> Policy
  Policy --> Registry
  Policy --> Router
  Router --> K8s
  Router --> Slurm
  Router --> Nomad
  Router --> Proxmox
  Router --> Direct
  Router --> Cloud
  K8s --> Models
  Slurm --> Store
  Nomad --> Store
  Proxmox --> Store
  Direct --> Models
  Cloud --> Store
  Models --> Ledger
  Store --> Ledger
  Exec --> Obs
  Ledger --> Explorer
  Ledger --> Command
  Gov --> Policy

Request lifecycle

sequenceDiagram
  autonumber
  participant Product as Product client
  participant UAPI as UAPI Bridge
  participant Policy as Policy Engine
  participant Registry as Device Registry
  participant Adapter as Scheduler Adapter
  participant Obs as Observability
  participant Explorer as UAI Explorer

  Product->>UAPI: POST /v1/workloads
  UAPI->>UAPI: Validate schema, idempotency, auth scope
  UAPI->>Policy: Classify authority, data class, lane, budget
  Policy->>Registry: Query devices, health, reservations, capabilities
  Registry-->>Policy: Eligible capacity set
  Policy-->>UAPI: Placement decision or deny/wait
  UAPI->>Adapter: Submit normalized backend job
  Adapter-->>UAPI: Backend handle and initial status
  UAPI->>Obs: Emit trace, metrics, event
  UAPI-->>Product: 202 Accepted with run_id
  Adapter->>UAPI: Status, logs, artifacts, result
  UAPI->>Explorer: Publish safe evidence packet after approval/catalog flow
  Product->>UAPI: GET /v1/runs/{run_id}
  UAPI-->>Product: Status, artifacts, audit summary

Routing lanes

flowchart LR
  Req["WorkloadRequest"] --> Classify["Classify\nproduct, authority, data_class,\nworkload_type, gpu_profile"]
  Classify --> Deny{"Allowed?"}
  Deny -- no --> Refusal["Refuse with policy reason\nand feedback path"]
  Deny -- yes --> Lane{"Lane"}
  Lane --> Interactive["interactive\nlow latency, small jobs"]
  Lane --> Inference["model-serving\nvLLM/Ollama/LiteLLM"]
  Lane --> Batch["batch\nKueue/Slurm/Nomad"]
  Lane --> Distributed["distributed\nRay/KubeRay/Volcano"]
  Lane --> Sandbox["sandbox\nProxmox/manual"]
  Lane --> CloudBurst["cloud-burst\nTTL and budget gated"]
  Interactive --> Ledger["Run ledger"]
  Inference --> Ledger
  Batch --> Ledger
  Distributed --> Ledger
  Sandbox --> Ledger
  CloudBurst --> Ledger

Device registry relationship model

erDiagram
  DEVICE ||--o{ ACCELERATOR : contains
  DEVICE ||--o{ NETWORK_INTERFACE : exposes
  DEVICE ||--o{ STORAGE_VOLUME : mounts
  DEVICE ||--o{ HEALTH_SAMPLE : reports
  DEVICE ||--o{ RESERVATION : blocks
  DEVICE ||--o{ RUN_RECORD : executes
  WORKLOAD_REQUEST ||--|| RUN_RECORD : creates
  ROUTING_POLICY ||--o{ RUN_RECORD : authorizes
  ARTIFACT ||--o{ RUN_RECORD : produced_by
  MODEL_REF ||--o{ WORKLOAD_REQUEST : requested_by

  DEVICE {
    string device_id


### Feedback 328

- Product: `uai-gpu-cloud-uapi-bridge`
- Category: `beneficial`
- Related slug: ``
- Source: `uai-thinktank-production-test`
- Created at: `2026-06-23T18:50:00.018487+00:00`

 string device_type
    string owner
    string locality
    string trust_tier
    string exposure_boundary
    string schedulable_state
  }

  ACCELERATOR {
    string accelerator_id
    string vendor
    string model
    int vram_gb
    string driver_stack
    string plugin_stack
  }

  WORKLOAD_REQUEST {
    string request_id
    string product
    string workload_type
    string authority
    string data_class
    string priority_lane
  }

  RUN_RECORD {
    string run_id
    string status
    string placement_backend
    string device_id
    string policy_decision_id
    string audit_state
  }

Heavy schema outlook

The heavy schema should be treated as a product asset, not an implementation afterthought. If UAI gets the schema right early, every later scheduler adapter becomes replaceable.

Contract rules

Every schema should declare:

• schema_version in uai.<schema>.vMAJOR.MINOR form.
• Required fields versus optional fields.
• Stable ID conventions: dev_, acc_, req_, route_, approve_, run_, artifact_, evidence_, policy_.
• Enum values and whether unknown values deny or degrade.
• Lifecycle state transitions.
• Redaction and public-safe view rules.
• Backward compatibility behavior.
• Owning service.
• Explorer export eligibility.
• Audit fields required at creation.

Versioning rule:

• Minor versions may add optional fields.
• Major versions may change semantics and require explicit migration.
• Unknown required fields or unknown enum values should fail closed unless a compatibility adapter is approved.

Schema families

1. Identity and authority - Product identity. - Service account. - Human operator. - Role/tag/scopes. - Approval record. - Data classification. - Scoped approval record.

2. Device and capacity - Physical device. - VM/container host. - Accelerator. - Driver stack. - Runtime stack. - Schedulable state. - Health/freshness. - Reservation. - Cost profile. - Power/thermal profile. - Reconciler source and freshness.

3. Workload - Request. - Placement candidates. - Policy decision. - Backend submission. - Run lifecycle. - Retry/cancel semantics. - Artifacts. - Evidence packet. - Preemption and checkpointing profile.

4. Model and data - Model reference. - Model serving profile. - Dataset reference. - Artifact policy. - Cache policy. - Retention policy. - Redaction/safety metadata. - Server-resolved classification.

5. Policy - Priority lane. - Quota. - Budget. - Preemption. - Affinity/anti-affinity. - Product reservation. - Cloud burst guardrail. - Public-safe boundary. - Approval scope and expiry.

6. Observability - Trace ID. - Metric references. - Log references. - GPU samples. - Queue wait. - Runtime. - Cost. - Artifact checksums. - Signed policy snapshot and runner image digest.

7. Explorer publication - Catalog candidate. - Redaction state. - Safe summary. - Required tags. - Lineage links. - Superseded/prior run relation. - Raw-content denial proof.

Schema maturity levels

Feedback 329

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:50:00.049113+00:00

write notes after the fact | | L1 | Typed request and run record | Products submit structured requests and receive run IDs | | L2 | Registry-aware routing | Router filters by capabilities, reservations, health, and trust | | L3 | Policy-aware admission | Priority lanes, quotas, data class, and budget gates drive decisions | | L4 | Multi-backend scheduling | Kubernetes, Ray, Slurm, Nomad, Proxmox, direct, and cloud adapters coexist | | L5 | Evidence-native platform | Safe run packets publish to Explorer and feed future AI contexts | | L6 | Self-service internal platform | Backstage-like catalog, golden paths, templates, SLOs, and automated guardrails |

Event-sourced option

For the run ledger and device state, prefer append-only events over silent mutable rows:

• device.registered
• device.surveyed
• device.health_reported
• device.reserved
• device.unreserved
• workload.requested
• workload.accepted
• workload.denied
• placement.decided
• backend.submitted
• run.started
• run.heartbeat
• run.succeeded
• run.failed
• run.canceled
• artifact.produced
• evidence.approved
• explorer.cataloged

Mutable projections can power dashboards, but the append-only stream preserves auditability.

Lifecycle examples

Device:

candidate -> surveyed -> approved_manual -> approved_scheduled
candidate -> surveyed -> rejected
approved_scheduled -> degraded -> maintenance -> approved_scheduled
approved_scheduled -> reserved -> approved_scheduled
approved_scheduled -> retired

Workload:

requested -> validated -> policy_denied
requested -> validated -> waitlisted -> admitted -> submitted -> running -> succeeded
requested -> validated -> admitted -> submitted -> running -> failed -> retry_wait -> submitted
requested -> validated -> admitted -> submitted -> running -> cancel_requested -> canceled

Evidence:

candidate -> quarantined -> redacted -> reviewed -> approved -> explorer_cataloged
candidate -> quarantined -> rejected_private

UAPI redesign

New UAPI mission

UAPI should become the internal API bridge for UAI products and lab services. It should not be just a route collection or thin proxy. It should be the place where product intent becomes governed compute action.

UAPI should expose:

• Workload intake.
• Model serving requests.
• Artifact lookup.
• Device registry reads.
• Run status and cancellation.
• Policy and quota summaries.
• Product-safe feedback/error details.
• Evidence export for Explorer ingestion.

UAPI should not expose:

• Generic SSH.
• Generic filesystem access.
• Raw host credentials.
• Direct Proxmox mutation without an approved adapter and runbook.
• Admin bypass routes.
• Public exposure mutation.
• Secret-bearing logs.

Server-side classification resolver

UAPI must not trust client-declared sensitivity as final. A product request may include a client assertion, but the authoritative class must be resolved server-side from:

• Product identity and service account scope.
• Artifact refs, dataset refs, model refs, and their Explorer/catalog metadata.
• Prior run lineage.
• Content or metadata scanning where allowed.
• Policy defaults for the requested lane.
• Operator approval records.

Classification rules:

• Clients may raise sensitivity b

Feedback 330

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:50:00.083444+00:00

ut never lower it. - Unknown artifact, model, dataset, or lineage class denies by default. - secrets_expected=true is not permission to handle secrets; it is a routing warning that requires protected handling or denial. - Classification decisions must be recorded in the placement decision and run record. - Product-visible errors should include safe reason codes, not raw paths, source snippets, or secret-bearing metadata.

Scoped approval records

operator_approved must resolve to a durable scoped approval record. It is not a blanket override.

schema_version: uai.approval_record.v0.1
approval_id: approve_20260621_000001
scope:
  action: cloud_burst | device_survey | device_approve | adapter_enable | policy_apply | sandbox_run | public_exposure
  product: cadence
  lane: cloud-burst
  devices:
    - dev_or_class_ref
  data_classes_allowed:
    - public_safe
    - internal
  max_cost_usd: 25.00
  ttl_seconds: 7200
  egress_profile: internal_allowlist_only
approver:
  kind: human_operator
  id_ref: operator_ref
  approved_at: "2026-06-21T00:00:00Z"
expires_at: "2026-06-21T02:00:00Z"
runbook_ref: explorer_slug_or_doc_ref
evidence_ref: evidence_...
rollback_plan_ref: rollback_...
revocation:
  revoked: false
  revoked_at: null
  reason: null
status: active

Separate approval scopes should exist for:

• Read-only survey.
• Device approval.
• Adapter enablement.
• Policy application.
• Sandbox workload.
• Internal compute workload.
• Cloud burst.
• Public exposure.

Public exposure must remain outside normal compute approvals.

UAPI service boundaries

Product-facing endpoints

Initial endpoint set:

GET  /v1/health
GET  /v1/ready
POST /v1/workloads
GET  /v1/workloads/{request_id}
GET  /v1/runs/{run_id}
POST /v1/runs/{run_id}/cancel
GET  /v1/devices
GET  /v1/devices/{device_id}
GET  /v1/policies/routing
GET  /v1/quotas/{product}
POST /v1/model/complete
POST /v1/model/embed
POST /v1/model/rerank
GET  /v1/artifacts/{artifact_id}
POST /v1/evidence/export

Operator-only, approval-gated endpoints should live under a separate surface:

POST /v1/operator/devices/register
POST /v1/operator/devices/{device_id}/survey
POST /v1/operator/policies/apply
POST /v1/operator/adapters/{adapter}/enable
POST /v1/operator/cloud-burst/approve

Product-facing device endpoints must use role-based views. GET /v1/devices should not reveal raw topology, owner details, hostname

Feedback 331

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:50:00.119989+00:00

s, private IPs, exact capacity, or reserved-lane details unless the caller has a matching operator/product scope. Public-safe or Explorer-facing device summaries should use pseudonymous IDs, field allowlists, freshness state, trust tier, and safe capability buckets.

API compatibility principle

Products should never care whether a run lands on:

• A local RTX GPU.
• A NUC-attached accelerator.
• A Proxmox VM with GPU passthrough.
• A Kubernetes GPU pod.
• A Ray worker group.
• A Slurm partition.
• A Nomad allocation.
• A leased cloud GPU.

Products should care about:

• What they asked for.
• What authority they had.
• What data class was involved.
• What priority lane was used.
• What run ID was issued.
• What result and artifact were produced.
• What evidence can be trusted.

Smart routing and priority lane design

Design goal

Routing should be deterministic enough to audit, but adaptive enough to handle changing device health, queue depth, cost, model availability, and product priority.

The router should produce an explicit PlacementDecision:

decision_id: route_20260621_000001
request_id: req_...
decision: accepted
selected_lane: model-serving
selected_backend: k8s-gpu
selected_device_class: nvidia.cuda.24gb
selected_runtime: vllm-openai-compatible
policy_version: routing-policy/v0.1
reasons:
  - product=cadence allowed lane=model-serving
  - gpu_profile requires vram_gb>=24
  - data_class=internal allowed on k8s-gpu-trust-tier-2
  - local queue wait below threshold
fallbacks:
  - direct-host-ollama
  - cloud-burst-a10g
denied_candidates:
  - device=rtx2070 reason=reserved_for_cortex
  - backend=cloud-burst reason=budget_not_needed

Priority lanes

Routing inputs

• Product: cadence, cortex, beacon, mesh, explorer, command-center, devine, uapi, other.
• Authority: plan_only, read_only, sandbox_allowed, internal_compute_allowed, cloud_burst_allowed, `operator_app

Feedback 332

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:50:00.148900+00:00

roved. - Data class:public_safe,internal,private,secret_bearing,customer,model_weights,dataset_sensitive. - Workload type:llm_inference,embedding,image_generation,batch_eval,training,ray_job,shell_task,build_test,video,vision,maintenance_probe. - GPU profile: vendor, VRAM, CUDA/ROCm/oneAPI/SYCL, quantization, model family, driver. - Runtime:vllm,ollama,litellm_proxy,ray,container,slurm,nomad,manual`. - Queue and priority lane. - Cost ceiling. - TTL. - Artifact policy. - Observability requirements.

Routing algorithm MVP

1. Validate request and auth scope.
2. Normalize product and workload type.
3. Reject incompatible authority/data-class combinations.
4. Load routing policy version.
5. Filter devices by trust tier, exposure boundary, health, reservation, and schedulable state.
6. Filter devices by accelerator profile, runtime compatibility, model availability, storage locality, and network.
7. Score remaining candidates: - hard constraints first, - priority lane, - queue wait, - locality, - cost, - energy/thermal state, - reliability, - freshness, - product reservation.
8. Select backend adapter and create run record.
9. Return run ID and decision reasons.
10. Emit metrics and trace events.

Routing maturity

Device registry design

Device registry purpose

The registry is not just a CMDB. It is the system that lets UAPI answer:

• What exists?
• What is trusted?
• What can run which workload?
• What is reserved?
• What is healthy now?
• What is safe to expose to which product?
• What is stale and needs a survey?
• What did this run actually use?

Device types

• physical_host
• proxmox_host
• proxmox_vm
• proxmox_lxc
• workstation
• nuc
• mac
• cloud_instance
• gpu
• accelerator
• storage_node
• network_service
• model_endpoint
• manual_lane

Registry record example

schema_version: uai.device.v0.1
device_id: dev_nuc140t_001
display_name: NUC 140T candidate
device_type: nuc
owner: lab
status:
  schedulable_state: unknown
  lifecycle: candidate
  last_surveyed_at: null
  freshness: stale_or_unverified
authority:
  mutation_allowed: false
  requires_operator_approval: true
  exposure_boundary: internal_only
  allowed_products: []
trust:
  trust_tier: unverified
  data_classes_allowed:
    - public_safe
  denied_data_classes:
    - secret_bearing
    - customer
locality:
  site: uai_lab
  network_zone: unknown
  storage_zone: unknown
accelerators:
  - accelerator_id: acc_nuc140t_integrated_or_attached_001
    vendor: unknown
    model: unknown
    vram_gb: null
    api_stacks: []
    driver:
      os: unknown
      version: unknown
    plugin_support:
      kubernetes_device_plugin: unknown
      slurm_gres: unknown
      nomad_device: unknown
capabilities:
  cpu:
    cores: null
    arch: unknown
  memory_gb: null
  storage:
    local_nvme_gb: 

### Feedback 333

- Product: `uai-gpu-cloud-uapi-bridge`
- Category: `beneficial`
- Related slug: ``
- Source: `uai-thinktank-production-test`
- Created at: `2026-06-23T18:50:00.180125+00:00`

null
  network:
    lan_gbps: null
reservations: []
observability:
  metrics_endpoint: null
  dcgm_available: false
  otel_agent: false
notes:
  - "Candidate record only. Do not route workloads until surveyed and approved."

Accelerator capability model

accelerator:
  vendor: nvidia | intel | amd | apple | cpu | unknown
  model: "RTX 3060" | "RTX 2070" | "Arc Pro B70" | "A100" | "other"
  vram_gb: 8
  memory_bandwidth_gbps: null
  compute_api:
    cuda: true
    rocm: false
    oneapi_level_zero: false
    sycl: false
    metal: false
    vulkan: false
  supported_runtimes:
    - vllm
    - ollama
    - llama_cpp
    - pytorch
  scheduler_support:
    kubernetes_device_plugin: true
    kueue_resource_flavor: true
    volcano: true
    slurm_gres: true
    nomad_device: unknown
  sharing:
    mig: false
    time_slicing: possible
    mps: possible
    memory_isolation: none | process | mig_partition | vm_boundary | unknown
    fault_isolation: none | process | mig_partition | vm_boundary | unknown
    oversubscription_factor: 1
    allowed_data_classes_when_shared:
      - public_safe
      - internal
  benchmark_refs:
    - bench_...
  constraints:
    - no_customer_data
    - no_cloud_egress

GPU sharing policy

GPU sharing must be explicit, not inferred from driver support.

Rules:

• time_slicing may improve utilization, but it does not by itself provide strong memory or fault isolation.
• MIG-like partitioning can provide stronger isolation where the hardware and driver support it, but it still needs policy, monitoring, and benchmark validation.
• MPS/time-slicing should be denied for private, customer, secret-bearing, or unknown data unless an approved isolation profile exists.
• Shared GPUs require allowed_data_classes_when_shared, oversubscription_factor, memory_isolation, fault_isolation, and product quota fields.
• Sensitive workloads should prefer exclusive devices, VM boundaries, or trusted dedicated lanes.
• A device with unknown sharing semantics is treated as exclusive or unschedulable.

Preemption and checkpointing policy

Preemption is unsafe unless the workload declares how it can recover.

Required fields for any preemptible workload:

• preemptible: true
• checkpoint_ref or explicit checkpoint_not_supported_reason
• grace_period_seconds
• requeue_policy
• max_tolerated_loss_seconds
• artifact_finalization_behavior
• cleanup_policy

Default behavior is non-preemptible. Operator incident lanes may interrupt work only inside the scoped approval and must record the lost work, affected artifacts, and requeue decision.

Device states

Device survey minimum

• Hostname and stable device ID.
• Owner and operator contact.
• Physical/locality label.
• OS and kernel.
• CPU, RAM, local storage.
• G

Feedback 334

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:50:00.210008+00:00

PU vendor, model, VRAM, PCIe location, driver. - NVIDIA CUDA/driver, Intel Level Zero/oneAPI/SYCL, ROCm, Metal, Vulkan as applicable. - Container runtime and GPU runtime. - Kubernetes/Slurm/Nomad/Proxmox compatibility. - Network zone and speed. - Storage mounts and artifact cache behavior. - Power/thermal constraints. - Security posture. - Observability endpoints. - Benchmark baseline. - Reserved lanes. - Approval state.

Workload request schema

Minimum product-facing schema

schema_version: uai.workload_request.v0.1
request_id: req_20260621_000001
idempotency_key: product-generated-stable-key
submitted_at: "2026-06-21T00:00:00Z"
product: cadence
requester:
  kind: service_account
  id: cadence-worker
  human_operator: optional-operator-id
authority: internal_compute_allowed
workload:
  type: llm_inference
  intent: "run planning model for architecture synthesis"
  command_ref: null
  image_ref: null
  model_ref:
    provider: internal
    family: qwen-or-llama-or-other
    model: model-name
    quantization: optional
  runtime:
    preferred: vllm
    acceptable:
      - vllm
      - ollama
      - cloud_openai_compatible
resources:
  gpu_profile:
    vendor_preference:
      - nvidia
      - intel
    min_vram_gb: 16
    count: 1
    allow_shared_gpu: true
  cpu_cores: 4
  memory_gb: 32
  local_disk_gb: 100
data:
  client_asserted_data_class: internal
  server_resolved_data_class: null
  classification_required: true
  input_refs:
    - artifact_id: artifact_...
      declared_class: internal
      server_class_required: true
  output_policy:
    artifact_store: uai-s3
    retention: 30d
    explorer_summary_allowed: true
priority:
  lane: interactive
  priority_class: normal
  deadline_at: null
  ttl_seconds: 3600
preemption:
  preemptible: false
  checkpoint_ref: null
  grace_period_seconds: 0
  requeue_policy: never
  max_tolerated_loss_seconds: 0
cost:
  max_usd: 5.00
  cloud_burst_allowed: false
network:
  allow_internet_egress: false
  allowed_internal_services:
    - uai-explorer
    - mlflow
observability:
  trace_required: true
  metrics_required: true
  log_redaction: required
safety:
  public_safe_required: false
  secrets_expected: false
  require_operator_approval: false
labels:
  project: uai-gpu-cloud
  purpose: planning

Request validation rules

• authority=plan_only cannot create an execution run.
• data_class=secret_bearing requires explicit approval and a protected lane.
• Server-resolved data class is authoritative; client assertions may raise sensitivity but never lower it.
• Unknown input, model, dataset, artifact, or lineage classification denies by default.
• cloud_burst_allowed=true requires budget, TTL, provider policy, and egress policy.
• public_safe_required=true must use redaction and Explorer-safe evidence export.
• Requests with no TTL should be refused unless they target a known persistent service profile.
• Products cannot request specific devices unless policy grants affinity rights.
• The router may accept a GPU profile, but direct device selection should be operator-gated.
• Preemption is allowed only when the request declares preemptibility, checkpoint behavior, grace period, requeue policy, and tolerated loss.

Routing policy schema

Policy example

sch

### Feedback 335

- Product: `uai-gpu-cloud-uapi-bridge`
- Category: `beneficial`
- Related slug: ``
- Source: `uai-thinktank-production-test`
- Created at: `2026-06-23T18:50:00.240675+00:00`

ema_version: uai.routing_policy.v0.1
policy_id: routing_policy_default_20260621
status: draft
applies_to:
  products:
    - cadence
    - cortex
    - beacon
    - mesh
    - explorer
    - command-center
defaults:
  deny_by_default: true
  require_run_record: true
  require_trace: true
  require_ttl: true
  require_server_classification: true
  [REDACTED:high-entropy]: true
lanes:
  - name: operator-incident
    allowed_authority:
      - operator_approved
    max_queue_wait_seconds: 60
    preemption: approval_required
    backends:
      - direct-host
      - sandbox-proxmox
  - name: interactive
    allowed_authority:
      - internal_compute_allowed
      - operator_approved
    max_runtime_seconds: 7200
    backends:
      - k8s-gpu
      - direct-host
      - cloud-burst
  - name: cortex-memory
    allowed_products:
      - cortex
    reservations:
      - reservation_cortex_gpu_lane
    backends:
      - direct-host
      - k8s-gpu
  - name: cloud-burst
    allowed_authority:
      - cloud_burst_allowed
      - operator_approved
    require_budget: true
    require_ttl: true
    require_egress_policy: true
scoring:
  weights:
    hard_constraints: 1000
    product_reservation: 200
    low_queue_wait: 100
    locality: 80
    cost: 70
    reliability: 70
    energy_thermal: 20
denials:
  [REDACTED:high-entropy]: true
  deny_unsurveyed_devices: true
  [REDACTED:high-entropy]: true
  deny_public_exposure_mutation: true
  deny_unknown_data_class: true
  [REDACTED:high-entropy]: true
fallbacks:
  max_fallbacks: 3
  require_reason_codes: true

Policy decision outputs

Every policy decision should record:

• Policy version.
• Request ID.
• Product.
• Allowed/denied/waitlisted.
• Candidate devices.
• Denied candidates with reason codes.
• Selected lane.
• Selected backend.
• Selected runtime.
• Human approval reference if required.
• Scoped approval record and expiry if required.
• Server-side data classification result.
• Cost estimate.
• TTL.
• Required observability.
• Explorer evidence eligibility.
• Backend primitive mapping used for the adapter.

Run record / audit schema

Run record example

schema_version: uai.run_record.v0.1
run_id: run_20260621_000001
request_id: req_20260621_000001
created_at: "2026-06-21T00:00:00Z"
updated_at: "2026-06-21T00:10:00Z"
status: succeeded
product: cadence
authority: internal_compute_allowed
data_class: internal
policy:
  policy_id: routing_policy_default_20260621
  decision_id: route_20260621_000001
  decision: accepted
  policy_snapshot_hash: sha256...
  approval_ref: null
classification:
  client_asserted_data_class: internal
  server_resolved_data_class: internal
  classification_sources:
    - product_identity
    - artifact_metadata
    - routing_policy
placement:
  lane: interactive
  backend: k8s-gpu
  backend_namespace: uai-gpu-interactive
  backend_handle: k8s-job-or-service-id
  device_ids:
    - dev_gpuworker_001
  accelerators:
    - acc_nvidia_001
runtime:
  runtime_type: vllm
  image_ref: registry/uai/vllm-runner:sha256...
  runner_image_digest: sha256...
  sbom_ref: artifact_sbom_...
  model_ref: model_...
  started_at: "2026-06-21T00:01:00Z"
  finished_at: "2026-06-21T00:09:0

### Feedback 336

- Product: `uai-gpu-cloud-uapi-bridge`
- Category: `beneficial`
- Related slug: ``
- Source: `uai-thinktank-production-test`
- Created at: `2026-06-23T18:50:00.269250+00:00`

0Z"
preemption:
  preemptible: false
  checkpoint_ref: null
  requeue_policy: never
metrics:
  queue_wait_seconds: 30
  runtime_seconds: 480
  gpu_seconds: 480
  peak_vram_gb: 17.4
  cost_usd_estimate: 0.00
observability:
  trace_id: trace_...
  prometheus_labels:
    run_id: run_20260621_000001
  log_ref: logs/run_20260621_000001
artifacts:
  - artifact_id: artifact_input_snapshot_...
    kind: input_manifest
    uri: s3://[REDACTED:high-entropy].json
    sha256: sha256...
  - artifact_id: artifact_...
    kind: output
    uri: s3://[REDACTED:high-entropy].json
    sha256: sha256...
audit:
  created_by: cadence-worker
  approval_ref: null
  redaction_state: summary_safe
  explorer_export_state: candidate
  deny_or_warning_codes: []
  actor_chain:
    - cadence-worker
    - uapi-router
    - k8s-gpu-adapter
tamper_evidence:
  previous_event_hash: sha256...
  event_hash: sha256...
  immutable_storage_ref: worm-or-object-lock-ref
  signature_ref: optional-signature-ref
lineage:
  supersedes: []
  related_runs: []

Audit requirements

• Every accepted workload creates a run record before backend submission.
• Denied requests create a denial record with safe reason codes.
• Logs are redacted before product-facing retrieval.
• Artifact references include hashes.
• Operator approvals are referenced by ID, not pasted secrets.
• Cloud runs include provider, instance type, region, TTL, and estimated cost.
• Device records include the exact accelerator used, not just the host.
• Explorer export uses a safe summary and redaction state.
• Policy snapshots, runner image digests, SBOM refs, input manifests, output refs, and event hashes are recorded for tamper-evident audit.
• Explorer receives only approved summaries and safe pointers, never raw logs, raw artifacts, raw topology, or secret-bearing metadata.

Product integration map

Ownership contract matrix

Feedback 337

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:50:00.296228+00:00

oute/DNS/firewall/reverse proxy/NetBird mutation from compute events | Event subscription or /v1/runs/{run_id} safe view | Notification/evidence cards | | Mesh | Service topology, readiness dependencies, cross-product coordination | Run health, service dependency status, safe capacity class | Compute requests for Mesh-owned workloads and readiness checks | Device/capacity registry ownership, placement decisions | /v1/workloads, /v1/runs/{run_id} | Readiness and migration gate summaries | | Explorer | Source-of-truth docs, AI context, redacted evidence, feedback | Safe run/evidence exports and proposal artifacts | Catalog/evidence ingestion through approved docs flow; possible future explorer-indexing client only if approved | Execution, raw files, raw logs, secrets, run ledger replacement | /v1/evidence/export consumer, not normal executor | Canonical approved plans, runbooks, evidence | | UAPI Bridge | Contracts, admission, policy, routing, run ledger pointers | Registry projections, backend status, product identity | Placement decisions, run records, safe status surfaces | Backend-native allocation, raw product UX ownership | All /v1/* product/control APIs | API decisions and policy snapshots | | UAI GPU Cloud | Runtime lanes, adapters, execution, teardown, telemetry | Placement decisions, registry projections, policy constraints | Backend submissions, metrics, artifact finalization | Product authority, docs truth, approval UX | Adapter contract behind UAPI | Runtime evidence summaries |

Event publication contract

Beacon, Cadence, Mesh, and Command Center may publish or display only safe event classes:

No event may mutate public/private route state, DNS, TLS, firewall, reverse proxy, NetBird, or service exposure.

Cadence

Cadence is the workflow and operator experience. It should:

• Submit work to UAPI using typed workload requests.
• Show queue/run status, evidence summaries, and suggested next actions.
• Ask Command Center or the operator approval workflow for approvals when a lane requires operator confirmation.
• Display routing reasons in operator language.

Cadence should not:

• Own the device registry.
• SSH into hosts for scheduling.
• Select GPUs directly except through approved affinity fields.
• Manage Proxmox/cloud/Kubernetes credentials.
• Mutate public exposure or lab networks.

Cortex

Cortex is the memory, knowledge, retrieval, embedding, and product-intelligence lane. It should:

• Request embedding/indexing jobs.
• Request mo

Feedback 338

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:50:00.325230+00:00

del inference and evaluation jobs. - Use protected data-class and retention rules. - Keep special GPU reservations explicit if they are still valid.

Cortex should not:

• Treat old reserved GPU assumptions as permanent unless the registry says so.
• Bypass UAPI to reach GPU hosts.

Beacon

Beacon is a signal, route-awareness, monitoring, notification, and public/private surface coordination product. It should:

• Read UAPI run status for notifications.
• Surface approved safe status cards.
• Integrate with incident and public-review evidence.

Beacon should not:

• Become the GPU routing plane.
• Change routes, DNS, firewall, reverse proxy, or NetBird from GPU Cloud runs.

Mesh

Mesh coordinates cross-device/project service relationships. It should:

• Use UAPI to request compute or model-serving endpoints.
• Own service topology/readiness dependencies, while UAPI owns placement, device registry, runs, and policy.
• Consume run/audit summaries for migration and service-readiness gates.

Mesh should not:

• Treat every device as equivalent.
• Collapse product orchestration and hardware scheduling into one layer.

UAI Explorer

Explorer is the source-of-truth and evidence layer. It should:

• Catalog current GPU Cloud/UAPI architecture, runbooks, device survey summaries, and approval packets.
• Provide AI-visible context packets for future agents.
• Store public-safe summaries and redacted evidence.
• Receive optional agent feedback when context is missing or stale.
• Request future indexing work only through a separately approved explorer-indexing product identity, not as implicit Explorer execution authority.

Explorer should not:

• Execute workloads.
• Expose raw device files.
• Store secrets in docs.
• Replace the run ledger for operational status.

Command Center

Command Center should be the operational dashboard:

• Capacity overview.
• Queue health.
• Incident lane.
• Approvals.
• Budget state.
• Device freshness.
• SLO/SLA indicators.

It should consume UAPI and Explorer. It should not become a hidden scheduler.

UAPI Bridge

UAPI is the internal bridge:

• Product API.
• Policy enforcement.
• Routing decision.
• Run ledger.
• Adapter abstraction.
• Evidence export.

UAI GPU Cloud

UAI GPU Cloud is the compute product:

• Local and cloud GPU capacity.
• Schedulers and adapters.
• Runtime workers.
• Model serving.
• Artifact pipelines.
• Observability.

It should feel like an internal cloud even before it has a large cluster.

Storage, networking, observability, security, governance

Storage

Recommended storage model:

• Object storage first: MinIO/S3-compatible storage for run artifacts, model weights, datasets, checkpoints, logs, and evidence packets.
• Ceph/Rook later: If UAI moves into Kubernetes-heavy storage, use Rook/Ceph for block, file, and object storage. Do not start there unless operational complexity is justified.
• Local NVMe cache: Use per-node local cache for model weights and datasets, with explicit cache invalidation.
• MLflow: Use MLflow Tracking and Model Registry for experiments, metrics, parameters, artifacts, and model lineage.
• Explorer: Store only safe summaries, docs, redacted evidence, and catalog pointers, not raw artifacts or secrets.

Storage princi

Feedback 339

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:50:00.350632+00:00

ples:

• Artifact references should be immutable and checksummed.
• Sensitive datasets should require data-class policy and lane controls.
• Model weights should have provenance, license, hash, quantization, runtime compatibility, and allowed products.
• Cloud burst should avoid uncontrolled egress and hidden data copies.

Networking

Recommended network posture:

• Internal-only by default.
• No public exposure changes without operator-approved exposure runbook.
• Separate control plane, data plane, and observability plane.
• Prefer Gateway API/Envoy Gateway or equivalent for Kubernetes ingress only after internal policy is set.
• Use service mesh only when mTLS, traffic policy, retries, and observability justify the operational overhead.
• Keep Proxmox management, Kubernetes API, object storage, model endpoints, and Explorer on distinct trust boundaries.

Network zones:

• uai-control: UAPI, policy, run ledger.
• uai-compute: scheduler workers and GPU nodes.
• uai-storage: object store and model cache.
• uai-observability: metrics, logs, traces.
• uai-sandbox: experiments and risky devices.
• uai-cloud-burst: leased capacity with tight egress and TTL.

Observability

Minimum metrics:

• Queue depth by lane.
• Queue wait by lane/product.
• Run duration.
• Success/failure/cancel counts.
• GPU utilization.
• VRAM utilization.
• GPU temperature and power where available.
• DCGM health for NVIDIA.
• Intel GPU telemetry where available.
• Cost per cloud run.
• Artifact bytes stored.
• Error codes by backend.
• Policy denials by reason.
• Device freshness.

Recommended stack:

• OpenTelemetry Collector for telemetry collection and export.
• Prometheus for metrics scraping and alerting.
• DCGM Exporter for NVIDIA GPU metrics.
• Grafana or Command Center dashboards.
• Structured logs with run IDs and product labels.
• Explorer evidence export for approved audit summaries.

Security

Security requirements:

• Dedicated service accounts per product.
• Scoped tokens, no shared admin token.
• Secrets in a secret store, never in docs, prompts, logs, run records, or artifacts.
• Deny-by-default routing policy.
• Data-class-aware admission.
• No raw host filesystem browsing through UAPI.
• No public exposure mutation through compute requests.
• Signed images and SBOMs for GPU runners.
• Runtime isolation by namespace, VM, or node pool according to data class.
• Redacted logs and safe product-facing errors.
• Cloud credentials isolated per provider/account/lane.

Secret lifecycle requirements:

• Short-lived token injection only at runtime.
• Rotation and revocation recorded in audit events.
• Break-glass access requires a scoped approval record and extra logging.
• Prompt, log, artifact, environment, and crash-dump scanning before product-visible retrieval or Explorer export.
• No environment dumps, full command echoes with secrets, raw stack traces, shell histories, or mounted secret paths in logs.
• Secret-bearing artifacts are quarantined until redacted, denied, or approved for a protected store.
• Cache purge rules for model/data caches that may have touched sensitive inputs.
• Explorer export is blocked until redaction state, data class, artifact hashes, and safe summary are present.

Governance

Governance should be enco

Feedback 340

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:50:00.380220+00:00

ded as versioned policy:

• Who can request each lane.
• What approvals are required.
• Which data classes may run where.
• Which products have reservations.
• Which devices are excluded.
• Which cloud providers are allowed.
• What TTL/cost caps apply.
• What evidence must be produced.
• What gets cataloged into Explorer.

OPA/Gatekeeper or Kyverno can enforce Kubernetes admission policy later. The UAPI policy engine should enforce product-level policy before Kubernetes sees a workload.

Staged migration roadmap

Roadmap gating rule: each phase is blocked until the prior phase has an Explorer-cataloged review packet and a scoped approval artifact for the next phase. "Done when" proves completion; it does not authorize the next mutation.

Phase 0 - Proposal and catalog

Deliverables:

• This architecture proposal.
• Explorer feedback note for missing GPU Cloud/UAPI product context.
• Operator review packet.
• Initial schema draft.

Done when:

• Proposal is reviewed.
• Product boundaries are accepted.
• Open questions are assigned.
• Explorer catalog plan exists.
• Gate 1 approval is explicitly granted before any read-only survey work starts.

Phase 1 - Read-only inventory and schema

Deliverables:

• Device survey runbook.
• Device registry schema v0.1.
• Workload request schema v0.1.
• Routing policy schema v0.1.
• Run record schema v0.1.
• Read-only inventory for known devices and candidate devices.

Done when:

• Every known GPU/device has a candidate or surveyed registry record.
• Reserved/unsafe/unknown devices are not schedulable.
• No device mutation has occurred.
• Gate 2 schema/fixture approval exists before any UAPI MVP build work starts.

Phase 2 - UAPI Bridge MVP

Deliverables:

• UAPI intake stub.
• Auth/service account plan.
• Static policy engine.
• Run ledger.
• Manual/direct adapter that only targets approved manual wrappers.
• Product-facing POST /v1/workloads and GET /v1/runs/{id}.

Done when:

• Cadence or a test client can submit a safe no-op/manual request.
• Denied requests produce audited reason codes.
• Run records are written.
• Explorer-safe summary export exists.
• Fixture policy simulator proves unknown data class, unsurveyed devices, missing TTL, missing run record, and unscoped approvals fail closed.

Phase 3 - Local inference lane

Deliverables:

• One approved local model-serving adapter.
• vLLM or Ollama wrapper depending on hardware and model profile.
• LiteLLM optional gateway for product compatibility.
• Artifact and log redaction path.

Done when:

• UAPI can route a small internal inference request.
• The product receives status/result via UAPI.
• No product touches the device directly.
• Metrics and run records are available.

Phase 4 - Sandbox Kubernetes GPU lane

Deliverables:

• Sandbox Kubernetes GPU worker lane.
• NVIDIA GPU Operator for NVIDIA nodes if hardware supports it.
• Intel device plugin experiment for Intel GPUs if hardware supports it.
• DCGM exporter for NVIDIA metrics.
• Kueue first for batch admission, quotas, queues, and resource flavors.
• KubeRay only after Kueue batch behavior is understood and a Ray workload justifies it.
• Volcano only if a specific gang/topology/co-scheduling requirement is documented.
• MinIO/S3 artifact path.

Done when:

• Sandbo

Feedback 341

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:50:00.407839+00:00

x GPU job can run through UAPI. - Kueue queue/admission behavior is visible. - GPU metrics are scraped. - Artifacts are stored with checksums. - No production/public exposure changes occurred. - GPU Operator/device-plugin/observability installation evidence is approved as sandbox mutation, not treated as read-only work.

Phase 5 - Product integration

Deliverables:

• Cadence request/status card.
• Cortex embedding/indexing lane.
• Beacon notification/status integration.
• Mesh service dependency integration.
• Command Center capacity/approval dashboard.
• Explorer evidence ingestion packet.
• Per-product ownership contract matrix accepted.
• Event publication contract accepted.

Done when:

• Products consume UAPI rather than device-specific access.
• Product-specific quotas and reservations are encoded.
• Operators can see queue, cost, device freshness, and failure reasons.
• Cadence can request but not approve operational gates.
• Command Center can approve/deny gates but not execute backend work directly.
• Beacon publishes only approved safe events and never mutates route state.
• Explorer receives only approved summaries and never raw run artifacts.

Phase 6 - Cloud burst

Deliverables:

• Cloud provider selection.
• Budget policy.
• TTL policy.
• Image/bootstrap process.
• Object storage and egress guardrails.
• Cloud run ledger fields.

Done when:

• Cloud burst is manually approved.
• Cost and TTL are enforced.
• Data egress policy is enforced.
• Run records and artifacts are complete.
• Provisioning adapter and scheduler adapter responsibilities are separated.
• Cloud teardown proof is present.

Phase 7 - Multi-backend maturity

Deliverables:

• Slurm adapter if bare-metal/HPC needs justify it.
• Nomad adapter if lightweight heterogeneous scheduling is useful.
• Proxmox adapter for approved VM/LXC provisioning and static passthrough.
• Multi-cluster Kubernetes support if needed.

Done when:

• Backends are replaceable under the same UAPI contract.
• Policy and run records stay consistent across backends.

Phase 8 - Internal developer platform

Deliverables:

• Backstage-like catalog or Command Center service catalog.
• Golden path templates.
• Self-service request forms.
• Policy-as-code review flow.
• SLOs and reliability reports.

Done when:

• New UAI products can request compute through documented templates.
• Operators can approve, audit, and retire lanes without rediscovering the system.

Runbooks

Every runbook should include:

• Preconditions.
• Authority level.
• Required scoped approval record.
• Required inputs.
• Allowed mutation level.
• Step list.
• Abort criteria.
• Rollback or cleanup criteria.
• Output artifacts.
• Evidence destination.
• Explorer catalog update requirement.
• Secret/log redaction check.
• Owner for follow-up.

Runbook 1 - Device registration, read-only

Purpose: add or refresh a device registry entry without scheduling workloads.

Preconditions:

• Gate 1 read-only survey approval exists.
• Device is not treated as local.
• Survey commands or sources are approved before use.

Outputs:

• Device registry candidate or surveyed record.
• Safe survey summary.
• Freshness timestamp.
• Explorer catalog candidate.

Steps:

1. Confirm operator authorization for survey only.
2. Iden

Feedback 342

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:50:00.437850+00:00

tify device class: physical host, VM, accelerator, model endpoint, storage, or network service. 3. Gather read-only facts: OS, driver, GPU, VRAM, CPU, memory, storage, network, scheduler compatibility, metrics availability. 4. Record trust tier and exposure boundary. 5. Mark schedulable_state=candidate or surveyed, not approved_scheduled. 6. Attach benchmark references only if approved and already run. 7. Export safe device summary for Explorer review.

Stop lines:

• Do not install drivers.
• Do not reboot.
• Do not join clusters.
• Do not enable public routes.
• Do not copy secrets.
• Abort if the survey exposes credentials, private paths beyond the approved summary, or requires mutation.

Runbook 2 - Workload request intake

Purpose: let a product request compute without direct device access.

Preconditions:

• UAPI schema version is accepted.
• Service account scope is known.
• Policy version is loaded.

Outputs:

• Validated request record or denial record.
• Server-side classification result.
• Placement decision or safe denial reason.
• Run record before backend submission.

Steps:

1. Product sends WorkloadRequest.
2. UAPI validates schema and idempotency key.
3. UAPI authenticates service account.
4. Policy engine checks authority, data class, lane, TTL, budget, and product quota.
5. Registry returns eligible devices/backends.
6. Router creates placement decision.
7. Run ledger creates run_id.
8. Adapter submits to backend.
9. Product polls or subscribes to run status.

Stop lines:

• Reject if no TTL.
• Reject if data class exceeds product authority.
• Reject if requested device is unsurveyed or reserved.
• Reject if cloud burst lacks budget/approval.
• Reject if server classification is unknown or lower than client-sensitive assertion.

Runbook 3 - Local inference lane

Purpose: route internal inference to a known local serving runtime.

Preconditions:

• Serving device is surveyed and approved for the lane.
• Model ref, license, and data class are known.
• Runtime endpoint is internal-only and approved.

Outputs:

• Run record.
• Redacted log ref.
• Model/runtime metrics.
• Artifact refs with checksums.

Steps:

1. Confirm serving device is approved_manual or approved_scheduled.
2. Confirm model ref exists, license is known, and weights are local or approved for download.
3. Choose runtime profile: vLLM for high-throughput OpenAI-compatible serving, Ollama for simple local serving, LiteLLM only as gateway.
4. Start or use existing approved model endpoint.
5. Send request through UAPI model endpoint.
6. Record latency, tokens, GPU metrics, and artifacts if applicable.
7. Export safe summary.

Stop lines:

• Do not download unknown model weights.
• Do not expose endpoint publicly.
• Do not log prompts containing secrets.
• Do not route to shared GPU mode for sensitive data without an approved isolation profile.

Runbook 4 - Kubernetes GPU sandbox lane

Purpose: validate Kubernetes GPU orchestration safely.

Preconditions:

• Gate 5 sandbox approval exists.
• Sandbox cluster/node scope is explicit.
• Non-secret fixture workload is selected.
• Driver/device-plugin/observability installs are approved as sandbox mutations.

Outputs:

• Queue/admission evidence.
• GPU metrics evidence.
• Artifact checksum evid

Feedback 343

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:50:00.466751+00:00

ence. - Adapter compliance report.

Steps:

1. Confirm sandbox authority and device approval.
2. Build a sandbox cluster or use an approved sandbox node pool.
3. Install only approved GPU components: - NVIDIA GPU Operator for NVIDIA nodes. - Intel device plugin for Intel GPU experiments. - DCGM exporter for NVIDIA monitoring.
4. Add Kueue for batch admission.
5. Add KubeRay only if a Ray workload has been approved after Kueue validation.
6. Add Volcano only if gang scheduling is required and approved.
7. Run a small non-secret workload through UAPI.
8. Capture metrics, logs, queue state, and artifact checksums.
9. Publish safe evidence.

Stop lines:

• No production workloads.
• No public ingress.
• No secret-bearing data.
• No production Proxmox/host mutation without a separate runbook.
• Abort if GPU Operator/device-plugin installation would touch a non-sandbox node.

Runbook 5 - Cloud GPU burst

Purpose: use leased cloud GPU capacity with strict governance.

Preconditions:

• Gate 7 cloud-burst approval exists.
• Budget, TTL, data class, provider, region, image, and egress profile are approved.
• Provisioning adapter and scheduler adapter responsibilities are clear.

Outputs:

• Cloud run record.
• Cost and TTL evidence.
• Teardown evidence.
• Artifact and metrics refs.

Steps:

1. Confirm cloud-burst approval.
2. Confirm product quota and budget.
3. Confirm data class permits cloud.
4. Confirm image, model, dataset, and artifact paths.
5. Create cloud run with TTL and teardown hook.
6. Restrict egress.
7. Stream metrics/logs.
8. Store artifacts and checksums.
9. Destroy capacity at TTL or completion.
10. Record cost and evidence.

Stop lines:

• No cloud run without budget.
• No cloud run without TTL.
• No secret-bearing workload unless explicitly approved.
• No untracked manual cloud console changes.
• Abort if teardown cannot be verified.

Runbook 6 - Incident lane

Purpose: prioritize repair, safety, or production evidence work.

Preconditions:

• Incident approval exists or emergency break-glass process is invoked.
• Affected lane/device/product is identified.
• Evidence capture path is known.

Outputs:

• Incident run record.
• Frozen/degraded device state if needed.
• Safe incident summary.
• Follow-up remediation owner.

Steps:

1. Open incident run record.
2. Identify affected product/device/lane.
3. Freeze routing to suspect devices if needed.
4. Route repair or diagnostic jobs only to approved incident lane.
5. Capture run evidence.
6. Update device state.
7. Export safe incident summary to Explorer.

Stop lines:

• Do not preempt protected product reservations without approval.
• Do not mutate external exposure.
• Do not paste secrets into incident notes.

Fixture-only policy simulator acceptance tests

Before any real backend adapter is enabled, UAPI policy should pass fixture-only tests:

Feedback 344

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:50:00.495997+00:00

| Reserved Cortex device requested by Cadence | Deny with product_reservation | | Cloud burst without budget | Deny with budget_required | | Cloud burst without teardown proof path | Deny with teardown_required | | Shared GPU requested for secret-bearing workload | Deny with isolation_insufficient | | Preemptible lane without checkpoint/grace/requeue fields | Deny with preemption_contract_required | | Adapter submit without run record | Deny with run_record_required | | Kubernetes DRA-style claim has no matching approved accelerator resource class/capability set | Deny with device_claim_unmatched | | Product requests raw device view without operator scope | Return redacted/pseudonymous view | | Kubernetes DRA-style NVIDIA fixture claim matches approved resource class/capabilities | Accept with policy_accepted |

Risk register

Risk ownership should be assigned during operator review. Until then, the default owner is "unassigned", and Command Center should eventually display trigger/early-warning states beside each risk.

Feedback 345

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:50:00.525704+00:00

down | | GPU sharing used for sensitive workloads | Critical | Medium | Isolation profile, data-class restrictions, deny unknown sharing semantics | | Model/data locality ignored | Medium | High | Placement scoring includes model cache, dataset locality, storage bandwidth, warmup time | | Cloud provisioning and scheduling are conflated | Medium | Medium | Separate provisioning adapter from scheduler adapter and require teardown proof | | Observability install treated as read-only | High | Medium | Device plugin, GPU Operator, and telemetry installs require sandbox/operator approval |

Open questions

1. What is the current approved inventory of GPUs, CPU hosts, Proxmox nodes, NUCs, workstations, and cloud accounts?
2. Which devices are reserved for Cortex, Cadence, operator work, or maintenance?
3. What is the desired first execution backend: direct/manual wrapper, Kubernetes sandbox, Slurm, Nomad, or Proxmox-backed worker?
4. Does UAI want UAPI written as Rust/Axum, Python/FastAPI, or another stack?
5. What is the current UAPI codebase and route map?
6. What service account model should UAPI use for products?
7. What are the first three workloads to support?
8. Which models must be served locally, and which can use external providers?
9. What data classes are allowed on leased cloud GPUs?
10. What cloud provider(s) should be approved for GPU burst?
11. Should UAI use MLflow from the start, or defer it until after object storage?
12. Is Backstage/IDP-style developer self-service desired, or should Command Center own that UX?
13. How should Explorer ingest device survey summaries and run evidence without raw secrets?
14. What does "NUC 140T" mean in exact hardware terms, and what accelerator stack does it expose?
15. Is Intel Arc Pro B70 a likely procurement target, test target, or only a future option?
16. What is the minimum viable Command Center dashboard?
17. What SLO matters first: latency, throughput, queue wait, cost, or operator confidence?
18. Should cloud burst ever run private/customer/secret-bearing data?
19. Who approves policy changes?
20. How long should run records and artifacts be retained?

2026-06-22 current-source refresh

This refresh was performed after the Thinktank bundle passed the one-shot CT127 container verification. It did not call UAI Explorer live because the Explorer API key was not present in the process environment for this continuation turn and was not retyped into shell commands. The UAI source-of-truth basis remains the sanitized Explorer cache recorded in [REDACTED:high-entropy].md and the refreshed Thinktank readiness evidence in .[REDACTED:high-entropy].json.

Official-source findings

Feedback 346

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:50:00.558936+00:00

nit of admission for applications that run to completion, and AdmissionChecks allow extra criteria before admission. Sources: https://kueue.sigs.k8s.io/docs/concepts/workload/ and https://kueue.sigs.k8s.io/docs/concepts/admission_check/ | UAPI should perform product/data/approval admission before Kueue, then map eligible batch jobs to Kueue Workloads later. | | NVIDIA GPU Operator and telemetry | NVIDIA's GPU Operator docs include DCGM Exporter as the default Kubernetes telemetry path, while DCGM Exporter exposes GPU metrics over /metrics for Prometheus-compatible monitoring. Sources: https://docs.nvidia.[REDACTED:high-entropy].html and https://docs.nvidia.[REDACTED:high-entropy].html | Treat GPU Operator and DCGM Exporter as mutable sandbox installs, not read-only probes; require a telemetry evidence packet before promotion. | | Intel GPUs | Intel's Kubernetes GPU plugin exposes discrete and integrated Intel GPU devices to workloads. Source: https://github.[REDACTED:high-entropy].md | Keep Intel Arc Pro B70 and future Intel lanes in the registry as candidate accelerators pending driver, runtime, and workload benchmarks. | | Ray/KubeRay | Ray docs show Kueue gang scheduling for RayJob and Volcano gang scheduling for RayCluster/RayJob. Sources: https://docs.ray.[REDACTED:high-entropy].html and https://docs.ray.[REDACTED:high-entropy].html | Add Ray only after UAPI can prove queue admission and run-ledger semantics; do not make Ray the first scheduler. | | Slurm | Slurm GRES supports arbitrary generic resources, with GPU-specific features. Source: https://slurm.schedmd.com/gres.html | Slurm remains the best candidate for HPC/bare-metal partitions, but it should sit behind a UAPI adapter rather than become the product API. | | Nomad | HashiCorp's NVIDIA Nomad device plugin exposes NVIDIA GPUs and detects MIG instances. Source: https://developer.hashicorp.com/nomad/plugins/devices/nvidia | Nomad is viable for a lightweight heterogeneous lane only if UAI chooses to operate another scheduler; keep it optional. | | Proxmox | Proxmox PCI passthrough gives a VM control over a physical PCI device and is documented for KVM virtualization. Source: https://pve.proxmox.com/wiki/PCI_Passthrough | Keep Proxmox as lifecycle/isolation/static-passthrough infrastructure, not a dynamic GPU scheduler. | | vLLM | vLLM's online serving docs describe an OpenAI-compatible server surface. Source: https://docs.vllm.ai/en/stable/serving/online_serving/ | vLLM is the likely high-throughput local inference runtime behind UAPI once model, GPU, and data-class gates exist. | | Ollama | Ollama documents OpenAI compatibility, including a non-stateful Responses API compatibility path. Source: https://docs.ollama.com/api/openai-compatibility | Ollama is useful for local/simple model lanes, but UAPI must record compatibility gaps rather than treating it as full OpenAI parity. | | LiteLLM | LiteLLM proxy docs emphasize unified LLM gateway behavior, spend tracking, budgets, and routing groups. Sources: https://docs.litellm.ai/docs/simple_proxy and https://docs.litellm.ai/docs/routi

Feedback 347

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:50:00.587121+00:00

ng | LiteLLM belongs in the model-provider/gateway layer, not the hardware scheduler; budgets should be mirrored in UAPI policy. | | OpenTelemetry | The OpenTelemetry Collector is a vendor-agnostic receiver/processor/exporter for telemetry. Source: https://opentelemetry.io/docs/collector/ | UAPI and GPU Cloud should emit OTLP-compatible traces/events while preserving an append-only run ledger for governance. | | MLflow | MLflow's tracking server can proxy artifact access, which gives the server assumed access to reachable artifacts. Source: https://mlflow.[REDACTED:high-entropy]/ | If MLflow is used, artifact proxy permissions must be treated as sensitive infrastructure authority and reviewed before enablement. | | Object storage | MinIO Operator is Kubernetes-native and S3-compatible; Ceph Object Gateway provides S3- and Swift-compatible interfaces. Sources: https://operator.min.io/ and https://docs.ceph.com/en/latest/radosgw/ | Start with one object-store contract in UAPI; choose MinIO for simpler early sandboxing, Ceph/Rook only if the lab commits to the operational burden. | | Gateway/service mesh | Gateway API documents GAMMA service-mesh support, and Istio documents Kubernetes Gateway API support. Sources: https://gateway-api.sigs.k8s.io/ and https://istio.[REDACTED:high-entropy]/ | Internal routing can later standardize on Gateway API/Istio, but no public exposure or mesh mutation belongs in the compute-routing milestone. | | Internal developer platform | Backstage's catalog entity descriptor format defines a human-maintainable entity model. Source: https://backstage.[REDACTED:high-entropy]/ | Use Backstage-style catalog modeling as inspiration only; UAI Explorer and Command Center remain the UAI-native evidence and operator surfaces unless Scott approves a separate IDP. |

Recommendation changes after refresh

• Keep the proposal's control-plane-first position. The refresh strengthens the conclusion that UAPI must normalize policy, admission, run records, artifacts, and evidence before any backend scheduler becomes authoritative.
• Promote Kubernetes DRA from a "later curiosity" to a schema-design constraint. Even if the first Kubernetes lane uses classic device plugins, the UAPI model should be able to express device classes, claims, sharing, and vendor-specific capabilities.
• Treat observability as a first-class gate. GPU telemetry and OpenTelemetry are not optional polish; they are how routing decisions become auditable.
• Keep the first executable gate fixture-only. Current docs make the backend landscape richer, not simpler, so the safest next action remains schemas plus a policy simulator, not installing GPU Operator/Kueue/Ray/Slurm/Nomad.

Research bibliography

Internal UAI source-of-truth context

• UAI Explorer AI Start Here, fetched through AI context slug uai-doc-start_here_ai.
• UAI Explorer Rules, fetched through AI context slug uai-doc-uai_explorer_rules.
• UAI Explorer Agent Instructions, fetched through AI context slug uai-doc-agents.
• Documentation Source Of Truth Runbook, fetched through AI context slug [REDACTED:high-entropy].
• AI Lanes And MCP Adapter

Feedback 348

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:50:00.614849+00:00

Runbook, fetched through AI context slug [REDACTED:high-entropy]. - UAI Development Standards Runbook, fetched through AI context slug [REDACTED:high-entropy]. - UAI Agent Feedback Convention, fetched through AI context slug [REDACTED:high-entropy]. - AI Memory, Knowledge, Beacon, And Mesh Runbook, fetched through AI context slug [REDACTED:high-entropy]. - UAI Explorer Sandbox Protocol, fetched through AI context slug uai-doc-docs-runbooks-sandbox-protocol. - Public-Safe Access Runbook, fetched through AI context slug [REDACTED:high-entropy]. - UAI Explorer QA QC QoL Gates, fetched through AI context slug uai-doc-docs-qa-qa-qc-qol-gates. - UAI Explorer 2.0 UX Blueprint, fetched through AI context slug uai-doc-docs-plans-explorer-2.0-ux-blueprint. - Explorer 2.0 Redaction And Embedding Lanes, fetched through AI context slug uai-doc-docs-plans-explorer-2.0-redaction-embedding-lanes. - UAI Explorer Final Completion Audit, fetched through AI context slug [REDACTED:high-entropy].

GPU scheduling and orchestration

• Kubernetes GPU scheduling: https://kubernetes.[REDACTED:high-entropy]/
• Kubernetes device plugins: https://kubernetes.[REDACTED:high-entropy]/
• Kubernetes Dynamic Resource Allocation: https://kubernetes.[REDACTED:high-entropy]/
• Kueue overview: https://kueue.sigs.k8s.io/docs/overview/
• Kueue ClusterQueue concepts: https://kueue.sigs.k8s.io/docs/concepts/cluster_queue/
• Volcano scheduler docs: https://volcano.sh/en/docs/
• Volcano GitHub: https://github.com/volcano-sh/volcano
• Ray on Kubernetes / KubeRay docs: https://docs.ray.io/en/latest/cluster/kubernetes/index.html
• KubeRay GitHub: https://github.com/ray-project/kuberay
• Slurm GRES docs: https://slurm.schedmd.com/gres.html
• Slurm GPU management: https://slurm.schedmd.com/gpu_management.html
• HashiCorp Nomad resources and device scheduling docs: https://developer.hashicorp.[REDACTED:high-entropy]
• Proxmox PCI passthrough docs: https://pve.proxmox.com/wiki/PCI_Passthrough

GPU operators, device plugins, and hardware support

• NVIDIA GPU Operator: https://docs.nvidia.[REDACTED:high-entropy].html
• NVIDIA GPU Operator GPU sharing: https://docs.nvidia.[REDACTED:high-entropy].html
• NVIDIA Kubernetes device plugin GitHub: https://github.com/NVIDIA/k8s-device-plugin
• NVIDIA DCGM Exporter: https://github.com/NVIDIA/dcgm-exporter
• Intel Device Plugins for Kubernetes: https://github.[REDACTED:high-entropy]
• Intel GPU plugin docs in device plugins repo: https://github.[REDACTED:high-entropy]
• Intel Arc Pro product family page: https://www.intel.[REDACTED:high-entropy].html
• Level1Techs Intel B70 technical discussion and early operator notes, anecdotal/non-authoritative: https://forum.level1techs.[REDACTED:high-entropy]

Model serving and AI gateways

• vLLM documentation:

Feedback 349

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:50:00.639425+00:00

https://docs.vllm.ai/ - vLLM OpenAI-compatible server: https://docs.vllm.[REDACTED:high-entropy].html - vLLM Kubernetes/Helm deployment docs: https://docs.vllm.ai/en/stable/deployment/frameworks/helm.html - Ollama API documentation: https://github.com/ollama/ollama/blob/main/docs/api.md - LiteLLM proxy docs: https://docs.litellm.ai/docs/simple_proxy - LiteLLM reliability, fallbacks, and routing docs: https://docs.litellm.ai/docs/proxy/reliability

Storage, MLOps, and artifacts

• MLflow docs: https://mlflow.org/docs/latest/
• MLflow Tracking: https://mlflow.org/docs/latest/ml/tracking/
• MLflow Model Registry: https://mlflow.org/docs/latest/ml/model-registry/
• MinIO Kubernetes docs: https://min.io/docs/minio/kubernetes/upstream/
• Ceph Object Gateway docs: https://docs.ceph.com/en/latest/radosgw/
• Rook Ceph docs: https://rook.io/docs/rook/latest-release/

Observability, gateways, service mesh, platform engineering

• OpenTelemetry Collector docs: https://opentelemetry.io/docs/collector/
• Prometheus overview: https://prometheus.io/docs/introduction/overview/
• Kubernetes Gateway API: https://gateway-api.sigs.k8s.io/
• Envoy Gateway docs: https://gateway.envoyproxy.io/
• Istio service mesh overview: https://istio.io/latest/about/service-mesh/
• Backstage overview: https://backstage.io/docs/overview/what-is-backstage/
• Crossplane docs: https://docs.crossplane.io/latest/
• OPA Gatekeeper docs: https://open-policy-agent.github.io/gatekeeper/website/docs/
• CNCF platform engineering maturity model: https://tag-app-delivery.cncf.[REDACTED:high-entropy]/

Current-source refresh used by this Thinktank pass

These official or primary sources were rechecked during the Thinktank sandbox production exercise on 2026-06-21 and should be preferred over stale recollection when implementation gates open:

• NVIDIA GPU Operator: https://docs.nvidia.[REDACTED:high-entropy].html
• NVIDIA GPU Telemetry / DCGM Exporter: https://docs.nvidia.[REDACTED:high-entropy].html
• NVIDIA DCGM Exporter GitHub: https://github.com/NVIDIA/dcgm-exporter
• Kubernetes Dynamic Resource Allocation: https://kubernetes.[REDACTED:high-entropy]/
• Kueue Workload concept: https://kueue.sigs.k8s.io/docs/concepts/workload/
• Ray gang scheduling with Kueue: https://docs.ray.[REDACTED:high-entropy].html
• Volcano Ray/KubeRay integration: https://volcano.sh/docs/ecosystem/rayonvolcano/
• Slurm GRES scheduling: https://slurm.schedmd.com/gres.html
• Nomad device block: https://developer.hashicorp.com/nomad/docs/job-specification/device
• Intel GPU device plugin: https://intel.github.[REDACTED:high-entropy].html
• Proxmox PCI passthrough: https://pve.proxmox.com/wiki/PCI_Passthrough
• vLLM OpenAI-compatible server: https://docs.vllm.ai/en/v0.21.0/serving/openai_compatible_server/
• Ollama OpenAI compatibility: https://ollama.com/blog/openai-compatibility
• LiteLLM OpenAI-compatible endpoints: https://docs.litellm.ai/docs/providers/openai_compatible
• MLflow self-hosting architecture: https://mlflow.org/docs/latest/self-hosting/
• MLflow tracking server and

Feedback 350

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:50:00.667250+00:00

remote artifact storage: https://mlflow.[REDACTED:high-entropy]/ - MLflow artifact stores: https://mlflow.[REDACTED:high-entropy]/ - MinIO AIStor container/S3-family docs: https://docs.min.io/aistor/installation/container/ - Ceph Object Gateway S3 API: https://docs.ceph.com/en/latest/radosgw/s3/ - Cephadm lifecycle management: https://docs.ceph.com/en/latest/cephadm/ - OpenTelemetry Collector architecture: https://opentelemetry.io/docs/collector/architecture/ - Istio Gateway API support: https://istio.[REDACTED:high-entropy]/ - Backstage Software Catalog: https://backstage.io/docs/features/software-catalog/

Independent review of other agent outputs

Review scope: I found one other local reply file, /[REDACTED:high-entropy].md. I did not find separate Claude, GPT, or raw peer-agent reply files in the local agent-replies trees. The Grok file includes its own embedded reviews of internal contributors, but those contributor drafts were not present as separate files, so this review evaluates the final Grok output only.

Self-containment status: this Thinktank reply is the canonical local plan-only artifact for the current sandbox pass. The main body above includes the required sections, schema outlook, UAPI redesign, workload/routing/run-record schemas, product integration contracts, runbooks, gate matrix, and bibliography. The companion machine-readable schema is docs/schema/uapi-gpu-cloud.schema.json. No absent external attachment is required to understand or review this Thinktank proposal.

Grok GPU Cloud UAPI planner reply

Blunt rating: strong research packet, weak promotion artifact. Technically useful, but not safe or self-contained enough to treat as the canonical architecture plan without a cleanup pass.

What is good:

• It correctly identifies the central product boundary: Cadence should submit work, while UAPI/registry/policy decide placement. That matches the most important architectural move.
• It has useful depth on Kueue, Volcano, Slurm, Nomad, GPU Operator, vLLM, Ollama, LiteLLM, Ray/KubeRay, MinIO, DCGM, Prometheus, and OpenTelemetry. The LiteLLM/vLLM/Ollama section is especially actionable as an inference gateway path.
• It treats ephemeral/contributed capacity as a first-class concept with TTL, provenance, proposal lineage, and claim/tunnel ideas. That is one of its best original contributions.
• It recognizes Proxmox as the host layer and recommends K8s on VMs rather than trying to make Proxmox itself the fine-grained scheduler.
• It includes concrete TypeScript-ish schema sketches for Device, WorkloadRequest, RoutingPolicy, and RunRecord, plus invariants around TTL and append-only records. Those are useful even though incomplete.
• It has a better-than-average discussion of priority lanes: critical gang training, shared inference, interactive, dev/best-effort, and burst.
• It is honest that several things are context gaps: exact GPU inventory, current Cadence contracts, unified cost units, storage policy, and Intel Arc Pro B70 validation.
• It has a useful embedded peer-review appendi

Feedback 351

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:50:00.697429+00:00

x. Some of those critiques are sharper than the main body, especially on schema incompleteness, storage pressure, and K8s-on-Proxmox risk.

What I do not like:

• The opening "Connection TL;DR" is a serious hygiene failure. It publishes operational SSH commands, hostnames, public/internal IPs, and route hints in an architecture proposal. Even if some details were already known in prior runbooks, putting them at the top as "verbatim authoritative" is exactly the wrong shape for a public-safe or Explorer-promotable artifact.
• It overstates source-of-truth status. It says Explorer is source of truth, but then embeds loose operational connection instructions and local path authority in the same artifact. That mixes governed context with lab access hints and makes the document harder to safely catalog.
• The reviewed Grok artifact is not self-contained where it matters. Several required sections defer core schemas and details to absent contributor material, but those referenced drafts are not present as separate files in the local reply tree. That makes that external output dependent on missing context.
• It is too K8s-forward too early. Phase 1 jumps to K8s on Proxmox VMs and GPU Operator deployment before resolving storage pressure, approval gates, device inventory, and a fixture-only UAPI policy simulator. That is a practical sequencing risk.
• It treats GPU Operator, DCGM, Kueue, vLLM, and MinIO as natural next steps, but underplays that installing those components is a mutation and must be approval-gated. The proposal says plan-only, but its roadmap language drifts toward implementation.
• It does not sufficiently separate provisioning from scheduling. Cloud burst capacity needs one adapter to create/teardown capacity and another to submit workloads. Grok mostly blends those under UAPI abstraction.
• Its UAPI story is good but slightly overloaded. LiteLLM, policy evaluation, registry query, placement, claim/tunnel handling, cost accounting, OTel, and fallback routing are all packed into "thin UAPI Bridge". That could easily become a large custom control plane with unclear failure modes.
• The data classification model is too weak. It talks about policy tags and data refs, but does not make server-side classification authoritative. Clients should not be allowed to self-declare sensitivity downward.
• Approval modeling is not durable enough. It relies on "operator review", "proposal-gated", and "Explorer decisions" language without defining scoped approval records, expiry, revocation, rollback, or denial codes.
• RunRecord immutability is asserted but not made tamper-evident. It needs policy snapshot hashes, actor chain, runner image digest, SBOM refs, input/output artifact hashes, immutable storage, and retention rules.
• Device registry views could leak topology. It models host, CT ID, zone, owner, and mesh identity, but does not strongly define redacted role-based views for product callers or Explorer summaries.
• Product integration is role-level, not contract-level. It says what Cadence, Cortex, Beacon, Mesh, Explorer, and UAI GPU Cloud do, but does not specify owned/read/write/forbidden surfaces, event classes, data classes, quotas, or Explorer evidence boundaries.
• The "Research Bibliography" includes broad external claims and forum/

Feedback 352

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:50:00.731109+00:00

comparison sources without ranking official docs versus anecdotal/community evidence. That matters for Intel Arc Pro B70 and scheduler maturity. - The embedded self-review appendix is valuable but awkward. It criticizes missing self-containment and schema gaps while the reviewed external document still contains those gaps. A polished final should integrate the criticisms, not merely append them.

Technical corrections I would require before promotion:

1. Remove the connection TL;DR and all operational SSH/IP route instructions from the architecture proposal. Move any access notes to an operator-only runbook if still needed.
2. Replace "source of truth" claims with a precise status: draft local lineage artifact pending Explorer catalog review.
3. Inline the actual schemas or attach separate schema files. Do not reference absent external drafts for required contract details.
4. Add a decision packet, hard invariants, terminology/authority ladder, and operator gate matrix.
5. Add server-side data classification: client assertions may raise sensitivity, never lower it; unknown class denies.
6. Add scoped approval record schema with approver, scope, expiry, runbook/evidence ref, rollback, revocation, and denial codes.
7. Add tamper-evident run ledger requirements.
8. Split UAPI responsibilities from backend allocation and cloud provisioning.
9. Make the first milestone schema + fixture-only policy simulator, not K8s/GPU Operator deployment.
10. Add a redacted product integration contract matrix.

Best salvage:

• Keep the LiteLLM/vLLM/Ollama inference gateway research.
• Keep the ephemeral capacity/provenance framing.
• Keep the Kueue/ResourceFlavor lane mapping, but put it behind later gates.
• Keep the TypeScript schema sketches as seeds, then harden them into contract-grade schemas.
• Keep the peer-review critiques, but integrate them into the main body instead of leaving contradictions in place.

Bottom line: Grok's output is a good research-rich draft and a poor safe handoff artifact. It is valuable as a source packet, not as the final architecture authority.

2026-06-23 Thinktank controller readiness addendum

This addendum records how the UAI GPU Cloud + UAPI Bridge proposal should use the now-working Thinktank controller. It does not change the architecture recommendation and does not authorize implementation.

Current Thinktank evidence after the 2026-06-23 controller pass:

• The Room Controller is locally ready for operator review with final readiness 252/252, acceptance audit 432/432, handoff evidence 34/34, and operator review status ready_for_local_operator_review.
• UI QC verifies 65 assertions and 38 required desktop/mobile workflow milestones.
• The new External Result Intake path records operator-pasted external provider outputs through Rust ProviderApproval and the external-result ledger endpoint as normalized AgentResponse records.
• Process hygiene shows zero Thinktank listeners and zero helper processes after the proof pass.
• The UAI PAT marker scan found no persisted Explorer PAT value in the working tree outside excluded artifacts.

Implication for this GPU Cloud/UAPI exercise:

• Thinktank can now be used as the local plan-only review room for this proposal. Human reviewers or future ap

Feedback 353

• Product: uai-gpu-cloud-uapi-bridge
• Category: beneficial
• Related slug: ``
• Source: uai-thinktank-production-test
• Created at: 2026-06-23T18:50:00.760775+00:00

proved sidecars can paste bounded Codex, GLM, Grok, browser-relay, or local-worker critique outputs into the External Result Intake card, but the proposal must still treat those outputs as review evidence, not implementation authority. - The correct next product loop is a prompt/profile/provider bakeoff over this proposal, followed by an operator_review_brief export and, if approved, an Explorer review packet refresh. - No live provider, browser-login relay, CLI editor, container workbench, or scheduler backend should become the default path for this exercise. - The existing Gate 2 schema and policy simulator remain the safe executable boundary. Scheduler installs, device surveys, cloud capacity, and product integrations remain blocked behind separate scoped approvals.

Explorer status during this addendum:

• No live Explorer refresh was performed for this 2026-06-23 addendum because the Explorer endpoint and API key were not present in the local process environment, and the key was not retyped into shell commands.
• The proposal continues to rely on the sanitized 2026-06-21 Explorer context capture and the 2026-06-21/2026-06-22 source refresh notes already recorded in this packet.
• Separately, the Thinktank project publication state remains [REDACTED:high-entropy]; that does not grant this proposal source-of-truth status in Explorer.

Next safe action for this proposal:

1. Use Thinktank's local Room Controller to collect reviewer critiques as ledgered, prompt-only evidence.
2. Keep all reviewer/provider outputs behind one-run approvals and External Result Intake.
3. Refresh the Explorer review packet only after a reviewer chooses an approved docs lane.
4. Do not use this proposal to mutate UAPI, Cadence, Proxmox, Kubernetes, schedulers, devices, cloud accounts, routes, secrets, or storage.

Explorer feedback and follow-up

No feedback was submitted during the current Thinktank sandbox run because /ready, /api/ai/bootstrap, and all discovered required primary_context fetches succeeded.

Safe follow-up note for later Explorer catalog review:

• Product: UAI GPU Cloud + UAPI Bridge
• Category: catalog-gap
• Source: codex-thinktank
• Observation: Explorer AI lane worked and all required primary-context slugs loaded, but no product-specific UAI GPU Cloud or UAPI Bridge architecture/runbook slug was present.
• Suggested next action: catalog a GPU Cloud/UAPI Bridge brief with device inventory boundaries, current UAPI surfaces, and accepted scheduler authority.

No credential or secret was written to this file or to the sanitized Explorer context artifacts.