NON_GPT_OSS_GEMMA4_PILOT.md

Non-GPT-OSS Gemma 4 Pilot

Status: published_bounded_lane on 2026-04-02 after issues #864, #865, and #866; #867 then added one optional dense 31B validation lane that reuses the same family contract without widening the original published claim; #880 then closed the first trainer-to-serving promoted- revision seam for the bounded gemma4:e4b lane; #895 then replaced the old proxy-only distributed proof with one real split-execution proof for gemma4:e4b; #892 then promoted gemma4:26b from topology-only sparse publication into admitted sparse distributed execution when the generic server is given a real multi-node sparse schedule; #896 then turned the old Metal refusal-only contract into live native Apple-Silicon execution and added one live mixed-device metal+cuda split-execution proof; #942 then admitted one bounded single-node gemma4:26b text lane on the generic server for CUDA and Metal, keeping the sparse distributed schedule as an optional extension instead of the entry requirement.

This document freezes what the first honest Gemma 4 claim means and now records the published first lane.

It still does not mean that the whole Gemma 4 family is implemented on this checkout.

The pilot row is the local e4b artifact at:

• default path: /Users/christopherdavid/models/gemma4/gemma4-e4b-ollama.gguf
• canonical model id: gemma4:e4b

Frozen First Target

The first target artifact is:

• artifact = gemma4:e4b
• family shape = dense Gemma 4
• intended runtime posture = Psionic-owned CUDA-backed text generation

This is the first useful target because it is already available as a real GGUF artifact, it avoids the current non-GptOss MoE gate, and it is large enough to exercise real prompt, routing, and long-context behavior without forcing the first claim to absorb the whole Gemma 4 family.

Frozen First Claim

The first bounded Gemma 4 claim for Psionic is:

• one dense Gemma 4 text lane
• one exact artifact target: gemma4:e4b
• one accelerator target: CUDA
• one server surface: the generic OpenAI-compatible server
• one bounded Gemma-native tool-call and response-state contract

When this lane is implemented, the publication bar is:

• backend = cuda
• execution_mode = native
• execution_engine = psionic
• refusal-required unsupported regions stay explicit in capability and health publication

Published Lane

Psionic now publishes exactly one bounded dense Gemma 4 lane:

• artifact = gemma4:e4b
• family shape = dense only
• accelerator = CUDA
• runtime = native Psionic GGUF runtime
• local server surface = generic OpenAI-compatible server
• admitted request surfaces = /v1/chat/completions and /v1/responses
• admitted publication surfaces = /health, /v1/models, and response headers
• bounded tool contract = Gemma-native <|tool_call>call:<tool>{...}<tool_call|> blocks with JSON-schema-subset argument validation and replayable tool-result state on /v1/responses
• published multimodal posture = one processor_owned image/video lane that refuses direct media URL parts on the current generic OpenAI surface
• published audio posture = one processor_owned audio lane on e2b and e4b only, with input_audio publication and explicit refusal on the current generic OpenAI surface until a real audio processor lands
• distributed proof surface = one real pipeline_sharded gemma4:e4b execution path across two CUDA machines, plus one live mixed-device pipeline_sharded path with a Mac Metal prefix stage and a remote CUDA suffix stage, with request headers and receipts that publish the realized clustered topology

This published lane is not the claim "Psionic supports Gemma 4" in the broad sense. It is the smaller claim that Psionic can admit one dense Gemma 4 artifact, execute it natively on CUDA, execute one real split request across multiple CUDA machines, keep the old remote-proxy path explicit as just proxying, and keep unsupported regions refused instead of widening the claim by implication.

Second Dense Validation Lane

After #867, the repo also carries one second dense validation lane for Gemma 4 31B.

That lane is deliberately narrower than a second publication claim:

