Great Idea, You Had It Last Week: Insight Doesn’t Survive

Reading Exhibit 1. The exhibit runs left to right: the earlier paper’s rule; what got lost one rung up; what the practice has tried; and the rebuilt loop with its status on 29 October. Seven answers on file counts the answers that turned out to be on file, not every answer given that day (Section 3.2). The 31 of 34 counts located losses only (Section 3.3). The 0 of 36,657 is a query of the operator’s memory database re-run on 18 October (Section 2). The 43 nights and 103 proposals are from a review of the nightly pass on 17 October (Section 4.2). Dashed steps are not built.

Summary

The plan beside outside measurements

What this means

• Capture the raw exchange when a position moves, not a lesson rewritten as an instruction (approved 20 October, not built; Section 5.1).
• Let each rung earn its level. Knowledge is scored as a forecast written in advance, insight is held if it raises how often that knowledge is right, and wisdom is held only on the operator’s ruling (Section 5.5).
• Turn a held record into a harness change and admit it on evidence: a change to what is loaded at start-up, a procedure, a check at the act, or how changes get made, admitted on fresh validation or the operator’s ruling, by a judge the change cannot edit (proposed; Sections 5.6 and 5.7).
• Serve held records as evidence at the act: at start-up (approved 27 October, not built), at the stop for coding agents (designed, not built) and before a decision a wisdom record governs (proposed, not built). It is never “are you sure?” (Sections 5.8 to 5.11).

1A written rule loses and a mechanism holds, so an insight has to become a mechanism

Reading Exhibit 2. The two columns set a rule beside an insight on what each says, when it can be checked, how it is lost and what holds it. The last row is this note’s claim: a rule holds when it is loaded first or enforced at the act, and an insight holds only when it becomes a change to the harness of the same kinds, admitted on evidence, with the raw exchange kept as the record of why. The strip at the foot marks the open case: a rule back in the window at 09:29 UTC that did not shape a plan at 16:02 (Section 1.5).

Terms used in this note

1.1What the rules paper claims

“Rulebooks are theater. Boundaries and incentives are not.” (background paper 3 of the series “How Do We Use This?”, revised 7 October 2026, 22 days before this draft) is the operator’s earlier paper. It argues from one practice, and says it reports a mechanism and not a rate, that a written rule the agent has to go and read competes with the work for its attention and loses. The practice carries about 125 rule-bearing items whose adherence has never been measured. One rule was missed seven times in a day, which the record counts as one act, and two tracked error classes came back in the very next session in 48 of 75 intervals, against about 40 expected from prevalence alone.

What held was different in kind: a rule loaded into the agent’s context before the session’s first token, which does not have to win anything, and boundaries that refuse an action at the moment it is attempted and record the refusal. The paper also says that a lesson written into the record is a rule of the first kind, one the agent must go and read, and that of eight lessons ratified into the practice’s merged store none is currently measurable, because promotion dropped the citation linking a lesson to the miss that produced it.

1.2A harness that evolves

The harness is the software around a model: the loop, the context it builds, the memory it keeps, the tools and the checks. The operator’s plan of 16 August already described a nightly step that proposes edits from the day’s misses, replays a regression set, gates them and allows one merge a day by the operator (Section 4.2). Wei et al. (Self-Evolving Agent Harness) (16 days; partly read) describe the same lifecycle in general form. Their harness uses feedback from its own runs to revise its instructions, memory, workflows and executable components while the model’s weights stay fixed. Each round diagnoses, proposes, assesses and admits; “Accepted revisions are stored and loaded in a subsequent run”. Two requirements make it a lifecycle rather than a log. Feedback has to produce revisions algorithmically, with the mechanism kept for the next round, and accepted revisions have to persist. Admission is the safeguard: a candidate is accepted only if it beats the current harness on fresh validation tasks, and the final judge sits outside what a candidate may edit. Admission may require a person’s approval. The paper also says what does not count: appending logs or compacting context under fixed rules does not revise the harness.

The update targets run in an order the paper draws as a road: instructions and prompts; context, memory and reusable procedures; workflows; and last, executable components and the runtime. A change high on that road alters what the model is shown. A change at the top alters what the system does whether or not the model reads anything.

1.3Why an insight has to become a mechanism, not a rewritten lesson

A rule says what to do, and it can be checked at the act: the action either followed it or did not, so a boundary can refuse the action and record the refusal. An insight is different in kind. It is a settled answer to a question, such as “No, the lead is the counterweight”¹, and nothing in the act is there to check it against. Its use depends on recognizing that the question has come back, often in other words.

The obvious repair is to rewrite the insight as a lesson, a short instruction that says what to do next time. That turns it into rulebook text, the first kind in the earlier paper, and it discards the part that made it an insight: the question it settled and what it rested on. The newest studies find that this rewriting is where the damage is done. In He et al. (Memory Tax) (4 days; main text read), 90 of 99 memory-system cells (11 systems, 3 benchmarks, 3 backbone models) fell below naive retrieval over the raw history, and raw episodes stayed competitive. R. Wang et al. (More Memory, Worse Agents) (10 days; partly read) found abstractions persisted by a model below trajectory-only memory in 7 of 9 cells. The older Zhang et al. (memory) (169 days, v2 29 Aug; full text, sections read) found that memory consolidated by a model first helps and then degrades, sometimes below no memory, while raw episodes hold up.

The same studies point to what does hold. In multi-agent software teams, Du et al. (Relic) (33 days, v2 29 Sep; abstract plus skim) measured fresh-member behavioral correctness at 25.4% with no inherited protocol, 34.6% with the lessons as readable text and 41.2% with lessons bound to the runtime. The earlier paper found the same split for rules: text the agent must read loses, and what is loaded first or enforced at the act holds. So an insight is made part of the harness the way a rule is: as a change to what is loaded first, to a procedure, to a check at the act, or to how such changes get made. The raw exchange is kept beside the change as its evidence, so the change can be traced to the moment that produced it and retired when it stops paying. These are agent-task results, not an operator’s own conclusions, so they bear on the design (Section 7) and do not prove it.

1.4What this paper adds

The earlier paper stops at the rule: where to load it and where to put a boundary. This note takes the argument one level up and joins it to the account of a harness that evolves. It names what is lost, the upper rungs of a ladder from data to wisdom, and where each would land in the harness (Section 2); shows the loss in the operator’s own record (Section 3); reports what the practice has already tried, by hand from lived experience and from insight, and with a nightly improvement pass (Section 4); and sets out the rebuilt loop, which captures insight and wisdom when they occur, makes each record earn its level, turns held records into harness changes and admits them on evidence (Section 5), with pass lines written before anything is built (Section 6).

The conclusion carries over. On 18 October the operator said of the usual remedy, “it wont help throwing it in memory”², and the plan does not file an insight as one more memory row to be read. The object changes: the earlier paper’s is a rule, this note’s is an answer settled once that has to change the system before its question comes back.

1.5The tension with Loss one, left open

The earlier paper says a rule loaded before the work starts fires. Section 3.1 records a rule that was in the window and did not govern the next action. At 08:58 UTC on 18 October the assistant committed to being thorough and to stating what it searched, and the rule was written down. The harness (the software that feeds the model its context) put it back into the window at 09:29. At 16:02 the assistant planned this very paper with the literature as a supporting track and ran no outside search first, about 6.6 hours after the re-injection and 7.1 hours after the rule was written. The operator caught it 83 seconds later.

Neither paper tests what the difference is. Candidate readings are that a mid-session re-injection differs from loading before the first token, that distance in a long window matters, that the display of the rule was cut so the coverage clause may not have arrived in full (Section 3.1), and that a new task is not an act the rule had been checked at. One case in one session cannot separate them, so this note states the tension and does not resolve it. It bears on the plan: if context alone does not reliably govern, serving an answer at start-up (Section 5.8) may not be enough, which is why the plan also serves it at the stop (Section 5.9) and turns held records into changes that act without being read (Section 5.6).

2Machines keep data and information; knowledge, insight and wisdom went untyped, and are still not served

