How the ckpt386 s0.10 release was made, tested, and selected.

The Short Claim

SignalLatch is a small behavior fine-tune merged into the already released Qwen3.6 AEON RYS 15/20 model line. The selected public artifact is a merged IQ4_NL GGUF file, not a live LoRA adapter.

What exactly was trained

The adapter was trained against the AEON RYS 15/20 HF-format base. The resulting release is not another RYS layer surgery pass; it is a behavior LoRA merged into the existing AEON RYS 15/20 model and then exported to the practical GGUF target.

Training data shape

The raw training dataset is not published with this release, so this page records the shape and supervision method rather than asking readers to trust a private file path.

Training method

Why merged GGUF, not live LoRA?

The final serving target uses the custom AEON ik-llama fork with graph split and flash attention. In this setup, live/native LoRA serving was not the stable deployment path we wanted to publish. The long-term release path became: merge the adapter into the model first, then export and quantize the merged model into the final GGUF file.

Artifact lineage

AEON RYS 15/20 HF base
  -> ckpt386 behavior LoRA
  -> merge at scale 0.10 in BF16
  -> BF16 GGUF
  -> IQ4_NL GGUF release file

Testing Journey

The testing was not a single clean benchmark. It was an engineering selection process. We started with small behavior checks and practical app-building probes, then moved toward the exact merged Q4_NL format we intended to release.

Early behavior probes

In the first response-style checkpoint eval, the raw checkpoints did not beat the base. This looked discouraging, but it was a scouting lane, not the final merged-GGUF serving path.

Early strength sweep

The next useful pattern was clear: full-strength LoRA was too aggressive. Lower strengths produced more useful behavior and longer, more complete outputs.

First exhaustive canvas matrix

The first practical canvas matrix tested all 36 combinations across checkpoints 210, 245, 250, 280, 300, 315, 350, 385, 386 and strengths 0.25, 0.50, 0.75, 1.00. No variant passed in that path. The distribution was:

The conclusion was not "the LoRA cannot work." The better conclusion was that the direct adapter/runtime path was not stable enough to judge the deployment artifact.

Merged BF16 GGUF canvas check

After merging the finalists into full GGUF models, the same practical canvas task changed the picture.

That result corrected the earlier negative read: the LoRA was useful when merged and served through the GGUF path.

The Deploy-Format Q4_NL Matrix

The final selection needed to answer one question: what should we actually upload and recommend? For that, we tested checkpoint 386 as merged IQ4_NL GGUF files across smaller strengths.

Each tested IQ4_NL file was approximately 16,554,833,600 bytes. The exact release file was renamed for public clarity as:

Qwen3.6-27B-AEON-RYS-SignalLatch-ckpt386-s010-IQ4_NL.gguf

Five practical code-agent patch tasks

The matrix used small but concrete repo-editing tasks with verifier checks. These were not broad public benchmarks; they were production-style checks for tool discipline, targeted fixes, and patch completion.

Scoring method

• Each task had a verifier that assigned a fractional score from 0.0 to 1.0.
• A strict pass only counted when the verifier marked pass=True.
• Timeout-like runs were tracked separately because stalled completion behavior matters for agent deployment.
• First-run results were not enough for selection; finalist strengths were repeated on the same five-task matrix.

Strength Selection

The first deploy-format sweep proved the LoRA helped, but it also showed why a one-run perfect score was not enough.

Task-level base versus selected s0.10

Repeat stability

After s0.20 and s0.25 produced perfect first runs, the finalists were repeated. That is where the selection changed.

Practical Canvas-Agent Test

We also tested the release candidate on a larger practical app task: build an isolated Krita-like raster canvas application with layers, brush and eraser, transforms, opacity, and a local-only AI image generation stub. The AI hook did not need to call a real Sloane service; it was a practical agent-completion test.

The canvas test is not a broad benchmark. It is useful because it exposed formatting reliability, timeout behavior, and whether a compressed model could still finish a real multi-file tool-style task.

Runtime Profile Used for Selection

The selected public runtime is the custom AEON ik-llama fork. The fine-tuned GGUF should be treated as an artifact for that fork, not as a stock llama.cpp compatibility claim.

./build/bin/llama-server \
  -m /path/to/Qwen3.6-27B-AEON-RYS-SignalLatch-ckpt386-s010-IQ4_NL.gguf \
  -c 65536 \
  -ngl 999 \
  -np 1 \
  -fa on \
  -sm graph \
  --temp 0.7 \
  --jinja \
  --reasoning-format deepseek \
  --reasoning-budget 0 \
  -cram 0 \
  --ctx-checkpoints 0

For the 131k canvas comparison, the same shape was used with a larger context and FP32 KV as an isolation setting:

-c 131072 \
  -ctk f32 \
  -ctv f32

Caveats and Boundaries

Evidence Included on This Page

This page intentionally embeds the relevant numbers rather than relying on local workspaces. The public evidence bundle in this directory remains useful for audit trails, but readers should not need private paths to understand the decision.