A valid kernel submission can still copy the input

The three model generations were actual GPU runs. The JSON, byte and provenance checks used retained records; no generated CUDA was compiled or executed in this sequence.

Our third development call finally returned the required JSON carrier. Its decoded CUDA source was byte-for-byte identical to the input.

That distinction is easy to lose if a pipeline records only one success field. A carrier is the JSON wrapper around source code and a launch descriptor. Passing its format check tells us the interface worked. It does not tell us that a repair happened.

Read the original Nodus research note.

Keep the failed attempts in the record

We used one deliberately modified, FlashInfer-derived BF16 RMSNorm fixture with Qwen2.5-Coder-7B-Instruct. These were adaptive development calls: we inspected each output before changing the next request.

Attempt	Change before the call	Retained output	Format result
1	Initial prompt; configured 60-second soft limit	602 tokens, including EOS; Markdown-fenced response with wrong outer fields	Rejected
2	Explicit protocol, source and nested launch; complete input carrier; same soft limit	765 tokens, no EOS; stops inside the source string	Rejected
3	Same explicit prompt; soft limit raised to 180 seconds	1,190 tokens, including EOS	Accepted after JSON repacking; source unchanged

The soft limits are configuration, not measured generation durations. Attempt 2's recorded stop reason was soft_time_or_other_stop; the exact stopping criterion was not captured.

The source, mathematical contract, fixed launch and strict extractor stayed unchanged. All three calls used the same pinned model and weight shards, BF16 weights, eager attention, greedy decoding and a 4,096-new-token limit. The observed runtime was an NVIDIA L4 with Transformers 4.57.1, Tokenizers 0.22.1 and Torch 2.9.0+cu130. Reusing the runtime image does not establish the same physical GPU.

Repacking JSON must not silently repair code

The extractor did not strip Markdown fences, rename keys or edit CUDA. On attempt 3 it changed only the JSON serialization. The resulting canonical carrier matched the original input exactly:

18dc7ef8e92a7efe2f1cf3735fc8f6b2e599d4bd79eb2707667f84e133d52c2c

The source hash also matched:

1f5053e0608172ed6540993f3025af026141e38f4e199cc51b3d6771f7817302

For this fixed-launch source-repair task, that comparison makes the absence of a source change explicit. If a task allows launch changes, compare those fields too. A source hash alone would miss that kind of change.

Inspect the saved evidence without running a model

Download the saved-byte package. It contains the selected DEV source and carrier, both prompts, all three raw responses and token-ID arrays, the retained final carrier, upstream notices and an original Python verifier.

After downloading and extracting the archive:

cd nodus-format-calibration-saved-bytes-v2
python3 -I -B verify_saved_bytes.py

The standard-library utility checks the frozen file hashes, strict JSON failures and exact source/carrier equality. The retained offline check reports two rejections and one valid carrier with unchanged source. It does not rerun Qwen, replay tokenizer decoding, compile CUDA or judge correctness. Hash consistency is not independent execution attestation.

The aggregate keeps all three outcomes and the changes between calls. The provenance distinguishes original owning records from the public projections in the archive.

What this observation leaves open

We deliberately removed a block barrier and changed the normalization divisor from H to blockDim.x in the input fixture. These were authored modifications. The model received no authentic compiler or runtime diagnostic. This exposed DEV lineage is excluded from training and held-out confirmation claims.

Three adaptive calls on one fixture are not independent replicates or a model repair score. The valid final carrier did not establish compilation, numerical correctness, memory safety, synchronization safety or training usefulness. No throughput, provider comparison, cost-per-result or training-uplift claim follows.

For a kernel-data evaluation, retain three separate fields: carrier validity, the proposed source/launch change, and independently judged program correctness. Keep the raw evidence behind each one.

Source credit: the fixture derives from FlashInfer's ordinary RMSNormKernel at commit 023a8474, with its Apache-2.0 license, copyright and modification notices retained. The model was Qwen2.5-Coder-7B-Instruct at revision c03e6d35. No upstream endorsement is claimed.