• artifact class = dense 31B
• operator hook = PSIONIC_GEMMA4_31B_PILOT_GGUF_PATH
• prompt contract = the same checked-in gemma4_e4b family fixture and bounded text template
• backend publication contract = the same backend = cuda, execution_mode = native, and execution_engine = psionic truth
• refusal contract = the same explicit refusal for structured outputs and the processor-owned image/video lane as on e4b

What this means:

• Psionic can validate a larger dense Gemma 4 workstation artifact against the same family contract it already publishes for e4b.
• Psionic does not, by doing this, widen the first public claim from gemma4:e4b to the whole dense family.
• 31B stays a validation lane until we decide to publish it separately.

Processor-Owned Multimodal Lane

After #868, dense Gemma 4 artifacts that publish vision facts now carry one explicit multimodal lane on the generic server:

• multimodal_projection_mode = processor_owned
• accepted media labels = image, video
• current surface posture = explicit refusal for direct media URL parts

What that means:

• Psionic no longer pretends the dense text prompt lane can consume image or video inputs.
• Psionic still does not claim native image or video understanding on Gemma.
• direct media parts now fail with a processor-lane refusal instead of a vague generic prompt-render refusal.

Processor-Owned Audio Lane

After #869, only dense Gemma 4 e2b and Gemma 4 e4b artifacts that publish audio facts now carry one separate audio lane on the generic server:

• audio_input_mode = processor_owned
• accepted request parts = input_audio
• current surface posture = explicit refusal for direct input_audio parts

What that means:

• Psionic now publishes that e2b and e4b have a distinct processor-owned audio path instead of pretending audio is either generally supported or generally absent across the dense family.
• Psionic still does not claim native audio execution on the current generic OpenAI surface.
• 31B and 26B A4B do not inherit this audio publication by implication.
• direct input_audio parts now fail with an explicit processor-lane refusal on the admitted e2b and e4b rows, while non-admitted dense variants fail closed without publishing audio capability at all.

Metal Lane Contract

After #872, the generic OpenAI-compatible server also publishes one explicit Gemma 4 Metal lane contract:

• backend = metal
• execution mode = native
• execution engine = psionic
• residency mode = metal_accelerated
• fallback policy = refuse
• current execution posture = live native single-node execution on Apple Silicon for dense gemma4:e4b
• mixed-device posture = one admitted metal+cuda split path when the Mac front is given one reachable CUDA suffix peer

What that means:

• Psionic now treats Gemma on Metal as a first-class contract surface instead of leaving Apple Silicon behavior implied or undefined.
• /health and /v1/models publish the same backend, execution, and refusal truth that the server will actually enforce at request time.
• /v1/chat/completions and /v1/responses now execute honestly on the single-node Metal path instead of silently falling back to CPU or CUDA.
• the same Mac row can also become one real split-execution front for a remote CUDA suffix worker without pretending the whole request stayed local.

Sparse 26B Single-Node Lane

After #942, the generic OpenAI-compatible server also admits one bounded single-node sparse Gemma 4 26B A4B text lane:

• model id = gemma4:26b
• artifact class = quantized sparse GGUF; the retained benchmark and operator examples use gemma-4-26B-A4B-it-Q4_K_M.gguf
• admitted backends = cuda, metal
• topology = one local host, no distributed sparse schedule required
• runtime = native local Gemma runtime on the generic OpenAI-compatible server
• admitted request surfaces = /v1/chat/completions and /v1/responses
• publication posture = the same sparse-topology truth still appears on /health, /v1/models, routed inventory, and mesh management status
• hardware expectation = the chosen host must be able to admit the full quantized sparse artifact plus active KV cache locally; if not, the server must fail closed or the operator must admit the distributed sparse schedule instead
• distributed extension = if the operator later admits a real sparse schedule, the same row widens into tensor_sharded sparse execution instead of pretending that single-node and clustered execution are the same lane

What that means:

• Psionic can now honestly say that gemma4:26b text inference works on one host through the generic server.
• Psionic still does not widen that into multimodal, audio, structured-output, or training claims for sparse Gemma.
• The distributed sparse path remains useful, but it is no longer the entry condition for gemma4:26b text serving.

