How SignalLatch v1.1 Lite and Plus were selected.

Exact candidate recipes behind the public files

The public filenames hide the internal recipe details, so they are reproduced here. These are the exact candidate recipes that became the two uploaded v1.1 files.

The mixed-quant combinations began as manual tensor-group recipes, not as a black-box automatic quantizer search. We chose meaningful groups from the model structure, such as full-attention Q/K/V/O, full-attention output, token/output tensors, RYS 15..24 signal-path tensors, RYS FFN tensors, duplicate-boundary tensors, and late FFN control tensors, then assigned ik-llama quant types to those groups and expanded the resulting families for testing.

What this release is, in plain terms

This page is written as a self-contained production record. A reader does not need the private build folders, server logs, or internal notes to understand what was tested and why these two files were uploaded.

Terms used below

Count accounting

The numbers on this page separate screening runs from production-style real-world runs. The hard-suite count used for the public decision is the stable promotion summary: 163 candidate runs multiplied by 12 core prompt tasks, for 1,956 prompt-level scored results. Later workspace aggregates contain additional replay/recursive artifacts; those were useful for investigation, but they were not treated as independent public release votes.

The real-world phase used 32 ClawCode harness runs across three project tasks. Those runs produced 564 verifier component checks: 11 KritaLite runs times 15 components, 8 SyncBoard runs times 19 components, and 13 legacy-codebase migration runs times 19 components.

The behavior target

The fine-tune was aimed at a natural coding-agent workflow: a user gives an implementation direction, not a complete patch. The model should inspect the repository, infer the architecture, choose a narrow production slice, edit carefully, run verification, and revise from failures.

• Review before editing: inspect the codebase and existing architecture before making changes.
• Instruction latching: keep user constraints active across a long session instead of drifting into a generic answer.
• Tool-shaped reasoning: turn reasoning into concrete file reads, commands, tests, and focused edits.
• Evidence-first repair: use failing tests, logs, and verifier output to decide the next patch.
• Scope control: avoid broad rewrites, dependency churn, and unrelated file changes.
• User-change preservation: never revert unrelated work; work with dirty files when needed.
• Calibrated uncertainty: avoid claiming a candidate is proven better when the evidence is mixed.
• Completion discipline: summarize what changed, what was tested, and what risk remains.

Sequential process

The process was deliberately conservative: keep the known-good reasoning/coding path as the anchor, then test whether new mixed quantization patterns preserved the SignalLatch behavior habits in realistic coding-agent work.

Test design

The tests were split into two layers. The first layer was a fast reasoning/habit gate that could screen many quantization candidates. The second layer was a real-world ClawCode harness that forced candidates to act like coding agents inside project folders.

Layer 1: hard reasoning and SignalLatch habit gate

The hard-suite gate used 12 prompt tasks. It was not meant to replace coding tests; it was used to eliminate candidates that lost the fine-tuned process habits or basic hard reasoning before spending hours on project runs.

The prompt-suite scores are normalized automated screening scores from 0.0 to 1.0. The weighted score used for candidate narrowing was 0.50 * habit_score + 0.35 * hard_score + 0.15 * mean_score - 0.05 * errors. This weighting deliberately favored SignalLatch behavior retention over raw puzzle-score leadership.

How the prompt-suite score was computed

Exact tasks checked answer patterns plus required terms. Rubric tasks checked named behavior categories, with penalties for very short answers, forbidden terms, and excessive repeated 5-grams. This made the suite useful for broad automated screening, but the final release decision still depended on the real-world codebase harnesses.

Comprehensive-suite additions

The later comprehensive summary used the same 12 core tasks plus four long-context retention tasks. These additional tasks are why the supplement has a separate 440-row comprehensive table.

Layer 2: real-world ClawCode harnesses

The real-world tests were designed to be closer to a human asking an agent to build or modify something in a project, rather than a benchmark prompt that names every target file and every implementation detail.

Verifier components

These are the public scoring categories used to interpret the project runs. The private source files are not needed to understand the result tables below.

Prompt transparency

The prompts below are included so the page is readable without access to our local harness folders.

In the third prompt, "SLOANE OS" refers to a private legacy agent-system repository used as a realistic existing-codebase target. The public relevance is the task shape: a nontrivial migration inside an already-existing codebase with constraints, tests, and old behavior that must be preserved.

You are working in a small browser paint application called KritaLite.

The project is intentionally incomplete. Fix it as a production-quality patch, not as a test-only patch. Keep the current file structure unless a focused helper makes the implementation clearer.

Core goals:

1. Implement the raster document engine in src/kritalite.js.
   - Layers must preserve order, visibility, opacity, blend mode, lock state, names, and pixels.
   - Compositing must support normal, multiply, and screen blend modes with layer opacity and source alpha.
   - Brush strokes must interpolate between points, support size, color, opacity, and optional selection clipping.
   - Eraser strokes must reduce alpha instead of painting white.
   - Flood fill must respect tolerance and the active selection.
   - Selection copy, paste, and transform must preserve pixel data and clip to the document bounds.
   - Undo and redo must be deterministic, deep-copy document state, and cover drawing, layer changes, selection changes, paste, fill, and transforms.
   - Serialization/deserialization must round-trip the complete document state with a version marker.