Reading Exhibit 3. The ladder runs from data at the bottom to wisdom at the top. For each rung the exhibit gives where it lives today, whether it is typed and whether it is served. Machines keep and type data and information. Knowledge, insight and wisdom went untyped (0 of 36,657 stored records carried a level on 18 October) and on 29 October are still not served. The counts are 1,066 typed candidates (914 knowledge, 66 insight, 86 wisdom; 22 October; not judged) and 15 held records (7, 6 and 2; 29 October). One short example of each upper rung is a held line in the operator’s words.

The operator’s ladder has five rungs: data, information, knowledge, insight and wisdom (DIKIW in the operator’s files). The operator said of it, “the learning ladder and the DIKIW are basically the same”³. It is a variant of the ladder in Ackoff (via a secondary source) (1989; snippet only), which puts understanding where the operator puts insight, so each rung needs a definition of its own. The definitions below are the level rules the operator’s retrieval build used on 7 October and the reading rules applied to the 30 days to 22 October. The wording of the second set is the assistant’s, and the operator has not judged how it splits the levels.

2.1Data

What it is. The raw record of what happened: a message, a commit, a log line, a reading. Where it lives today. In transcripts of chats, coding-agent sessions and the assistant’s own sessions, in the message log between agents, in version history and in chat exports. Machines write it and append to it, and each item points back to where it came from. Losing it looks like a gap in the record, not a forgotten fact. The 22 October reading found the backup of coding-agent transcripts ending at 03:03 UTC on 18 October and the newest chat export dated 13 September, so those periods were out of reach. In the operator’s words. A held line is data before it is anything else: “Youre losing the KIW and that's what I've really been trying to sort out”⁴ first exists as a message sent at 10:05 UTC on 18 October, in a transcript, with a position in it.

2.2Information

What it is. Data that carries its date, speaker and source, so it can be counted, joined and traced. Where it lives today. In git history, a table of the operator’s rulings (73 rows read on 22 October), the miss ledger and the streams in the operator’s memory database. Losing it looks like an entry that no longer joins to where it came from. The earlier paper reports the case: eight ratified lessons, none measurable, because promotion dropped the citation that linked each lesson to its miss. The entry survives and the information does not. In the operator’s words. “I think the outside model, interacing with the frontier using the insights from above and our previous convos, is right”⁵ is information once it carries its date (18 October), its speaker and a pointer to the message, as the held record does.

2.3Knowledge

What it is. A statement of what is settled or measured that a later reader should be able to rely on without reopening the source: a ruling with its scope, a standing rule, a measured result with its number, a decision with its reason. Where it lives today. In the rulebook as the earlier paper counted it on 7 October, which is the two start-up documents every session loads (122 headed sections) and a memory store of 124 files, and in the rulings table. This is the rung the earlier paper is about, because a rule is knowledge of the kind that says what to do. Losing it looks like the rule that was in the window and did not govern the next action (Section 3.1), or the rule missed seven times in a day. In the operator’s words. “I think shipped errors is a stupid metric for us”⁶ is a ruling on which measure to use. A reader should not need to reopen why.

2.4Insight

What it is. A reframing or connection that was not stated before in the exchange: two things shown to be the same motion, a cause replaced by a better cause, a problem restated so that a new solution appears. A plain correction, a rebuke, an instruction or a one-line opinion is not an insight. The reading rule credits whoever formed it. Of the 66 insight candidates, 13 are the operator’s, 34 the assistant’s and 16 a coding agent’s. Where it lives today. As prose inside a turn: a reply, a commit body, a docstring. Nothing typed it until 22 October, and nothing carries it to the assistant at the act. Losing it looks like a settled answer coming back as new. On 18 October the assistant gave seven such answers, and two July ideas were lost until the operator supplied them again, 88 and 94 days after they were written (Section 3.3). In the operator’s words. “No, the lead is the counterweight”¹ names the working counterweight as the human lead.

2.5Wisdom

What it is. A priority or principle that governs a whole class of future situations (what to do first, what never to do, what to measure instead) and that rests on something specific: a pattern of cases, an outcome or a ruling applied again. A wisdom record has to name what it rests on. If it cannot, the reading rule labels it knowledge or insight, and 4 of 90 wisdom calls were demoted that way. Where it lives today. Nowhere typed as a level beyond the candidate set and two held records. The 7 October build counted 161 wisdom records by rule and its wisdom rule was weak (5 of 10 rulings misassigned). Of the 86 wisdom candidates, 15 carry a pointer to an item they rest on and 71 do not. Losing it looks like a frame dropped between sessions. By the serve plan’s own account, on 27 October the assistant framed the operator’s company by a measure other than its stated purpose after loading its memory, although the line that states the purpose was already in that memory. The memory search had been phrased in the wrong frame and returned the wrong rows. That is one session’s report, not a count. In the operator’s words. “all you can do is influence an LLm”⁷ sets a priority for a whole class of design choices: work on what enters and leaves the model, not on commands inside it.

2.6What separates knowledge from insight from wisdom

The three upper rungs are told apart by what it takes to hold a record at that level, not by how it sounds. Three tests come from the loop the operator approved on 18 October (“the updated concept for the loop”⁸) and from the reading rules.

• Knowledge is what a later reader would act wrongly without, or repeat work without, and it can be scored. The design writes it as a forecast in advance (if a lesson class is loaded, misses of one type fall by at least a stated amount within a stated number of weeks, with a probability) and scores it when the window closes.
• Insight is held if it raises how often the knowledge forecasts are right. It is tested by what it changes in knowledge.
• Wisdom is a priority judged against an outcome the operator values, and only the operator rules on it. The test that can be observed is what it changed: an action, a rule, or how rules get made.

The operator drew the last line himself when he asked where a scored forecast sits: “is that just knowledge, or insight? It's not wisdom.”⁹ The assistant reads that as follows: a score can show that a forecast was right, and cannot show that the priority behind it was the right one to hold. That reading is the assistant’s. The levels on the 15 held lines were proposed and then confirmed by the operator on 27 October. The levels on the 1,066 candidates were assigned by a reader (a Claude model), and the operator has not judged them: the split is 86% knowledge, which the 7 October funnel (3,043 knowledge, 570 insight, 161 wisdom, levels not nested) cannot confirm, because the unit and the rule differed. The boundaries between levels are the weak point of any such scheme. In the 7 October build a check of 10 insight records found 6 misassigned as given and 2 after plain corrections were dropped, and the wisdom check found 5 of 10.

2.7The state of the record

The counts below are from the operator’s memory database, re-read read-only on 29 October (the table of typed records, grouped by status and level). Candidates and held records sit in one table and are not disjoint: a text match on the first 40 characters finds three of the 15 held lines also among the candidates, so the two counts are not added.

• 18 October. 0 of 36,657 stored records carried a level. The column that would hold it was empty, and a re-read on 29 October finds it still empty.
• 22 October. 1,066 typed candidate records (914 knowledge, 66 insight, 86 wisdom) were loaded from a reader’s pass over 30 days, which read 1,371 of 3,667 reading units (37%). Each carries a verbatim span and a pointer. The operator has not judged them, so none is held.
• 29 October, 16:44 UTC. 15 held records (7 knowledge, 6 insight, 2 wisdom) were loaded from the operator’s own lines, confirmed at their levels on 27 October. Nothing is served to any model at start-up or at the stop.

The ladder is therefore partly typed and not yet used. What typing exists is a floor of what the operator’s record holds, and Section 5 sets out how a record would be captured, earn its level and be served.

2.8Where each rung lands in the harness

The loop of 18 October judges a wisdom record by what it changed: an action, a rule or trigger, or how rules get made. Read against the road in Section 1.2, each rung has a natural landing place. Data and information are already kept by machines, in transcripts, logs and version history, and the harness reads them on request. Knowledge lands in what is loaded at start-up: a ruling with its scope, a measured result with its number, a standing rule. Insight, a reframing of a recurring problem, lands one step further: a procedure the agent follows, or a check at the act that catches the problem the insight named. Wisdom, a priority for a class of situations, lands where changes are made: which gate a class of records must pass, which decisions go to the operator, what is measured instead. Section 5.6 turns this mapping into the loop’s output, and Section 4.1 shows changes of these kinds already made by hand.