Explicit Non-Goals

The first Gemma 4 claim does not include:

• admitted image execution on the processor-owned lane
• admitted video execution on the processor-owned lane
• admitted audio execution on the processor-owned audio lane
• 31B Dense
• broader gemma4:26b support beyond the admitted single-node text lane and optional admitted distributed sparse extension
• full parity with llama.cpp
• full parity with ollama

CPU-only bring-up may still be useful as a debug lane, but CPU alone does not complete the first published Gemma 4 milestone.

Current Repo State

After issues #861 through #866, the repo now has the first honest published Gemma 4 admission, runtime, bounded mesh validation, and conformance work:

• psionic-models now classifies general.architecture = gemma4 as its own decoder family instead of silently aliasing it to llama, qwen, or another generic family.
• the local gemma4:e4b GGUF tokenizer facts are now fixture-covered, including the Gemma-specific turn, tool-call, tool-response, and channel tags.
• dense Gemma 4 artifacts classify cleanly, and the generic server now also admits one bounded single-node sparse gemma4:26b text lane on CUDA and Metal while keeping the broader expert-family contract explicit.
• the local e4b GGUF does not currently embed tokenizer.chat_template, so the repo now carries one checked-in bounded text template fixture at crates/psionic-models/src/testdata/gemma4_chat_template.jinja.
• psionic-serve now has a first bounded native Gemma 4 CUDA runtime for quantized dense projection artifacts, using the Psionic-owned tokenizer, prompt, KV-cache, and decode loop instead of routing through llama.cpp.
• the generic OpenAI-compatible server now admits Gemma 4 on CUDA with backend = cuda, execution_mode = native, and execution_engine = psionic, and the bounded lane now stamps both x-psionic-backend and x-psionic-served-backend as machine-checkable backend labels across both /v1/chat/completions and /v1/responses.
• the same bounded lane now admits Gemma-native tool calling on both server surfaces through explicit <|tool_call>call:<tool>{...}<tool_call|> blocks instead of borrowing the tagged-JSON Qwen or GPT-OSS contract.
• /v1/responses now stores replayable Gemma assistant tool-call turns and projects replayed tool results back into one explicit user-side tool_responses turn instead of failing the continuation surface closed.
• the repo now has bounded prompt-render, health/model publication, and refusal coverage for the Gemma 4 CUDA lane, including explicit fail-closed checks for structured outputs and the processor-owned image/video refusal lane.
• the conformance harness now accepts the real gemma4:e4b fixture shape and the repo now carries one repeatable gemma4:e4b CUDA conformance repeat test that runs when both the pilot GGUF and a CUDA host are available.
• the same bounded family contract now also has one optional dense 31B validation repeat and one optional real-artifact tokenizer and prompt-render check, both keyed off PSIONIC_GEMMA4_31B_PILOT_GGUF_PATH.
• the same gemma4:e4b lane now also has one first real split-execution proof: the repo carries a machine-checkable pipeline_sharded Gemma request across two CUDA workers, plus matching response headers and receipt surfaces that publish cluster_disposition = sharded and cluster_topology = pipeline_sharded.
• the generic OpenAI-compatible surfaces now also publish family-agnostic clustered execution truth for Gemma 4 instead of forcing downstream consumers to infer it from route details:
  • /health and /v1/models now expose generic execution modes such as dense_split, sparse_expert, remote_whole_request, and replicated
  • the same rows also expose generic topology kinds such as pipeline_sharded and tensor_sharded
  • routed inventory and mesh management status additionally carry the runtime-owned cluster capability profile for the admitted multi-machine path on that row