2. Keep the browser UI contract in index.html and src/app.js.

3. Run the visible tests with npm test.

There is also a hidden verifier. Do not delete tests, avoid hard-coded answers, do not vendor dependencies, and keep the solution scoped to KritaLite.

Build the SyncBoard app in this repository.

The goal is a local-first project board that can be used offline. Keep the app small and focused. Do not add external dependencies or a backend.

Required deliverables:
- Implement src/syncboard.js.
- Keep index.html, styles.css, and src/app.js usable as a simple browser UI.
- Keep the existing visible tests intact.
- Use plain JavaScript and Node-compatible CommonJS exports.

Required core API:
- createBoard, addColumn, addCard, updateCard, moveCard, deleteCard
- undo, redo, filterCards, exportBoard, importBoard
- mergeBoards, replayActivity

Behavior requirements:
- Preserve card IDs across moves, export/import, undo/redo, and merge operations.
- Clip out-of-range move indices.
- Undo/redo must cover add/update/move/delete operations.
- Filtering must support text, labels, dueBefore, dueAfter, and archived.
- Import must throw on invalid JSON or invalid board shape.
- Activity log IDs must be deterministic and look like evt-000001.
- Merge must preserve non-conflicting edits, report same-field conflicts, and let deletion win over edit/move conflicts.

Before finishing, run npm test and fix failures.

I have an issue in this legacy SLOANE OS repo.

The memory architecture is still too RAGFlow-heavy, and the compiled/general-knowledge path does not keep deterministic source proof strongly enough. I want the next production slice of the migration toward:

- SimpleMem for session continuity and user/project memory.
- An object/item indexer for immutable local bytes, references, chunks, and evidence packets.
- A secondary hard-facts lane for deterministic claim verification.

Please work agentically:

1. Explore the repo first and infer the existing architecture before editing.
2. Review the safest narrow production slice to implement.
3. Implement that slice.
4. Add focused tests or a runnable verification path.
5. Run what you can, then refine based on failures.

Constraints:

- Do not remove, disable, or rewrite the existing RAGFlow path.
- Preserve current defaults unless the new behavior is explicitly feature-flagged or opt-in.
- Treat SimpleMem as continuity memory, not source proof.
- Hard facts must be backed by local evidence packets or immutable item references.
- Avoid API-model/LLM dependencies in deterministic indexing, compiling, or claim-verification paths.
- Keep the change scoped. Do not do a broad architecture rewrite.

Leave a concise final summary covering what changed, what files matter, what tests you ran, and any remaining risks.

Score evidence

Each harness measures a different failure mode. The final decision did not come from a single table. The selected files had to survive multiple task shapes without losing the intended SignalLatch behavior.

How to read the scores

A score such as 14/15 means the verifier found 14 passing components out of 15. The components include visible tests, hidden tests, and structural checks such as preserving scope, not deleting tests, and avoiding dependency churn. A model could complete the visible task but still lose points on hidden edge cases or production discipline.

The ClawCode return code was not used alone as the quality score. The verifier inspected the produced workspace and counted behavior-specific components. This mattered because some useful agent runs ended with a non-zero command return while still producing a correct, testable patch.

The hard-suite decimal scores and the real-world component scores should not be compared as if they were the same unit. A hard-suite score such as 0.8822 is an automated prompt-screen aggregate. A real-world score such as 19/19 is a workspace verifier count after the agent edited files. The release decision used both, but treated project-level verifier results as stronger evidence for the fine-tune target.

Public decision trace

This is the public version of the project "homework": prompts, verifier categories, numeric results, observed failures, and decision rules. It is not a private chain-of-thought dump. The auditable trail is evidence-first: what was observed, what rule it triggered, and what action followed.

Finalist matrix

All real-world harness results

The tables below are the project-level results used for the final public selection. They include both selected files, the first online SignalLatch Q4NL baseline, and the Unsloth baselines where those were available.

KritaLite: browser paint implementation

SyncBoard: local-first board and merge/replay logic

Legacy-codebase memory migration: natural agentic implementation

Hard-suite narrowing

The hard suite was used to find promising quantization families before spending time on full project work. Its job was candidate discovery, not final release selection. The table shows the later comprehensive hard-suite view for candidates that affected the release discussion.

Decision logic

Unsloth Qwen3.6 remained a strong competitor. The evidence does not support a broad claim that every SignalLatch v1.1 file beats every Unsloth file on every task.

That is why the public naming avoids absolute claims. Lite means smaller practical SignalLatch. Plus means the best practical quality SignalLatch variant from this sweep.

Caveats

• This is not a general leaderboard claim.
• The tests emphasize coding-agent behavior, tool discipline, file editing, and repair loops.
• The legacy-codebase task used a private/internal codebase, so the page describes the task shape and scoring rather than publishing the repository.
• Lite is not strictly better than the original file on every harness; it trades SyncBoard edge-case strength for better KritaLite and legacy-codebase migration results.
• Plus is the best current all-around pick, but it is slightly larger than Lite.
• Both files require the custom AEON ik-llama runtime path described in the main SignalLatch model card.