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

Complementary by construction. Bonsai and Prism Engine do not need to compete for the same layer. Prism ML can explore training, calibration, progressive quantization, ternarization, mixed precision, and model-quality tradeoffs. Prism's ECS-native compiler/runtime accepts the resulting artifact and solves the deployment questions that appear when those weights meet heterogeneous CPU, GPU, and NPU capabilities.

• Prism ML / Bonsai — Training + representation (calibration, ternary, mixed precision, quality)
• Prism Engine — Deployment + execution (admission, CImage, KV, routing, receipts)

Bonsai models made the architecture concrete. The Bonsai Ternary and binary model work gave Prism Engine a demanding upstream representation to compile against. That relationship helps validate the architecture's central boundary: numerical representation can evolve upstream while deployment layout, execution views, scheduling, and evidence remain explicit downstream.

1. Bonsai model — ternary or binary representation
2. Prism ingestion — identity + graph + tensor classes
3. Deployment admission — quality, target, resource gates
4. Execution artifact — CImage + views + receipts

Architectural result

The upstream model can change its numerical representation without forcing the runtime to become the owner of every deployment decision.

Prism Engine is the deployment scale. The same Bonsai model family can become different physical artifacts depending on where it will run. The logical model and quality contract remain attributable to Prism ML; the CImage reflects representation admission, KV policy, hardware capabilities, routing, and execution evidence for the target.

• CPU — Reference image. Differential checks, conservative fallback, and bounded memory.
• GPU — MI300X ROCm/HIP. AMD memory, kernels, queues, and active validation evidence.
• NPU — XDNA / XDNA2. Spatial planning, tile legality, and explicit hardware boundary.
• Heterogeneous — Distributed image. CPU/GPU/NPU routing, KV ownership, transfers, and replay.

Different expertise. One handoff.

Prism ML / Bonsai owns

• Training behavior
• Quantization strategy
• Ternary / binary representation
• Calibration and numerical validation

Prism Engine owns

• Representation admission
• Physical tile layout
• Execution views
• Scheduling, residency, and receipts

What the integration can become

Prism Engine can expose deployment evidence back upstream: tensor sensitivity, layout pressure, target-specific failures, and runtime observations. Prism ML can use that evidence to improve the next model or representation. The result is a feedback loop without collapsing training and deployment into one system.

The practical story.

• Model — quantized / ternarized artifact
• Compile — ECS analysis, search, admission
• CImage — layouts, views, KV policy, receipts
• Route — CPU, MI300X ROCm/HIP, XDNA/XDNA2
• Prove — backend-specific validation scope

The meeting sentence

Prism ML makes representation choices measurable; Prism Engine makes deployment choices explicit and records where the target path is — and is not — validated.