3The answer was on file and not in hand at the act: two losses and 34 located cases

Reading Exhibit 4. Three panels, left to right. The first is the timeline of Loss one on 18 October (UTC): the rule written to the operator’s memory at 08:58, put back into the window by the harness at 09:29, and the plan at 16:02 that ran no search, about 7.1 hours after the rule and 6.6 hours after the re-injection. The second is Loss two: the seven answers that were already on file, each drawn from the date its source was written to 18 October (not to 29 October 2026), from 45 to 88 days for the three offered as new, 45 for the one offered partly as new and 46 to 95 for the three that first appeared as retrievals. The third is the 34 located losses by what the loss crossed: 31 of the 34 crossed a boundary, the median gap was 4.37 days, and the medians were 0.13 days inside one window (3 pairs) and 0.80 across a compaction (6). The panels show when and how long, not how often (Section 3.4).

Two losses organize this section. The assistant grouped three of the operator’s messages^10–12 into them: a conclusion reached in the window does not govern the next action (Loss one), and what was on file was not in hand at the act (Loss two). The record has no statement that the operator takes that frame (Open questions), so each loss is argued from timestamps and files, not from what the assistant said about itself. The third part counts how often the second shape turned up in the operator’s history.

3.1Loss one: a rule in the window did not govern the plan

At 08:58 UTC on 18 October the operator wrote “i need you to be thorough”¹³, and the assistant committed to being thorough and to stating what it searched. At 09:29 the harness put that rule back into the assistant’s window. At 16:02 the assistant planned this very paper with the literature as a supporting track and ran no outside search first; the operator caught it 83 seconds later, and the assistant ran six web searches in the same reply. Nothing was compacted and no session ended in between, so the rule was carried and the next action on a new task did not reflect it. That is the open tension of Section 1.5: a rule in the window that did not govern a plan 6.6 hours after its re-injection. It cost one plan. Appendix D.6 gives the timestamped sequence, what the record does not support, and the outside studies.

3.2Loss two: the seven answers were on file

Late in the day the operator said “right, so this has all been out there”¹⁴, and the assistant produced a table of seven things it had offered that day and where each already was. Checked against the files (Table 1), it offered R1, R3 and R6, and partly R4, as new before finding that they existed; R2, R5 and R7 first appeared in its replies as retrievals. It reached most of the seven only after the operator pushed. Nobody counted the answers that turned out to be new, so seven is a count of losses found, not a rate. Appendix D.6 gives the corrections to the assistant’s table and its account of why.

Three of the seven were already part of the harness. R1, R2 and R7 were already code in the operator’s harness when the assistant reached them. R1 is the clean case. It is a clause of the operator’s stop check, first committed on 3 September, that blocks a claim that something does not exist unless the claim names the space searched. At 06:10 UTC the assistant proposed exactly that check as a new idea, and at 06:13 it found the check already built. The clause runs in the coding agent’s harness, at that agent’s stop. The assistant works on a platform that harness does not reach (Section 5.12), and nothing carried the clause, or the question it settled, to the assistant when the question came back. R2 and R7 were also in code, and the assistant found them by retrieval after the operator asked. So a change to the harness is necessary and not sufficient: it acts only in the harness it lands in, and it does not carry its reason. The rebuilt loop therefore ships every change with its record, and serves the record wherever its question returns; Section 5.6 takes R1 through the loop.

3.3The 34 located losses

The assistant read the corpus: 8 chat export files (290 unique conversations, 17,332 messages, 9 February to 3 September), the coding agent’s transcripts (2,450 unique session or sub-agent files, 197 of them main sessions, 12 May to 18 October), 285 of its own sessions (2,922 text turns, 7 to 18 October) and one commit. It searched with a lexicon frozen before the precision read (14 families of the operator’s phrases such as “we’ve gone over this” and 8 of the agents’, such as “I re-derived it”), grouped hits within six messages into events (347 events; 337 remain after dropping duplicates from forked sessions; the hit counts are in Appendix C), and read all 337 by hand. Of these, 104 were true losses of something the agent had worked out, labeled insight losses at the time under a wide rule (a reframing, decision or finding re-derived as new, contradicted without citation, or re-supplied by the operator; Section 3.5 sorts them by level) and 17 were rule bypasses, where a known rule wasn’t applied. A random sample of 48 hits gave 18 true, a hit precision of 37.5% (Wilson interval 25.2 to 51.6%). The four known losses all fired the lexicon, a check on four cases and not a recall estimate.

For the insight losses it then looked for the moment the insight formed. That search was systematic only for the high-confidence events and a review of the first 24 medium ones. It located 34 formation-to-loss pairs (25 high confidence, 7 medium, 2 low) covering 32 distinct loss turns (31 of them among the 104 insight losses; the 32nd is a rule bypass kept because the rule is the insight). The other 73 insight losses have no located formation: some were searched for and not found, and some were not searched. The median gap from formation to loss is 4.37 days (bootstrap 95% interval 1.09 to 10.04; range 0.08 to 94.24; 5.31 days for the 25 high-confidence pairs). 11 of the 34 are under a day, 8 are 1 to 7 days, 9 are 7 to 30 days and 6 are over 30. By source the losses are 21 in chat, 11 in coding-agent sessions and 2 in the assistant’s sessions (counts, not rates; the windows differ).

The boundary is what the loss crossed. 31 of the 34 crossed one: 13 a different agent or channel, 12 a later session in the same channel and 6 a compaction inside one session; 3 happened inside one context window.

The 34 pairs are not independent: four pairs share a loss turn (two couples) and four others share a formation turn (two couples), eight pairs in all. Counting each of the 32 distinct loss turns once, the median is 3.29 days with the same interval from a cluster bootstrap (the interval depends on the bootstrap scheme and is discrete; Appendix C and Section 8 give the details); counting each formation once at its shortest gap, it is 4.23.

In the same window, one agent wrote that it had the answer right and then talked itself into reopening it (3.2 hours apart): “I had it right and then talked myself into re-opening it.”²⁷ Across a compaction, an agent asserted the opposite of its own earlier finding (2.7 hours apart): “I had it right. Before the compaction. In writing.”²⁸ The two that end in the 18 October debate are the longest: the 15 July commit and the 22 July session of a second agent on one side, the operator’s 18 October turn³ on the other, 94 and 88 days apart, across an agent. The earliest formation is an off-corpus Notion note, dated only to the afternoon of 13 May. The in-session case of Section 3.1 is not among the 34: the study set aside the debate session’s own meta-discussion after the seed turn.

3.4What it can and can’t say

The count is of losses someone noticed, not a rate. The lexicon finds the phrases the operator and the agents use when something is lost, so a loss nobody flagged in those words is invisible. One rater did all the labeling, the assistant, a Claude model reading Claude-written turns, and boundary and confidence calls are judgments. The median is conditional on a loss having been noticed, on its event having been searched for a formation (systematically for only part of the events) and on the formation being findable: a formation was located only when the loss turn quotes it or a targeted search found it. The channels cover different windows, so the gaps are not times to loss and the counts are not rates.

The assistant’s reading: the lexicon is built from phrases that point back to earlier sessions, so in-window losses may be undercounted, and 3 of 34 shows what the search can see, not how rare in-window loss is. July and August run higher than May, June, September and October, which may partly reflect agents logging misses and quoting prior text in those months (a hypothesis the study did not test), so it need not mean a higher rate of loss. Several formations sit in Notion or Slack, which the study did not read.

What the evidence does say is narrower than the frame. Loss one is one case in one session, in a setting where the rule had been re-injected. Loss two is seven answers from one day, with no denominator for the answers that turned out to be new. The 34 pairs show that, among losses noticed and traced, most crossed a boundary and the typical gap was days, not months. None of the three measures a rate, and none tests whether serving the earlier answer would have changed the act: Sections 5 and 6 give the plan for that test, and as of 29 October 2026 nothing is served; Section 8 states the limits. Open questions has the readings that cut against the operator’s position.

3.5What level was lost