• the older bootstrap-mesh path is still useful, but it now stays explicitly classified as remote whole-request proxying instead of being treated as the distributed proof.
• the same generic server now also has one admitted sparse gemma4:26b execution ladder above the existing topology-publication surface: single-node /v1/chat/completions and /v1/responses now execute locally on CUDA and Metal without a distributed schedule, and an operator can still admit one real multi-node sparse schedule to widen that same row into tensor_sharded clustered execution together with selected-node truth, request-specific expert-routing diagnostics, published shard artifact cache truth, and conversation-local sticky placement on /v1/responses.
• the managed dense-GGUF lane now allocates whole-model KV-cache width instead of silently falling back to one-layer fixture geometry, and the repo now carries a multi-layer regression that keeps that boundary explicit.
• the live gemma4:e4b CUDA lane now respects Gemma 4's mixed per-layer attention geometry, including narrower sliding-window layers and wider full-attention layers, instead of assuming one uniform KV shape across the whole stack.
• the same live gemma4:e4b lane now also fixes the prompt path that had left the real local Ollama GGUF in a half-wired state:
  • if the artifact omits tokenizer.chat_template, Psionic now falls back to the checked-in bounded Gemma 4 template instead of collapsing to the raw plain-text fallback prompt
  • rendered Gemma prompts now flow into generation as token IDs, so literal <bos> text in the rendered template does not get retokenized into a duplicated BOS boundary
  • the SentencePiece runtime now preserves Gemma-special tokens, byte fallbacks, and whole-piece preference closely enough to match the real tokenizer fixture and produce live grammatical output instead of prompt echo or gibberish
• with those fixes in place, the live 4080 CUDA server now answers a real /v1/chat/completions request for gemma4:e4b with a grammatical English sentence rather than prompt replay. The bounded proof prompt Reply with exactly one short grammatical English sentence. returned The cat slept soundly on the warm rug. on 2026-04-03.
• the same real gemma4:e4b artifact now also answers that same bounded /v1/chat/completions prompt on the native Metal path on macOS, returning The cat slept soundly on the warm rug. on 2026-04-03.
• the same bounded prompt now also completes as one live mixed-device split-execution request on 2026-04-03, with a Mac Metal prefix stage and a Tailnet RTX 4080 CUDA suffix stage returning The cat slept soundly on the warm rug. together with psionic_cluster_execution.disposition = sharded, execution_topology.kind = pipeline_sharded, and execution_topology.effective_backend = metal+cuda.
• the same bounded gemma4:e4b lane now also accepts typed promoted adapter revisions from the Gemma trainer without restart, revalidates checkpoint and adapter truth before activation, surfaces the active served revision in response provenance, and preserves rollback to the last known-good revision.

The training side now also has one bounded real trainer above that serving lane across crates/psionic-train/src/gemma_e4b_finetuning_mvp.rs and crates/psionic-train/src/gemma_e4b_cuda_adapter_sft.rs. That surface freezes the first admitted gemma4:e4b finetuning family as one CUDA-only LM-head adapter-SFT lane with rank 8 / alpha 16, stable tokenizer plus base-revision truth, served-base compatibility checks, typed safetensors export, exact checkpoint resume, and explicit refusal truth.

That same bounded lane now also has the first real trainer-to-serving refresh surface in crates/psionic-serve/src/gguf.rs:

• one typed promoted-revision import path for Gemma exported adapter artifacts plus exact trainer checkpoints
• one fail-closed revalidation gate for base-model identity, served-artifact digest, tokenizer contract, compatibility digest, and checkpoint integrity
• one active served-revision identity packet on generation provenance
• one rollback path to the last known-good promoted revision without requiring a restart of the bounded lane

The same bounded lane is now also quality-gated instead of trainer-first across crates/psionic-eval/src/gemma_e4b_finetune_eval_pack.rs and crates/psionic-train/src/gemma_e4b_finetune_eval.rs:

• one canonical held-out eval pack for the bounded finetune claim
• one dataset contract that requires exact train, held_out_validation, final_report, and baseline_short split refs, the checked-in prompt template digest, full assistant-response masking, and explicit overlap plus decontam review truth
• one short baseline-sweep mode that compares small candidate configurations on held-out validation loss before full-budget promotion
• one typed eval-receipt surface for the untuned base and checkpoint candidates, including automatic clearance over prompt-template, mask, tool- use, formatting, and steerability checks
• one canned promoted-checkpoint vibe-review packet plus operator review state
• one promotion decision that refuses held-out regression against the untuned base and does not silently promote without positive operator review

What still does not exist:

• no admitted image or video execution on the Gemma processor-owned lane
• no admitted audio execution on the Gemma processor-owned audio lane
• no generic structured-output Gemma surface
• no broader Gemma finetuning platform claim beyond the bounded e4b CUDA adapter-SFT lane
• no RL-first, DPO-first, or full-model Gemma finetuning claim
• no broader published support claim beyond the bounded dense e4b CUDA lane, one real dense split-execution proof, one admitted single-node sparse gemma4:26b text lane plus its optional admitted distributed extension, the live Metal Gemma contract, routed mesh publication, repo-owned conformance coverage, and the optional 31B validation repeat

Canonical Repeat

The published lane is repeatable through repo-owned tests.

Documented local validation:

cargo test -p psionic-runtime \
  local_multi_device_plan_runner_executes_gemma4_pipeline_sharded_workload_with_direct_handoff \
  --manifest-path Cargo.toml --no-default-features
cargo test -p psionic-provider \
  text_generation_receipt_surfaces_gemma4_pipeline_sharded_cluster_execution_truth \
  --manifest-path Cargo.toml --no-default-features
cargo test -p psionic-cluster \
  realized_sparse_cluster_execution_attaches_live_route_proof \
  --manifest-path Cargo.toml --no-default-features
cargo test -p psionic-cluster \
  sparse_shard_materialization_reuses_cached_artifacts \
  --manifest-path Cargo.toml --no-default-features
cargo test -p psionic-serve \
  generic_cuda_gemma4_26b_load_plan_admits_single_node_sparse_native_runtime \
  --manifest-path Cargo.toml --no-default-features
cargo test -p psionic-serve \
  generic_metal_gemma4_26b_load_plan_admits_single_node_sparse_native_runtime \
  --manifest-path Cargo.toml --no-default-features
cargo test -p psionic-serve \
  generic_server_gemma4_26b_single_node_lane_executes_on_cuda_without_sparse_schedule \
  --manifest-path Cargo.toml --no-default-features
cargo test -p psionic-serve \
  generic_server_gemma4_26b_single_node_lane_executes_on_metal_without_sparse_schedule \
  --manifest-path Cargo.toml --no-default-features
cargo test -p psionic-serve \
  generic_execution_headers_surface_gemma4_pipeline_cluster_truth \
  --manifest-path Cargo.toml --no-default-features
cargo test -p psionic-serve \
  generic_server_gemma4_26b_sparse_lane_executes_when_schedule_is_admitted \
  --manifest-path Cargo.toml --no-default-features
cargo test -p psionic-serve \
  generic_server_gemma4_26b_sparse_responses_keep_conversation_bound_to_same_placement \
  --manifest-path Cargo.toml --no-default-features
cargo test -p psionic-serve conformance --manifest-path Cargo.toml --no-default-features
cargo test -p psionic-serve gemma4 --manifest-path Cargo.toml --no-default-features

Real-artifact repeat lane:

PSIONIC_GEMMA4_PILOT_GGUF_PATH=/abs/path/to/gemma4-e4b-ollama.gguf \
  cargo test -p psionic-serve \
  gemma4_e4b_cuda_conformance_repeat_is_machine_checkable_when_available \
  --manifest-path Cargo.toml --no-default-features

Optional second dense validation repeat:

PSIONIC_GEMMA4_31B_PILOT_GGUF_PATH=/abs/path/to/gemma4-31b.gguf \
  cargo test -p psionic-serve \
  gemma4_31b_cuda_conformance_repeat_is_machine_checkable_when_available \
  --manifest-path Cargo.toml --no-default-features

