Establish one canonical subject and follow it through every observable surface.

A provider and a planner. General Compute brings the physical execution system: SambaNova accelerators, their memory behavior, kernels, queues, and provider-specific capabilities. Prism brings the layer that turns a workload requirement into a legal, inspectable composition across those capabilities.

• General Compute / SambaNova — Physical execution (accelerator, memory, kernels, queues, transport)
• Prism Engine — Deployment planning (admission, phase placement, handoff, receipt)

One serving request. Several physical phases. A frontier-model serving path does not have to assign prefill, KV state, decode, and streaming to the same provider. Prism can represent the phase requirements and ask the capability model for the lowest-latency legal composition.

• Phase 01 — Prefill. Process prompt, produce KV state.
• Boundary — KV handoff. Explicit transfer, ownership + cost.
• Phase 02 — Decode. Token generation, state residency.
• Phase 03 — Stream. Observable output, terminal receipt.

Researcher detail

The repository's heterogeneous-serving fixture models provider capabilities for prefill, KV handoff, decode, and token streaming. The serving requirement remains fixed while changing capability descriptions changes the physical plan. The SambaNova path is a planning and integration surface, not a claim of general production support.

The accelerator stays itself. Prism does not flatten MI300X ROCm/HIP, XDNA/XDNA2, or other providers into a generic GPU-shaped abstraction. It preserves provider-specific capabilities while making representation, spatial planning, KV ownership, routing, and validation implications visible to the ECS-native planner.

• Capabilities — What phases, dtypes, layouts, spatial resources, and workloads the provider can execute.
• Placement — Which phase or tensor region should run on CPU, GPU, or NPU under latency, memory, and compatibility constraints.
• Handoffs — Where activations, KV state, or compressed cache pages cross a physical memory or provider boundary.
• Evidence — What was admitted, planned, executed, measured, and actually validated for replay.

Clear boundaries prevent fake portability.

General Compute owns

• SambaNova topology
• Accelerator execution
• Memory and queues
• Provider transport
• Kernel behavior

Prism Engine owns

• Workload semantics
• Capability matching
• Phase placement
• KV ownership
• Receipts and recovery

Design constraint

A provider may reject a plan, but it cannot silently redefine the workload or publish an unaccounted outcome.

Compare plans, not slogans. The useful question is not whether a provider behaves like a GPU. It is whether Prism can represent its capabilities, produce a legal ECS-native plan, execute the selected phases, and compare the resulting evidence against another deployment.

• Input — same model, same workload, same quality policy
• Plan A — MI300X / ROCm-HIP, GPU validation path
• Plan B — XDNA/XDNA2, spatial planning path
• Output — latency, memory, KV, quality, receipts

Current boundary

General Compute and provider integrations remain bounded by backend, driver, device, and conformance evidence. A legal plan or compiled CImage does not by itself claim production execution on every provider.