The labels above are the assistant’s, and the outside review of 30 October found that they call rules and decisions insight, which this note’s Terms table classes as knowledge. The assistant re-sorted the 34 located losses, the seven answers of 18 October and the 15 held records against the Terms definitions; Appendix C lists the file, with a call and a reason for each item for the operator to overrule. Of the 34 losses, 24 are knowledge (rules, designs, facts), 7 are insight, 1 is wisdom, 1 is a one-line opinion and 1 cannot be recovered. All 7 insight losses crossed a boundary (2 at a compaction, 3 in a later session, 2 in another agent), with a median gap of 10.04 days (0.11 to 94.24); two of them share one loss. Of the seven answers of 18 October, R2 and R6 are insight and the other five are knowledge. 5 of the 7 insights were formed by an agent.

The wisdom is the operator’s. The one wisdom loss and both held wisdom records are his lines, and on 30 October he agreed with all three wisdom calls (3 of 3), in his words “I’m the one dropping the wisdom ha”. On the 15 held records the assistant’s level matches the operator’s in 7 of 15. The re-sort is one more pass by the same kind of rater, so it is evidence for Section 5.3 rather than a correction of it: a model sorting its own exchanges by level blurs knowledge and insight, which is why the design sets level by a forecast test or the operator’s ruling.

3.6Outside data: public coding-agent sessions

The note’s own record is one practice. To set it beside others, the same question was run on public session transcripts posted to Hugging Face (computed 30 October 2026; sessions dated December 2025 to 17 October 2026): 2,342 sessions from 12 operators, 9,248 operator turns judged by a model, 2,076 corrections and 161 repeats, where a repeat is a correction the operator gives again. The measure differs from Section 3.3, which counts losses someone noticed; this one counts repeated corrections, mostly misses, so it bears on knowledge more than on insight. Three results. First, lessons rarely become harness changes: 30 of 1,915 lessons (1.6%) were followed by an edit to a harness file that addresses them, and 2 of the 161 repeats had one in between. Second, most repeats cross a boundary, though fewer than in the operator’s record: 88 of 161 (54.7%) came in a later session and 14 more after a compaction, so 102 of 161 (63.4%) crossed a boundary as this note defines it, against 31 of 34 here; the share runs from 0% to 74% by operator, with how each one splits work into sessions. Third, most repeats come quickly: the median gap is 0.27 days overall and 11.5 days for repeats across sessions (interval 4.0 to 16.5), which contains this note’s 4.37. Whether a harness change stops a lesson recurring cannot be tested on these data: 1 of 30 lessons that got an addressing edit repeated, against 88 of 1,774 that did not, too few to tell apart. All of it is provisional: one model judge (85% on a 20-item hand check), a word-overlap matcher whose recall was not measured, so repeats are undercounted, and 11 qualifying operators not computed. Appendix C lists the files.

4The harness has been changed by hand, from lived experience and from insight; the nightly pass meant to do it proposed prose

Reading Exhibit 5. The left panel lists four changes tried by hand from logged scars, with their dates, their kind and what became of each: two rules loaded first in the start-up documents (10 July), which the agent landed itself; a guard extension to check the repository (23 September), which the operator closed; and replay tests for the two largest miss classes (28 and 30 September), which the operator merged. The right panel is the nightly improvement pass over 43 nights: what it was asked to do, what it proposed and what was merged. Each panel’s input was scars. The dashed box notes the third route: an insight (R2) and a design built on one (R7) put into the code by hand, with no record of the insight (Section 4.3).

The practice already changes its harness from experience, in three ways: by hand from lived experience (so far, only scars), by hand from insight, and with an automated pass meant to run on lived experience. This section reports each against the requirements of Section 1.2: feedback that produces revisions, persistence, and admission on evidence with the judge outside what is edited.

4.1By hand, from lived experience

The practice’s learning input is lived experience: what an agent or the operator logged as earned from the work, scars and positives alike. The operator ruled three times (17 July, 31 July, 24 August) that positives get the same process as scars, and the code now counts both; the miss ledger that came before is retired, by the operator’s word on 27 August. Four changes in the record were tried by hand from logged scars, and three persist; none came from a positive. Two are rules loaded first, the form the earlier paper found to fire at start-up (though Loss one shows such a rule does not always govern the next act); the other two are a check at the act and tests, the forms it found to hold. On 10 July a forced diagnosis check was locked into the start-up documents: before asserting or acting on a consequential diagnosis, the agent names what would prove it wrong and reads that first. It came from catalogued wrong-diagnosis misses, 15 by one count of the register; the count depends on how the register is filtered. The same day a standing rule set which calls go to the operator and which the agent decides. It came from one logged scar, recorded in the since-retired miss ledger as a repeat of an earlier routing miss, after the operator told the agent it was supposed to be making informed decisions. On 23 September an extension of the guard that makes the agent read before it claims, to check the repository before a claim that something still needs building, was proposed after misses in September; the operator closed that change the same evening, and it never reached the harness. On 28 September replay tests were written for the two largest miss classes; the operator merged them, and they entered the test corpus on 30 September. Table C4 in Appendix C gives the receipts.

Against Section 1.2, admission is where these fall short. The agent wrote the two rules of 10 July and landed them itself in the same session, and no record shows the operator approving either, so the editor and the judge were the same agent, which Section 1.2 rules out. The operator merged the replay tests without reviewing their content, which a second agent reviewed. The one change the operator did judge, the guard extension, he rejected. In every case the feedback was a scar someone noticed and logged and the revision was written by hand, so the loop ran only when someone ran it. Whether each change reduced its miss class has not been measured in this note. None of these four came from a typed insight or wisdom record, because no such record existed until 22 October (Section 2.7); insight reached the harness by another route, by hand and untraced (Section 4.3).

4.2The nightly improvement pass

The operator’s plan of 16 August describes a nightly step with the shape of Section 1.2: pick the day’s logged experience (misses, in the plan’s words), re-solve them, propose candidate edits, replay a regression set, gate, and allow one merge a day by the operator. A review of 17 October read the built pass end to end. Over 43 nights it was given a real experience on 2 nights; on 4 early nights it was asked to improve one start-up file, and on 37 it only resumed open work. It produced 103 proposals, and 87 of them (84.5%) were prose edits to two start-up files. None was code, a validator or a test. One change was merged, a 3-line metadata edit.

Each failure maps to a requirement. The pass drew one record at a time, so it could not see a class, and it read a frozen copy of the start-up files, so it could not see the record of what happened. Its grader checked the form of an edit and never saw the experience the edit answered, so admission did not rest on evidence that the change helped. And its output space was an edit to a file, so its revisions stayed prose in start-up files, the same form as the two rules of Section 4.1 and no stronger, and none added a check, a test or a validator, the forms the earlier paper found to hold. On 16 October the pass itself named the right fix for the miss it had worked for weeks, a resolver that reads the live value instead of accepting a typed one; that fix sat outside what it could edit. The outside record agrees: Zhao et al. (13 days; abstract only) found that failure-derived experience repairs failed tasks but rarely yields sustained improvement on unseen tasks.

4.3By hand, from insight, with no record

Misses are not the only input. Insight already changes the harness, by hand. Two of the seven answers of 18 October carry it into the code: R2, itself an insight (the reframing that ignorance is a work order and not a verdict), has shaped how the challenge is dispatched since 2 September, and R7, a design that scores a gate by loop depth rather than by wisdom and is knowledge by the Terms test, was committed on 15 July with the R6 connection, between the operator’s ladder and Ackoff’s, written into the commit itself (Section 3.2). What these changes lack is the record. Neither carries the insight it came from, so neither can be judged on a forecast, kept against a rewrite or served when its question returns, and on 18 October the agent offered R6, the connection behind R7, as new. The lived-experience route traces each change to a logged record; the insight route traces nothing. The rebuilt loop in Section 5 keeps all three routes and adds the record.

5The rebuilt loop: capture the moment, earn the level, change the harness, admit it on evidence, keep it

Reading Exhibit 6. The loop runs clockwise. A position moves in a live exchange and the raw pair is captured as a candidate record. The record earns its level by a gate for its rung. A held record is turned into a proposed change to the harness at the level it governs: what is loaded at start-up, a procedure, a check at the act, or how changes get made. The change is admitted on fresh evidence, or on the operator’s ruling for wisdom, by a judge outside what the change may edit. Admitted changes persist and the record is served where it applies, and outcomes return as data for the next pass. Each step carries its status: ruled, proposed or built.