Optional real-artifact tokenizer and prompt-render checks for that same lane:

PSIONIC_GEMMA4_31B_PILOT_GGUF_PATH=/abs/path/to/gemma4-31b.gguf \
  cargo test -p psionic-models gemma4_31b --manifest-path Cargo.toml --no-default-features

Repo-owned benchmark harness:

cargo run -p psionic-serve --example gemma4_bench -- \
  --model-path /abs/path/to/gemma-4-e2b-it-Q8_0.gguf \
  --mode single \
  --backend metal \
  --json

cargo run -p psionic-serve --example gemma4_bench -- \
  --model-path /abs/path/to/gemma-4-e4b-it-Q4_K_M.gguf \
  --mode distributed-dense \
  --peer-base-url http://127.0.0.1:18080 \
  --split-layer 21 \
  --json

cargo run -p psionic-serve --example gemma4_bench -- \
  --model-path /abs/path/to/gemma-4-31B-it-Q4_K_M.gguf \
  --mode single \
  --backend cuda \
  --json

cargo run -p psionic-serve --example gemma4_bench -- \
  --model-path /abs/path/to/gemma-4-26B-A4B-it-Q4_K_M.gguf \
  --mode single \
  --backend metal \
  --json

cargo run -p psionic-serve --example gemma4_bench -- \
  --model-path /abs/path/to/gemma-4-26B-A4B-it-Q4_K_M.gguf \
  --mode distributed-sparse \
  --json

That harness prints or writes one machine-readable benchmark receipt with:

• load seconds
• total seconds
• time to first token
• output-token count
• decode tokens per second
• backend and topology truth

The supported benchmark matrix is explicit:

• gemma4:e2b: dense single-node
• gemma4:e4b: dense single-node and dense split execution
• gemma4:31b: dense single-node and dense split execution
• gemma4:26b: single-node sparse text on Metal or CUDA, plus admitted distributed sparse execution

The harness refuses unsupported combinations instead of pretending every Gemma 4 row is interchangeable.

Current official-artifact support on main is wider than the original retained pilot cut:

• the GGUF tokenizer path now admits official gemma4 tokenizer metadata
• dense Gemma 4 inspection and load now tolerate the real official per-layer metadata shape, including per-layer feed-forward widths, per-layer KV-head counts, V := K layers, and true reused-KV layers
• the official ggml-org e2b and 31b artifacts now load and benchmark on local Metal instead of failing at tokenizer admission
• the official 26B-A4B artifact now runs through the admitted sparse benchmark harness on local Metal instead of failing immediately on unsupported GGUF metadata or unsupported Q5_0 execution, and the same harness now also admits the bounded single-node --mode single sparse text lane on Metal or CUDA

One honest boundary remains:

• the admitted 26B-A4B sparse execution lane on Apple silicon is still a fallback-heavy path because unsupported Metal quantized rows now run through the host quantized projection path rather than a native Metal kernel
• that means the lane is now honest and benchmarkable on one Mac, but it is not yet the performance ceiling for sparse Gemma 4 on Apple hardware
• after porting explicit expert-range prefaulting and parallel selected-expert accumulation into the sparse host path, current local receipt on main for gemma-4-26B-A4B-it-Q4_K_M.gguf --mode distributed-sparse --backend metal is now: load 30.7238 s, total 12.4447 s for 16 output tokens, about 1.286 tok/s end-to-end
• the retained earlier local Metal sparse receipt on this same lane was 43.0130 s for 16 output tokens, about 0.372 tok/s, so the current path is about 3.46x faster end-to-end on the same admitted benchmark shape

Those runs are the current publication bar. They prove:

• bounded prompt-render and fixture alignment for the real gemma4:e4b instruction-first shape
• dense Gemma 4 family admission plus one bounded sparse gemma4:26b single-node text lane instead of a blanket expert-family refusal
• native CUDA and Metal load planning for the admitted sparse gemma4:26b single-node lane
• honest generic-server publication with:
  • backend = cuda
  • execution_mode = native
  • execution_engine = psionic
• admitted /v1/chat/completions and /v1/responses execution on the bounded lane
• admitted /v1/chat/completions and /v1/responses execution on the single-node sparse gemma4:26b lane without requiring a distributed sparse schedule first
• admitted Gemma-native tool calling with JSON-schema-subset argument validation and replayable response-state storage
• explicit refusal for:
  • structured outputs
  • direct image or video media URL parts on the processor-owned lane
• repeatable real-artifact CUDA conformance against the local e4b GGUF when both the artifact and a usable CUDA host are present
• optional repeatable validation against a local dense 31B GGUF when that artifact is supplied explicitly
• one real split-execution Gemma proof across two CUDA workers, with machine-checkable receipt and header publication for the clustered topology
• one live single-node native Metal proof on the real e4b GGUF
• one live mixed-device split-execution proof on the real e4b GGUF, with a Mac Metal front and a remote RTX 4080 CUDA suffix worker
• bootstrap-routed mesh publication that keeps remote Gemma 4 route truth explicit instead of widening the thin-client claim into split execution
• family-agnostic publication of clustered execution mode and topology on /health, /v1/models, routed inventory, and mesh management status, so downstream consumers can tell the difference between proxying, replication, dense split execution, and sparse expert execution without family-specific heuristics

Pass Criteria

The pilot stays green only if all of the following remain true:

• gemma4:e4b is still admitted as dense gemma4
• the bounded text template remains aligned to the real e4b tokenizer facts
• the native CUDA runtime still loads the dense GGUF lane without silently degrading to another family or engine
• the generic server still publishes truthful backend, execution-mode, and execution-engine metadata
• the generic server still admits /v1/chat/completions and /v1/responses
• Gemma-native tool calling still produces machine-checkable tool calls on the admitted lane
• structured outputs still fail closed on the published lane
• the generic server still publishes processor_owned for Gemma image/video media and still refuses direct media URL parts explicitly
• split-execution publication keeps cluster_disposition = sharded and cluster_topology = pipeline_sharded machine-checkable on the bounded proof path
• family-agnostic clustered execution publication still distinguishes remote whole-request proxying from the true split dense proof and from the admitted sparse expert path
• mesh bootstrap publication keeps routed remote truth explicit and does not borrow a local host's wider endpoint claim
• when PSIONIC_GEMMA4_31B_PILOT_GGUF_PATH is supplied, the dense 31B validation lane still matches the same tokenizer, prompt, backend-truth, and refusal contract instead of forking the family semantics
• gemma4:26b now publishes sparse-topology truth while still admitting one local single-node text lane on CUDA and Metal by default
• that same gemma4:26b row can still cross into admitted distributed execution with machine-checkable clustered receipts instead of falling back to a generic unsupported-family error

Why The Claim Is Narrow

Gemma 4 is a family, not one model. The first useful Psionic result is not "supports Gemma 4" in the broad sense. The first useful result is a narrow, truthful set of lanes that proves Psionic can admit one dense Gemma 4 artifact, one sparse gemma4:26b single-node text lane, the bounded split and distributed extensions above those rows, and publish exactly what still remains unsupported.

That bounded claim keeps later work cleanly separated:

• admitted image and video execution on the processor-owned lane
• audio support for E2B and E4B
• generic structured outputs
• wider non-GptOss MoE family admission
• Metal and other accelerator parity
• any future decision to promote 31B from validation-only into its own published support claim

Follow-On Issues

This claim freeze is the prerequisite for the next runtime issues:

1. family and prompt classification
2. dense CUDA runtime bring-up
3. server and conformance coverage
4. mesh validation
5. bounded publication of the finished first lane