---

DEVLOG #6 (2026-07-02, CANDIDATE TRACING AND FAILURE ANALYSIS)

Project: SL-LLM-R

After the V1/V2 no-go, I wanted to see exactly what the proposal engine was
doing candidate by candidate.

I built deterministic tracing and wired it into the engine. Every candidate now
records its kernel source, parent, depth, score history, verifier decision, and
budget consumption. Trace files are canonically serialized and hashed.

Then I evaluated the main remediation hypotheses in isolation:

• Mutation kernel only
• Combination kernel only
• Restart kernel only
• Adaptive mixture

None showed an advantage over random. I also compared the strongest single
kernel and a uniform mixture. They behaved the same way.

The traces did reveal a real efficiency problem: duplicate candidates consume a
significant part of the nominal budget before deduplication. That is fixable,
but the oracle results from the previous devlog show that it cannot solve the
main benchmark problem by itself.

This was still useful. Instead of only knowing that the engine failed, I can now
replay the candidate path and see where each unit of budget went.

---

What Works

• Deterministic candidate-level traces
• Isolated evaluation of the proposal kernels
• Budget-use analysis
• Duplicate-pressure failure identified

---

Tests

.venv/bin/python3 -m pytest tests/stage1a_v2/test_round2_tracing.py

The recorded tracing tests passed. Sixty trace files were generated.

---

Changed Files

Commits: 8f0988c, dc9f233, e5b2b34

---

Next Steps

Use the tracing infrastructure in a new V3 benchmark with intermediate task
difficulty.

---

Summary (AI)

Tracing now explains candidate origin, scoring, verifier outcomes, and budget
use. No proposal kernel beat random on the old benchmark, reinforcing the
benchmark-discrimination NO-GO.