Section 2 says where each rung lives today and Section 4 what has been tried. This section sets out the loop in order: capture (5.1 to 5.4), promotion (5.5), the change to the harness and its admission (5.6 and 5.7), and serving (5.8 to 5.12). Every part is labeled ruled (the operator decided it, with the date), proposed (the assistant’s design, with no ruling) or built (loaded or running, with the date).

The design follows the operator’s loop of 18 October, approved as a concept that day, which writes typed records of knowledge, insight and wisdom with a source pointer, promotes them by scored gates, none self-graded, serves held records at the act, and returns the outcomes as data. Its measure of a wisdom record is what it changed: an action, a rule or trigger, or how rules get made. Sections 5.6 and 5.7 make that measure the loop’s output.

5.1When: as the position moves, with a nightly pass behind it

Exhibit 6, step 1: capture the moment.

An insight forms inside an exchange, in the pair made by the operator’s push and the assistant’s reply. The operator said so of the debate behind this note: “THIS exchange in particular shows it well”¹¹. A nightly read of the record finds that pair hours or days later, after a compaction or a new session has already put it at risk, and Section 3.3 shows losses within hours of formation. Capture therefore has two triggers. The live one fires when the assistant’s stated position moves from one turn to the next: the pair that moved it, the preceding operator turn and the reply, is written as a candidate record in the same session. The backstop is a nightly pass that reads every source (session transcripts, the message log between agents, commits, the ruling ledger, notes) and writes what the live step missed.

Status. The loop that holds both triggers was approved by the operator on 18 October at 15:44 UTC (“the updated concept for the loop”⁸). Capture as the insight forms, from the live exchange and not only in a nightly pass, was ruled on 20 October. It is not built. The reader a nightly pass would use was run once, on 22 October, over the previous 30 days (Section 5.3), and a scheduled nightly run is not in the record. Serving a record inside the session in which it was captured is not ruled: the operator was asked on 20 October, and no ruling is recorded (Section 5.12).

5.2What: the raw pair, not a lesson

A record holds six things. The raw pair, verbatim: the span of the exchange in which the position moved, in the speakers’ own words. The level: knowledge, insight or wisdom, as defined in Section 2. The question it settled, so that a later question can be matched to it (Section 5.10). A pointer a reader can open: a message in a session, a commit, a ruling row, a page. What it derives from: the earlier records it rests on. A status: candidate, held or retired. Successes are recorded as well as misses, since both show what held. No rewritten lesson is stored as the record.

The pointer and the derivation carry weight because the earlier typing attempt failed without them. In the 7 October build of the operator’s retrieval pipeline the wisdom rule was weak, with 5 of 10 rulings misassigned, and the records had no field naming what they rested on; the derivation field was added for that reason. The outside evidence points the same way on versioning. In long simulated chats, an agent reading atomic-fact memory published 62% of objects whose failure lay upstream, against 0.3% when each verdict recorded the versions it derived from (Y. Wang et al. (Tether) (11 days; abstract plus a text search)).

Status. Built on 22 October: a table of typed candidate records with a span, level, speaker, pointer, derivation, status and a short statement the reader wrote beside each span. It has no field for the question settled, which belongs to the matching design and is proposed, not built. Of the 1,066 candidates, 1,056 carry a span found verbatim in the source and 10 a near-verbatim one; all 1,066 pointers resolved in the check run at the time of the load. The derivation is the weak field: for most of the 86 wisdom candidates it is a prose note, not a pointer to an item, and a lexical linker found an earlier knowledge or insight record for fewer than 1% of the insight and wisdom candidates. The 15 held records, loaded on 29 October at 16:44 UTC, are dated to the day only, and the database flags the pointer as resolving for 2 of the 15 and not for the other 13; whether those 13 can be opened by hand was not checked.

5.3How a formation moment is recognized: designed in part, unsolved in part

Measured, once. Section 3.5 is a measured case of the unsolved part: the model that formed the exchanges labeled rules and decisions insight, and on the operator’s held records it matches his level in 7 of 15.

Designed. The live trigger rests on a check the operator’s code already has for another purpose: whether an agent’s position moved between two turns, and whether the move was a fold to pressure or a correction to a fact. The design reuses it, and the check’s accuracy as a formation trigger has not been measured. A second signal is the shape of the push: in the debate the operator’s tagged pushes each named a place to look (Appendix D.3), so, as proposed, a push that names a source followed by a reply that moves marks a candidate pair. The third is the nightly reader, which was run over the last 30 days of the operator’s sources on 22 October and produced the 1,066 candidates (914 knowledge, 66 insight, 86 wisdom) from 1,371 of 3,667 reading units (37%). That run is the only measurement of recognition so far, and it is a reader’s judgment: the operator has not judged the blind sample of 60 records (20 per level), and no second reader has read it.

Unsolved. Five problems are open, and the design does not claim to have solved any of them. First, a position can move because the assistant folded, so a trigger on movement also records capitulations; capture only records, and the gates in Section 5.5 decide what is kept. Second, formation is easy to see after a loss and hard to see before one: the 34 pairs in Section 3 were located backward, from a loss turn that quoted or implied the formation, and the phrase list used there was built to find losses, not formations. Third, the reader missed material: a random audit of the units its filters skipped found a record in 6 of 18 skipped operator-anchored units and 9 of 18 unread units from other sources (provisional, 18 units each), so the 1,066 are a floor. Fourth, the reader labeled 86% of its output knowledge, and whether it separates knowledge from insight at the operator’s line is unmeasured. Fifth, whose insight counts: of the 66 insight candidates, 13 are the operator’s, 34 the assistant’s and 16 a coding agent’s, and whether an insight formed by an agent counts is for the operator to rule.

5.4Why not a lesson

A lesson written into the record is the first kind of rule in the operator’s earlier paper: text the agent must go and read, competing with the work for its attention. The outside studies add that the rewriting itself costs accuracy, so the design keeps the raw exchange and treats any model-written statement as a label beside it. Newest first. Across 11 memory systems, 3 benchmarks and 3 backbones, 90 of 99 cells fell below naive retrieval over raw history (He et al. (Memory Tax) (4 days; main text read), personal-agent recall, no Claude model). Raw retrieval ranked first in 6 of 7 benchmark-model settings, and a write policy that only appended raised accuracy on one conversation benchmark from 67.36% to 69.42% (Bao et al. (Naive RAG) (7 days; partly read)). When a lesson is written from a chance failure, readers named the worse tool in 11.6% of next runs, against 0.4% for an irrelevant item, and 6 of 11 models carried the chance, while the Claude 5.5 models were bounded below 0.10 (Nakayashiki (Lessons from Luck) (17 days; partly read), synthetic two-tool worlds). Repeated consolidation by a model degraded memory even from correct inputs, and agents that kept raw episodes by default doubled the accuracy of forced consolidation (Zhang et al. (memory), a May study on ARC-AGI problems, so transfer to behavioral lessons is unverified).

The remedy proposed here, typed records with a pointer, is itself untested. The full text of the consolidation study above has no typed-schema condition (text search), and the two studies that use typed, provenance-bound records do not isolate the typing (Fan et al. (KEEL), Y. Wang et al. (Tether)). The loaded table also contains a model-written statement on every candidate, which is a rewrite of the kind the studies warn about; it is kept as a label, and the verbatim span stays the evidence.

5.5Promotion by rung

Exhibit 6, step 2: earn the level.

A candidate is not trusted because a model typed it. Each rung has its own gate, and none is self-graded. Knowledge is held when its outcomes are scored: written before a window as a forecast (“if this class of lesson is loaded, misses of this type fall by at least this much within this many weeks, probability p”) and scored with a Brier score when the window closes. Insight is held if the reframing raises how often the knowledge forecasts it produces are right. Wisdom is held only on the operator’s ruling, a line the operator drew himself when he asked where a scored forecast sits on the ladder: “is that just knowledge, or insight? It's not wisdom.”⁹ Whether a wisdom record worked is judged by what it changed: an action, a rule or trigger, or how rules get made. Status then moves from candidate to held to retired, and, as proposed, only the operator retires a wisdom record.

