@Samuelm

DEVLOG #46 - Some repair scores could not be trusted

Every possible repair SL-LLM-R produces should be linked back to the original proposal it came from so the search can be scored correctly. I found cases where that link was ambiguous, which can make the score describe the wrong search. I changed the scoring path so ambiguous pairs are rejected instead of guessed, and the earlier zero-hit result stays zero.

DEVLOG #45 - Fixing one broken link still gave zero hits

When SL-LLM-R fails to find a repair that I know should be reachable, I need to know whether the search is bad or the test case is broken. One case had a broken link between the original proposal and the repair I expected the search to find, so I fixed only that link and ran the case again with the same number of attempts. The search still found the target zero times, so that broken link was not the whole problem.

DEVLOG #44 - I can explain 306 misses, but 1,224 still look the same

I am trying to understand why SL-LLM-R’s repair search fails to find fixes that should exist. Right now I can explain 306 misses, while another 1,224 look identical in every field I am allowed to compare. Two different explanations for the source-signal problem also match the same 306 cases, so the available data still cannot separate those explanations for the larger group.

DEVLOG #43 - I built one failure where I already knew the cause

SL-LLM-R’s repair search was missing many fixes that I expected it to find, but I did not know why. I built one small synthetic failure where the component reading the source signal gets the wrong input, so I can reproduce that miss on purpose. At least one failure now has a known cause, which I can compare with the unexplained failures without assuming they are all the same problem.

DEVLOG #42 - The first real learning run is still blocked

The repaired SL-LLM-R comparison produced 1,530 completed results, but I still did not understand the repair-search failures well enough to start changing real model weights. Training therefore stayed off while I investigated why targets were being missed. I would rather delay the first learning update than call an unclear result progress.

DEVLOG #41 - If the model grows, the extra capacity has to help

I do not want SL-LLM-R to add parameters just because a larger model sounds better. If the system ever needs more capacity, my current idea is to add a small module in a copy and test whether that addition actually improves the model. If it does not help, the extra module should be deleted just like any other failed update.

DEVLOG #40 - What happens if the model runs out of room?

SL-LLM-R is meant to keep learning over time, which creates a long-term problem if a fixed-size model eventually runs out of useful capacity. My current idea is a stable core, fast memory, small learnable parts, and possibly extra specialist modules only when the existing capacity is not enough. The project cannot do that yet, so this is still future research.

DEVLOG #39 - The repair-search failures are finally visible

With a completed comparison, I can now inspect why SL-LLM-R’s repair search misses targets. Some misses come from repeated ideas, some repairs need more steps, and some targets are never reached by the current search. Separating those cases is more useful than treating every miss as one generic failure.

DEVLOG #38 - The retry produced 1,530 completed results

After the first SL-LLM-R comparison crashed, I fixed only the problems that prevented the test from running and repeated the same comparison. This time all 1,530 runs completed and produced scores. I could finally inspect failures in the repair search itself instead of only debugging the test setup.

DEVLOG #37 - All 1,530 comparison runs crashed

I ran a large SL-LLM-R comparison to measure the repair search, but all 1,530 runs crashed before producing a useful score. That means the run tells me nothing about whether the repair method was good or bad. The test setup failed, so I kept the result as a failed experiment instead of treating the crashes as model evidence.

DEVLOG #36 - The learning loop is connected, but training is still off

The main SL-LLM-R learning path is now connected. It starts with the original model, makes a temporary changed copy, checks whether the change helped and whether older abilities got worse, then either keeps the copy or throws it away. Real training is still disabled, so this is not yet a finished self-learning model.

DEVLOG #35 - A better retry is still not model learning

SL-LLM-R is meant to change future model behavior, not just get a better answer on the second attempt. Many AI systems can retry with more context and look like they learned even when the model itself stayed the same. I only care about a correction as learning if it affects later behavior, does not break other abilities, and can still be undone.

DEVLOG #34 - Replay and consolidation fit the project together

I realized two ideas from continual-learning research fit SL-LLM-R quite well. Replay means keeping older knowledge present while learning something new, while consolidation is about deciding which new experiences deserve to last longer. Together they match the goal of turning some verified experiences into lessons without making every observation permanent.

DEVLOG #33 - Brain wiring gave me one idea to test

I looked at connectomics, which is research on how brain cells are connected, because SL-LLM-R needs a way to keep model changes local. One idea is that connection structure might help choose which parts are safe to change together. It is only inspiration for an experiment, not a claim that transformers work like brains.

DEVLOG #32 - The first real update has one clear path

I wanted the first real SL-LLM-R model update to follow one understandable sequence. The system loads a parent model, copies it, changes only the child, tests the parent and child, then either keeps the child or deletes it. Training is still disabled, but the update path itself is now connected instead of being spread across separate pieces.

DEVLOG #31 - A real base model is now part of the setup

SL-LLM-R started with placeholder model inputs while I built the safety and comparison logic around them. I replaced that placeholder with a real open model that the system can identify and verify exactly. Training is still off, but future experiments can now start from a real model rather than a fake name.

DEVLOG #30 - I can now undo a model update through the full practice loop

SL-LLM-R needs a complete way to undo a model change before real learning updates can be trusted. I can now save the original model, make a changed copy, test it, switch to it, and return to the original in one practice run. I have not yet used that path to undo a genuinely learned LLM update, so the mechanism works but the real learning case is still untested.

DEVLOG #29 - The cause finder is allowed to say it does not know

Before SL-LLM-R changes a model, it tries to estimate what caused the original failure. I tested that part on simple cases where the cause was already known, especially to see what happens when the signal becomes weak. It can stop instead of inventing a confident answer, which is the behavior I want before any model update depends on that guess.

DEVLOG #28 - Loading a model should not enable training

SL-LLM-R needs access to a real base model before I can run realistic experiments. I made that access read-only so loading and checking the model does not automatically give the system permission to change its weights. Training can stay completely off while I verify exactly which model and data the project is using.

DEVLOG #27 - Failed repairs still tell me something

SL-LLM-R generates repair ideas after model mistakes, and many of those ideas get rejected. I started keeping track of why they fail instead of treating every rejected repair as the same kind of failure. Duplicates, impossible repairs, multi-step repairs, and bad ideas reveal different weaknesses in the search even when the model learns nothing from them.