[P2] Compute profile: implement the CPU reference and prove one real accelerator

[wsdt]

[P2] Compute profile: implement the CPU reference and prove one real accelerator

Review baseline and scope

Reviewed source: c9d32008e98d0e1711f47cb739f61c42376b884e on main, 22 September 2026.
Classification: IMPLEMENTATION + HARDWARE.
Predecessors: #210.
This replaces their remaining work; closing a predecessor during backlog migration is not a claim that its original scope was completed.

Already delivered — do not rebuild

The closed compute-profile classifier and RFC design exist, including stable refusal vocabulary and grammar tests. The latest issue audit does not establish a CPU reference runtime, working accelerator implementation or real hardware/driver conformance. PG-9 is no longer undecided, but its negative support/publication decision and the original dependency/evidence boundaries remain relevant.

Remaining implementation / execution

• Implement the admitted deterministic CPU reference semantics and the typed owned-device-buffer/effect/capability lifecycle for the existing bounded compute profile.
• Implement one explicitly selected accelerator backend and its exact shader/artifact/device-policy binding; reject unsupported operation/type/resource shapes.
• On real identified hardware, run CPU/device differential, transfer/bounds, cancellation/device-loss, stale-artifact and cleanup tests. Record driver/toolchain/provenance and reproducible resource observations.

Acceptance evidence

• At least one real accelerator executes the admitted kernels; a mock/simulator cannot satisfy the hardware gate.
• Exact equality claims are limited to the specified deterministic integer subset; floating-point portability is not invented.
• Ownership, failure and resource cleanup behave as specified under both successful and hostile execution.

Integration dependencies

• R09 / #305
• R16 / #294

These identify related acceptance work; safe independent implementation can proceed in parallel where the owning contracts permit it.

Boundaries

The existing design/admission work is not missing. Hardware provisioning and any external spend require explicit approval. A task description is not an authorization for provider spend, signing, publication, remote deployment or a change to support policy. Preserve existing stable identities, explicit profile limits, source authority and non-vacuous acceptance gates.

Evidence and implementation entry points

• Issue #210 update
• Repository entry point: docs/RFC-0005-COMPUTE-KERNEL-PROFILE.md (review at the pinned revision).
• Repository entry point: src/compute_profile/classifier.rs (review at the pinned revision).

Test results described above are retained repository evidence, not a fresh full test run performed by this backlog review. Re-run the owning gates for the implementation being accepted.

[wsdt]

Coordinator update (2026-09-23)

Status: blocked before CPU/accelerator implementation by missing executable semantics.

The current compute profile is an admission classifier: it has no value-bearing kernel IR/source binding, CPU executor/simulator, owned queue/buffer cleanup contract, or target dispatch. A new CPU module now would be a private mock. Final acceptance also depends on the R09/R16 candidate/evidence boundaries.

Next step: freeze executable kernel semantics/source binding and ownership/settlement, then select an exact accelerator API/toolchain/driver and authorized physical device. The issue remains open.