Status. The gates are part of the loop approved on 18 October. None has run: no forecast is recorded as scored, and no record has been promoted by a gate. The 15 held records reached that status by another route, ruled on 27 October: the operator confirmed 15 of his own statements at proposed levels (7 knowledge, 6 insight, 2 wisdom), and they were loaded as held on 29 October at 16:44 UTC. Their level is his judgment, not a score. The other 1,066 stay candidates; the operator has not judged them.

Outside evidence. Scoring forecasts is a method for training forecasters (Afifi et al. (28 days; full text, sections read), Singh et al. (121 days; abstract only) and Turtel et al. (293 days; abstract only)), at the level of model weights. Nothing found tests Brier-scored forecasts as the signal that promotes or demotes lesson classes with no weight change: not found at this search depth (6 queries on arXiv and OpenAlex, 29 October 2026). The nearest, Pham et al. (Randomized Block Curation) (16 days; abstract plus a text search), promotes lesson blocks by their measured effect on task success. Gating itself has outside support: verified lessons helped Claude Opus 4.6 and Sonnet 4.6, and Haiku 4.5 fell (Fan et al. (KEEL) (4 days; full text)).

5.6From a held record to a harness change

Exhibit 6, step 3: change the harness.

Status. Proposed; nothing is built. The plan of 16 August already allows a nightly step to propose candidate edits for the operator to merge, and that step has run on misses (Section 4.2). Feeding it from held records is new.

A held record is offered to the change step with its raw pair, its level and what it rests on. The step proposes a change at the level the record governs, and the levels follow the road of Section 1.2. A knowledge record that names a fact or a measured result changes what is loaded at start-up (5.8). An insight that reframes a recurring problem changes a procedure or adds a check at the act, the kinds of change Section 4.1 lists. A wisdom record, a priority for a class of situations, changes how changes get made: which gate a class of records must pass, or which decisions go to the operator. Each proposal names the record it comes from, the miss class or decision class it should move, and a forecast written before admission: if this change is loaded, the stated outcome moves by a stated amount within a stated window.

Two limits from Section 4.2 are written in. The step sees a class of records and the record of what happened, not one item and a frozen copy of the start-up files. And its output space includes code, checks and tests, not only text the agent must read, since text is the step the earlier paper found loses.

Worked example: R1, the absence check. Run through the loop, R1 shows what the rebuilt loop adds to a change that already exists. Capture. The exchange that produced the clause would be kept verbatim, with the question it settled (how is a claim that something does not exist checked?) and a pointer to the commit of 3 September. Level. It is an insight in the sense of Section 2.4, a reframing: an absence is a claim like any other and needs its search space named; that labeling is the assistant’s reading. Change. The change already exists, a check at the act in the coding agent’s harness. What the loop adds is that the change is registered with its record, so the record travels with the mechanism. Admission. The validation set would be logged false-absence misses of that class and past turns where the check should stay silent; none has been run, so the change’s value is not measured here. Serving. In the coding agent’s harness the check acts at the stop whether or not the agent reads anything. On the assistant’s platform, which no hook reaches, the record is what can travel: at 06:10 on 18 October the question of how to check an absence claim had a settled answer on file, and a lookup by that question (Section 5.10) would have put the record, and the existing check, in view before the assistant proposed it as new. Whether it would have changed the turn is untested.

5.7Admission: fresh evidence and a judge outside the change

Exhibit 6, step 4: admit it on evidence; scoring its forecast is step 6, outcomes back as data.

Status. The operator’s merge as the last gate is in the plan of 16 August. Admission on fresh evidence is proposed; nothing is built.

A proposed change is admitted only if it beats the current harness on cases it was not built from, following Wei et al. (Self-Evolving Agent Harness): a fresh validation set drawn after the proposal is fixed, and a judge the change cannot edit. For a check at the act, the validation set is replay of logged misses of its class and of past turns where the check should stay silent, so that both a catch and a false alarm count. For a change at start-up, it is the retrieval test with known answers (Section 6.1). For a wisdom record, admission is the operator’s ruling, since its value is judged against the outcome the operator values. The forecast written in 5.6 is scored when its window closes, so a change that does not pay is retired, with its record kept.

The operator’s load. Wisdom needs the operator’s ruling, and every held record so far entered by his confirmation, while 1,066 candidates (86 of them wisdom) wait for him. The plan proposes a sampling order rather than a full read: first the blind sample of 60 records (20 per level) already drawn, with agreement reported per level; then candidates in the order the change step would use them, so a record is judged when a change depends on it. Knowledge and insight are then admitted on their scored forecasts and replay sets, which do not need him; only wisdom and the final merge do. All of this is proposed.

The guard is the one Section 5.5 sets for promotion, where no gate is self-graded: no record and no change is graded by the agent that wrote it. The final judge stays outside the editable surface, as Wei et al. (Self-Evolving Agent Harness) requires, which here means the operator, the replay set and the scored forecast.

Serving. A change to the harness acts whether or not the record is read, but not every record becomes one, and a held record has to reach the act in the meantime. Capture without serving changes nothing, since a record on file and not in hand is the loss that Section 3 measures. Serving rests on the earlier paper’s argument: a written rule the agent has to go and read loses to the work, and a boundary that refuses an action at the moment it is attempted holds. An insight cannot be turned into a boundary by itself, because nothing about it can be checked at the act. What can be checked is the lookup. The rule is the lookup; the insight is the evidence. A boundary on the lookup makes sure the record is in view, and what is served is the raw exchange, for the agent to reason with. Sections 5.8 to 5.12 give the three points of service, matching and reach.

5.8At start-up: a context channel, not the boundary

Exhibit 6, step 5: persist and serve. Sections 5.8 to 5.12 cover the three points of service, matching and reach; Appendix E gives each in full.

Status. Approved by the operator on 27 October; not built. A short section of held records (the operator’s verbatim line, its level, its date and a pointer) is rendered first on the page every agent session reads when it starts. It is a context channel and is not claimed to be a boundary: Loss one (Section 3.1) showed a rule in the window that did not govern the next act. It should help most where the failure is framing and least where a specific act must be stopped, which is the job of the stop (Appendix E.1).

5.9At the stop: the lookup boundary

Status. The work order at the stop is in the loop approved on 18 October; the framing as a boundary on the lookup is in the plan approved on 29 October. Not built. When the agent is about to give a final answer on a question that has a held record, the answer is refused until the record is in view, and the record is served as a work order: what the record says, what the turn says, and which source to check. It is never “are you sure?”. The trigger is wider than the existing stop check, which refuses claims made without a read: it also covers absence and origin claims, including the claim that an idea is new. An enforced completion gate gained 4.0 and 5.3 points across seven frontier coding models, against 3.3 and 3.9 for a prompt instruction alone (Zhang et al. (Rethinking Verification)); serving an insight at the stop is untested (Appendix E.2).

5.10Matching by the question settled

Status. Proposed; not built; no index of held records exists. A record is served when the question in front of the agent is the one the record settled, however differently it is worded, and an outside model makes that judgment. Word similarity alone has failed once (a lift over chance of 0.100, interval including zero, on 93 held-out pairs), and an informal keyword lookup put the expected record in the top 5 for 2 of the 7 answers of 18 October. A wrong match has a price, so the record is served as evidence with its source (Appendix E.3).

5.11Applying wisdom: a ruled priority, weighed at a decision

Status. Proposed; not built; no wisdom record has been served. A wisdom record is a priority the operator has ruled on, with the objective it assumes. It is served at a decision of its kind and weighed, not obeyed: the agent says what it weighed and what it chose, and only the operator retires a record. Held line 3, “it wont help throwing it in memory”²⁹, would be served when the proposal for a repeated miss is to write a memory row; applied, it would show as a proposal that names where the fix is enforced (Appendix E.4).

5.12Reach: where the stop can be served and where it cannot

