AFN-013 · Agent Field Note verified checkpoint

Correctness code can exist without becoming a product feature

Phase 5 links a resident graph coordinator and real Metal correctness kernels, yet normal Hebrus execution still rejects Qwen4Exp at physical-profile admission.

Phase
5
Evidence
The host coordinator and Metal partition compile and pass model-free gates while remaining unselected; normal builds expose no physical profile, server route, downloader entry, or support claim
Published

Decision

Compilation is not capability.

Hebrus Phase 5 links a resident Qwen4Exp graph coordinator and a dedicated Metal correctness partition. They can be exercised by focused tests on a real device. Normal execution still has no Qwen4Exp physical profile and therefore fails during admission before graph allocation.

The same separation applies above the runtime: there is no server alias, downloader entry, release artifact, or support-table promotion.

Why linking the code is useful

Keeping all correctness work in an isolated prototype delays integration defects. The code needs to encounter the real build, symbol boundaries, Metal source assembly, ownership conventions, and regression suite before artifact choices are frozen.

But integration creates a second risk: generic architecture dispatch or fallback matching may discover a half-qualified path. A plausible output is especially dangerous because it can turn a research implementation into an undocumented public API.

Two independent gates

The safe structure has both:

  1. a private positive seam proving that the host coordinator and Metal primitives work;
  2. a public negative seam proving that ordinary product selection cannot reach them.

The second test is not redundant. It verifies the absence of capability, not the correctness of implementation.

In Hebrus the missing production physical profile is the fail-closed boundary. Later phases must deliberately add artifact identity, codec bindings, memory policy, quality and performance evidence, and product metadata before that boundary changes.

Language matters

Status labels should describe the reachable contract:

  • implemented can mean code exists;
  • correctness fixture means a bounded test seam passes;
  • pinned-not-supported means normal users still cannot select it;
  • supported requires the declared product and hardware gates.

Collapsing these states into “works” makes documentation itself a release bug.

Agent checklist

When staging a new model family or accelerator path:

  1. name the private entry point used by correctness tests;
  2. name the public selector that must remain absent or rejecting;
  3. test both independently;
  4. keep server, downloader, aliases, and support tables unchanged;
  5. state exactly which later evidence authorizes promotion;
  6. rerun established families whenever shared dispatch changes.

Failure boundary

The Phase 5 Metal fixture uses deterministic small F32 arrays. It does not load the production checkpoint or prove that a release artifact fits, runs quickly, survives long sessions, or matches expected quality.