Status. The reach statement is in the loop approved on 18 October; serving inside a session is not ruled. Coding agents can be served by a stop hook, which is not built. The assistant’s own platform cannot be reached by hooks, which is why R1 was lost there (Section 3.2). For that platform the design of 27 October adds a procedure: before a big-picture question, retrieve the operator’s own words on the topic and quote what was used. That is a rule of the first kind, so Loss one applies to it, and the operator’s work orders remain the check (Appendix E.5).

5.13What a team can do now

• Keep the raw exchange beside every lesson or rule. Store the question it settled and a pointer to the exchange, so the reason survives the rewrite.
• Write the forecast before changing the harness. Name the miss or decision class that should move, by how much and by when, and score it when the window closes.
• Replay before merging. Run the change against logged cases of its class and cases where it should stay silent, and let something other than its author judge it.

6The pass lines are written before anything is built; on 29 October nothing is served

Reading Exhibit 7. The left panel is the status of each part of the plan on 29 October 2026, one row per part, in three columns: ruled, proposed, and built. The right panel is the pass lines, each with the number that would pass it: 6 of 7 expected records in the top 5, against 2 of 7 on the informal lookup of 22 October. Only the candidate table and the 15 held records are built, and nothing is served.

The pass lines were written before anything was built, so that a result cannot move them. Three are ruled and one is proposed. They measure whether the right record is found or whether use beats a baseline; none yet measures whether an agent’s answer changed, which is the point of the plan. The proposed replays are the route to that.

6.1The pass lines

1. Retrieval with known answers (ruled with the loop, 18 October). The seven answers of 18 October (Section 3.2) were written down as queries before any index existed. The index passes if the held record that answers each is in the top 5 for at least 6 of the 7. Not run: no index exists, and the answering records are dated 15 July to 11 September, older than the 30-day window the candidates were typed from, so the 1,066 candidates cannot contain them. None of the 15 held records is one of them either; those are statements of the operator from 6 July, 19 August and 16 to 22 October. An informal keyword lookup on 22 October, which is not this test, put the expected record in the top 5 for 2 of 7, at ranks 2 and 3, with one more at rank 84 and four beyond rank 1,070. Run through the same reader, the seven source units produced a matching candidate for five and a partial one for two, by the assistant’s judgment; that shows the reader can write the record, not that an index finds it. A later proposal of 27 October restates the replay as at least 5 of 7; the acceptance line and the original design say 6, and this note uses 6.

2. Typing, judged by the operator (ruled with the loop, 18 October). A blind sample of the typed records is judged by level, with agreement per level and an interval. The sample of 60 records, 20 per level, has been built and the operator has not judged it. No second reader has read it. No agreement threshold is written, so this line reports a rate and does not pass or fail it.

3. Use, on fresh pairs (ruled 3 September). The operator’s ruling for the retrieval engine applies: beat chance and beat the fallback, with an interval that excludes zero, on fresh pairs only. The first version did not (Section 5.10), the fix was authorized on 11 September, and no fresh-pair result is cited in this note.

4. Replays (proposed; thresholds for the operator to set). The assistant proposes replaying the nine same-window and compaction pairs of Section 3.3 and the ten stops of Appendix D.2 against the same top-5 criterion once the index exists; the operator has set no threshold for either. For serving at start-up, the design of 27 October proposes one replay: a fresh session is asked for the strategic view of the project with the served section loaded, and it passes if the answer frames the project by what it keeps and cites at least one held line, and fails if it frames the project by buyers, revenue or output volume. That is one question, so it can show a failure and cannot show reliability. Wisdom has no pass line; Section 5.11 describes how an effect would be observed, by replaying the same decision with and without the record.

What would show the design fails. The loop is a bet, stated before anything is built. It fails if changes admitted from held records do not beat the current harness on their replay sets, if their forecasts written in advance do not come true when their windows close, or if the retrieval test of Section 6.1 does not reach its pass line. Each of these is scored by something the change cannot edit.

6.2Where each part stands on 29 October 2026

The counts were re-read from the operator’s memory database, opened read-only, on the draft day. The level column of its main record table still has 0 of 36,657 records filled. The separate table of typed records holds 1,081 rows: 1,066 candidates (914 knowledge, 66 insight, 86 wisdom) and 15 held records (7 knowledge, 6 insight, 2 wisdom). The same statement may be both a held record and a candidate, so the two sets are not claimed to be disjoint.

7Outside studies support a check at the stop; serving an insight as evidence is untested

Reading Exhibit 8. The top bar counts the findings in the cited studies on a check at the stop, and the lower bars give each source’s age: 33 of the 56 outside sources are a month old or younger on 29 October 2026. For serving at the stop the claims table gives 10 supporting findings, 4 complicating findings and 2 untested parts: an outside model reading past conversations, and work orders as the form of the push. The plate does not sort the other parts of the plan; in the text below, capture and promotion rest on memory and lesson studies, matching and wisdom on no direct test. The classification is the assistant’s reading, for the operator to adopt or not. Each part below gives its status in the plan, then the studies newest first.

7.1Capture

Status. Capture as the position moves was approved on 20 October and is not built; 1,066 typed candidate records, loaded on 22 October, are not judged. Newer studies favor keeping the raw exchange and versioning it. He et al. (Memory Tax) (4 days; main text read): 90 of 99 memory-system cells fell below naive retrieval over raw history (no Claude model). Peng (MemoryTax) (8 days; full text): on one conversation, Claude Opus 5.5 reading the raw file scored 99% against 87% for Zep. Y. Wang et al. (Tether) (11 days; abstract plus a text search): atomic-fact memory published 62% of objects whose failure lay upstream, against 0.3% when each verdict recorded the versions it derived from (simulated chats). Nakayashiki (Lessons from Luck) (17 days; partly read), the one study to test the Claude 5.5 models on written lessons: a lesson from a chance failure was carried by 6 of 11 models, and Claude Opus 5.5, Sonnet 5.5 and Haiku 5.5 were each bounded below 0.10 (synthetic worlds). Older: Zhang et al. (memory) (169 days, v2 29 Aug; full text, sections read) found that repeated consolidation by a model degraded memory, and the nightly typing pass is such a consolidation. Typed records are untested as a remedy: that study has no typed-schema condition (full-text search), and Fan et al. (KEEL) and Y. Wang et al. (Tether) do not isolate typing.

7.2Promotion

Status. The gates for knowledge (a forecast scored) and insight (held if it raises knowledge’s hit rate) are proposals from the debate; wisdom only on the operator’s ruling is his own line. Fifteen held records (7 knowledge, 6 insight, 2 wisdom), confirmed by the operator on 27 October, were loaded on 29 October at 16:44 UTC; nothing serves them. Gating has the nearest support. Fan et al. (KEEL) (4 days; full text): verified lessons lifted Claude Opus 4.6 from 44.0 to 65.7 on 166 tasks, but Haiku 4.5 fell from 37.3 to 28.9, and the tasks have verifiers. Pham et al. (Randomized Block Curation) (16 days; abstract plus a text search): curating lesson blocks by randomized measured effect raised average success to 66.9 against 55.5 for the whole playbook (open models), by task success, not a forecast. Forecast scoring is used to train forecasters (Afifi et al., weight-level), and nothing found tests Brier-scored forecasts as the signal that promotes lessons with no weight change: not found at this search depth (6 queries on arXiv and OpenAlex, 29 October 2026). The insight gate had no search of its own.

7.3Serving at the stop

Status. The lookup boundary is proposed in the plan the operator approved on 29 October and is not built; a stop hook reaches coding agents now, and same-session serving is not ruled. Serving at start-up was approved on 27 October and is not built. A check at the stop has the most support, in a narrower form than the design assumes. Zhang et al. (Rethinking Verification) (4 days; main text read): an enforced completion gate gained 4.0 points on Terminal-Bench and 5.3 on SWE-bench Verified, a critic reading the full trajectory 9.5 and 3.9, against 3.3 and 3.9 for a prompt instruction alone (seven frontier coding models; no Claude or GPT model). Chen et al. (Knowing When to Stop) (7 days; main text read): a rule-based monitor that surfaced the evidence pattern raised restored task success from 7.6% to 21.8% (one 30B open model). Zhang et al. (Judged Useless) (24 days; full text, sections read): an enforced integration step raised failing-source success for every model, while a stopping rule in the prompt was followed at most partly.

Narrower support, newest first. Gill et al. (15 days; abstract only) reports a trained predictor that flags a run’s success long before it ends; it is not a reader of conversations. Mehta and Datta (129 days, v2 12 Oct; full text, sections read) concludes that a stability signal cannot replace an independent correctness check. Srinivasan and Paragiri (142 days; full text, sections read): an external loop audits candidates after the agent decides and can reopen a run it called finished; the authors call the evidence narrow, one certified run. Cao et al. (169 days; full text, sections read) used Claude Sonnet 4.6 with an outside controller over the model’s own confidence reports and lifted pooled accuracy from 48.3 to 56.9 on benchmark tasks. Al Nazi and Dipta (169 days; full text, sections read) found that models rarely keep to budgets they declare and that their plans collapse under enforced budgets; it shows the gap between advisory and enforced control, not that enforcement helps.

Dated background and the correction. Liu (68 days; full text, main text re-read) was the design’s main support on 18 October: a certificate gate cut unsupported stops from 40 of 66 trajectories to 0 of 66 (synthetic tasks), while a model reading the full trace falsely continued on 21 of 66 clean ones. The newest benchmark reverses that ranking: what is supported is a check enforced outside the prompt, by a rule or a model.

Untested. Serving an insight as evidence is untested. No test was found of an outside model reading past conversations to recover lost insights and serve them at the next act: not found at this search depth (22 queries on arXiv, OpenAlex and alphaXiv, 29 October 2026). Models that read one run’s trajectory exist (Nagarajan et al. (Write Once, Check Many) (12 days; partly read); it audits compliance, not insights). For work orders, 5 queries found only advisor models that write per-input advice for a frozen agent (Koyluoglu (HSAD) (20 days; abstract only)).

7.4Matching

Status. Matching by the question settled, judged by an outside model, is proposed in the plan approved on 29 October and not built. The operator proposed the form: “the outside model, interacing with the frontier”². The one measurement is the operator’s own, from September: word similarity gave a lift over chance of 0.100 (interval -0.043 to 0.237) on 93 held-out pairs and 0.054 over the fallback (-0.097 to 0.194); both intervals include zero, so that version did not clear its pass line. Tang et al. (24 days; abstract only): retrieved memories can mislead even when correctly stored, most under partial query-memory overlap. No study found tests a model judging whether a new question is one a record already settled; no query was written for this part alone, so it is untested, not searched.

7.5Wisdom

Status. Serving a ruled priority, with its assumed objective, at a decision of that kind to weigh and not obey is proposed in the same plan and not built; two of the 15 held lines are wisdom. Du et al. (Relic) (33 days, v2 29 Sep; abstract plus skim): lessons bound to the runtime as executable protocols lifted software-team correctness from 34.6% (readable text) to 41.2%, which is evidence for the rule form, not for wisdom. Argyris (via a secondary source) (1999; snippet only) describes double-loop learning as changing the governing variables, the human analogue of a ruled priority. No study found tests serving a priority at a decision, and no query was written for it: untested, not searched.

7.6Revising the harness from its own feedback

Status. Feeding the change step from held records is proposed (Section 5.6); the operator’s merge as the last gate is in the plan of 16 August, and fresh-evidence admission is proposed (Section 5.7). Wei et al. (Self-Evolving Agent Harness) (16 days; partly read) is the closest account of the whole loop and its persistence: a harness revised from its own runs while the weights stay fixed, with persistence across runs, admission on fresh validation and a final judge outside the editable surface. It is a survey with conditional theory, and its cases are drawn from other papers rather than matched-cost comparisons; it warns that temporary workarounds can become standing rules and that successful runs can yield skills that generalize harmfully. Zhao et al. (13 days; abstract only) found that failure-derived experience repairs failed tasks but rarely generalizes, which matches what the nightly pass produced (Section 4.2). Studies already feed this step from corrections captured in conversation, newest first. Giampieri (Cortex) (20 days; partly read) writes a skill or rule from recurring developer corrections and keeps it only if repeated runs with and without it show a net gain; the developer was a script in its evaluation. Y. Zhao et al. (TRACE) (80 days; partly read) mines user corrections from conversations and sends context fixes to human review, a step it did not evaluate (60 synthetic traces). A deployment report of 13 July, Aggarwal and Farhady Ghalaty, codifies each code-review comment a human accepts as a rule, with no controlled baseline. Zhou et al. (TellOnce) (140 days; partly read) turns conversational corrections into persistent rules and runtime checks, with simulated users. In each the input is a correction, a miss in this note’s terms, and admission is automated, measured or reviewed on the fix, not ruled on at a level. No study found types the input as insight or wisdom, promotes it by level, or admits the change on the operator’s ruling: not found at this search depth (61 queries on arXiv, OpenAlex, Semantic Scholar, alphaXiv and Hugging Face Papers, 30 October 2026; Semantic Scholar answered 2 of 19 attempts, and two further search services returned nothing).

8Every count here rests on one rater and a partial search

Reading Exhibit 9. Four rows, each resting on one rater: 18 of 48 hits were true losses in a random sample (37.5%, Wilson interval 25.2 to 51.6%); 31 of the 104 hand-labeled losses have a located formation (29.8%); 7 of the 34 located losses are insight by the Terms test (Section 3.5); and no reader outside the Claude family has labeled anything (0 readers). Hits are the search’s matches, not losses, and the 104 are the hand-labeled losses among 337 events.

One rater, and the rater is the model under study. A Claude model labeled the losses, reading text written by Claude models and the operator’s messages. No reader outside the Claude family has checked any of it; a second reader from a non-Claude model re-labeling a blind sample of 48 hits is an open task, not done. The debate record is likewise one reading of one session by the assistant. Five of its replies are cut off, the operator’s image-only message³⁰ was not opened, and two later messages^11,12 are read from the session table and fall after the record’s scope. The ten-stop count is one reader’s classification and provisional.

A lexical search and a partial formation search. The lexicon finds the losses someone noticed in the words the operator and the agents use; hit precision is 37.5%, so most hits are not losses, and the counts are of losses noticed and labeled by one rater, not rates. The formation search was systematic only for the high-confidence events and the first 24 medium ones, so 73 of the 104 insight losses have no located formation, and the median gap is conditional on a loss having been noticed and on that search. The 34 pairs are not independent: two couples share a loss and two share a formation. Counting each of the 32 distinct loss turns once, the median gap is 3.29 days (4.37 for the 34 pairs), with an interval of 1.09 to 10.04 under a cluster bootstrap by loss turn and 0.89 to 9.49 under a median of cluster medians.

One operator, one session, one case. Everything about what holds is one operator’s practice, and the rules paper reports one practice too. The in-session case in Section 3.1 is one case, with one plan caught in 83 seconds. Its timestamps, including the 09:29:24 injection and a cut-off display of the memory row, come from the session’s memories table as read on 18 October and were not re-queried for this draft.

The plan is a design, not a result. On 29 October 2026 nothing is served: capture and start-up serving are approved and not built, the lookup boundary at the stop is designed and not built, and same-session serving is not ruled. An informal lookup on 22 October put the expected record in the top 5 for 2 of 7, and the one serve-side measurement, by word similarity, did not clear its line (Section 7.4). No statement in this note says that serving an insight helps.

The candidates are not judged. The 1,066 typed candidate records (914 knowledge, 66 insight, 86 wisdom) were typed by an AI model. The operator has not judged them, including the blind sample drawn from them, so the levels are a model’s reading. The 15 held records are the operator’s own statements, confirmed on 27 October; the database may hold one statement as both a held record and a candidate, so the sets are not claimed to be disjoint.

Outside sources. 21 of the 56 were read at abstract depth only, with a text search or as snippets or secondary summaries (the Croskerry sources, the Ackoff and Argyris summaries and the Simon entry), so what the note claims from them is what the abstract says. Several results are on older or small models and do not transfer to the assistant by default. Only Nakayashiki (Lessons from Luck) and Peng (MemoryTax) test the 5.5 lineup on a note-relevant claim. Matching and wisdom had no query of their own, so for them the absence of a test means untested, not searched.