The event log remembers every tool call, every approval decision, every input the model has ever seen—yet not one component learns anything from that history.
This is the fourth piece in the DSH series. The third piece ended on a gap: the architecture paved the road right up to the door, and the learning loop itself was the blank. This piece fills that blank with a reference design ready to break ground on. Its nature, stated up front: this is a design proposal, not a description of dsh as it stands today. It can be implemented on a dsh fork, or on any platform that adopts that set of patterns. All dsh facts in this piece are anchored to the open-source repository source code (baseline 47f9438); the design portions are new proposal.
Prologue: After the Seven Consumers
Count, once more, the downstream consumers of the DSH event log. Six at runtime: resume (session restore), fork (branching a new session), transcript, telemetry, title generation, statistics. One at test time: snapshot replay, which replays real sessions without keys and asserts on model-visible behavior. Seven classes of consumers, each taking what it needs.
They share exactly one thing: all of them consume history; none of them changes the system. Resume puts the system back where it was; telemetry turns history into charts; snapshot replay turns history into test cases. Not a single component extracts experience from that history and feeds it back into the runtime.
Yet the raw feedstock is all in place. Every behavior is replayable: session semantics are a fold of the log, with no hidden state beyond it. Every decision is auditable: approvals leave persistent events—who rejected what, and when, is on record forever. Every model-visible input is reconstructible: whatever the model has seen, the log can replay one to one. Those three sentences together are a ready-made experience-collection format—the full raw material of a training-data collector, and the storage bill is already being paid (full zstd persistence).
The only thing missing is the final consumer: a learner.
Three Judgments
Why is this worth doing? Three judgments, stacked.
The paradigm judgment: the next split among harnesses is "can it learn." The composability fight at the execution layer already has its answer shape; the third piece told that story. The adaptation layer—improving the system from its own running history—is still vacant. Some will point to the research direction of RL directly optimizing harness decisions; whether or not that training route matures, the logs on that road are training corpus. Put differently: only when there is a structured record of "observe, propose, effect" does any learning algorithm enter the conversation. An experience-extraction pipeline on the log side is prerequisite engineering. There is no way around it.
The economics judgment: the marginal cost is very low. Session logs are already paying their storage cost; one more class of consumer is pure incremental gain. Nothing touches the runtime hot path, and no new collection pipeline is added; the only new persistence is the loop's own proposal events, a volume that rounds to zero. Engineering rarely trades this little for a genuinely new capability. This is one of the rare cases.
The risk judgment: unreviewed self-modification is a privilege-escalation channel. This is the weightiest of the three. A component that can rewrite prompts, tighten guards, add skills—and skips approval—is a superuser inside the system. The learning loop's value lies precisely in standing up the safety constraints first, then opening the adaptation capability. Reverse that order and you get an incident—and a security incident at that, not a functional one.
The Fork in the Road
DSH already contains one thing that "modifies itself": tool-cordis. The second piece dissected it—the cordis preset lets an agent edit its own runtime, executing model-written JavaScript. But it and the learning loop are two different roads.
| tool-cordis (dsh today) | The learning loop (this design) | |
|---|---|---|
| Trigger | The model decides on the spot | Driven by historical patterns (offline / turn-based) |
| Payload | Cordis plugin code | Declarative artifacts (rules / markdown / diffs) |
| Persistence | Process memory, gone on restart | Event log plus landed artifacts, auditable forever |
| Position | Can it, right now | How it should change, over the long run |
One analogy: tool-cordis is live improvisation; the learning loop is the studio album assembled afterward. The former explores possibility; the latter consolidates reusable experience. The two coexist without conflict—but self-modification in production must be the latter. Improvisation cannot be audited.
The second piece left behind an evolution-capability table: humans directing changes—implemented, and the cordis preset is the evidence; agents modifying themselves—partially implemented (the self-modification package can inspect and mount, but carries no decision logic); the system learning from patterns—blank. What the learning loop fills in is that third row.
Loop Design
How the loop turns—one figure to set the skeleton first: five stages stringing together six events, with the events landing in the learned/ namespace.
Six Events, One Lifecycle
The learning loop's own history also travels the event log—six classes of persistent events:
learned/pattern-observed pattern discovery: what pattern, which session positions it hit, statistical strength
learned/proposal-created proposal: what to change, the evidence chain (citing source event seqs), confidence
learned/proposal-decided verdict: approved / rejected / deferred, and who decided (human / automatic policy)
learned/proposal-applied landing: which layer, where, what version it produced
learned/proposal-rolled-back rollback: why, and rolled back to which version
learned/effect-observed effect observation: window, baseline, delta, confidence, notes
One lifecycle, closed: a pattern is discovered, becomes a proposal, receives a verdict, lands or gets rolled back, and its effect is observed. Two details deserve a pause. First, proposal payloads fall into three classes—prompt revisions, skill drafts, guard tightenings; that is the taxonomy of "what to change," and it is not to be confused with the six events: the six events are process, the three classes are content. Second, the effect-observed event becomes input to the next round of pattern discovery: an artifact with persistently no positive effect triggers a "recommend re-review" pattern. The loop discovers when it has learned wrong.
Five Stages
Events are the record; stages are the process. Extract, propose, gate, apply, audit.
The extract stage folds session logs offline, hunting repeated patterns. Three classes in P0 scope: repeatedly failing tool-call sequences (the shape of the same tool failing N times in a row), approval ping-pong (the same operation retried verbatim after being denied), and user corrections (the user's consecutive amendments of the same class of output). Implemented as pure-function projections: cold start is free, replay rebuilds everything—isomorphic with dsh session restore.
The propose stage turns candidate patterns into proposal events carrying evidence chains. Evidence is not the model saying "I feel like"—it is a list of source event seqs, each one openable and replayable.
The gate stage is the security core: three checks in sequence. Automatic validation—payload legality, evidence completeness. Monotonicity check—a guard-class proposal is joined with the existing policy set in a semilattice join; if the join result contains any relaxation, it is rejected outright. Human approval (approval waterfall)—the full proposal, its evidence, and its blast radius are presented, and a human decides.
The apply stage's keyword is zero new bypasses. Prompt revisions travel the existing system-prompt section mechanism, with their order in a dedicated number range that crowds nothing in the tool-guide zone; skills travel the skills seam; guard rules travel the patch configuration layer. No new change channel is opened: learned artifacts walk the same roads as human configuration, under the same laws.
The audit stage is where an independent Auditor observes effects. Note how the independence is pinned: the Auditor is a projection built into the harness, not registrable through any provider seam the learner can touch—pinned by structure, not by a verbal promise that "we don't reuse context." The metric vocabulary is fixed—failure rate, retry rate, approval rate; new metrics go through a harness change, not the learning layer. Observation windows advance on event timestamps; a session crash does not reset them, and after a cold recovery the unclosed windows are back-filled.
What One Round Actually Looks Like
The full walkthrough from the design document, played through once, is clearer than any abstract description.
The user types /learn-review. The Extractor folds the log, and three pattern-observed events land in it: a failure-sequence pattern, an approval anti-pattern, a correction-language pattern. The Proposer generates two proposals from them: one guard tightening (outright banning the parameters of an operation that fails repeatedly), one prompt revision (adding a caution line for a certain class of tasks).
Gate, first check—evidence replay; both proposals pass. Second check—monotonicity; the guard proposal's join has no relaxation direction; pass. The prompt does not fall under the monotonicity check; pass. Third check—human approval (approval waterfall). The guard proposal goes to a human; someone reads the evidence chain and approves; the decided event lands in the log; the patch layer gains one learned--prefixed rule; the applied event lands; the Auditor hangs a 24-hour observation window. The prompt proposal is deferred, TTL 72 hours; it expires unanswered and automatically becomes rejected. Fail-closed: deferral is not tacit approval—expire without an answer and it is a rejection.
Twenty-four hours later, the window closes. effect-observed lands in the log: failure-rate delta on that operation of −41%, sample size 17, confidence 0.6, notes stating "single session." That event joins the next round of extract's input.
Rollback Is Mechanical
Learning errs; rollback must be cheap. The answer lies in the patch layer's position and prefix discipline: the learning layer sits above home and below overlay in the layer order—session experience carries a semantic strength between personal global configuration and an explicit override for this one launch. All learned artifacts carry the learned- prefix; rolling back equals disabling that row, or stripping the entire learning layer, plus one rolled-back event. Append; history is never deleted.
The operation set is closed: ReplaceRow is forbidden on non-learned rows—the learning layer can never edit human configuration; revisions to learned rows themselves must re-pass the monotonicity check, and the check's baseline includes the version being replaced—you cannot quietly shrink your own previous rejection domain with a newer proposal. The patch algebra has no "inverse operation" verb; rollback semantics live on the existing verbs. Hence mechanical, auditable, no special cases.
Turn-Based, Not a Daemon
The loop is not a background daemon. One command drives one round of extract and propose; gate, apply, and audit advance asynchronously at proposal granularity. If any stage crashes, state recovers from event replay: proposals applied but not yet observed get their windows re-hung by the Auditor; proposals sitting in defer have their TTLs continued from event timestamps. No loop state lives only in memory—this property is inherited straight from the event-sourcing foundation, at zero additional cost.
The Safety Model
Three iron laws govern the loop; one direction stays sealed forever.
This is the design's intellectual core, and the reason a composability-first architecture is precisely the safety foundation a self-improving system needs.
Iron law one: learning may only tighten, never loosen. A guard-class proposal is joined with the existing policy set in a semilattice join; if the join result contains any relaxation—any shrinking of an existing rejection domain—it is rejected outright. This is the guard absorption law extended along the time axis: in space, a deny anywhere is a deny; in time, a relaxation anywhere is a rejection. A loop that learns badly can at most learn itself stricter; it cannot learn to open doors for itself.
Iron law two: guard- and skill-class proposals require human approval. Automatic-approval policies may act on prompt-class proposals only. The reasoning is plain: a broken prompt dents output quality; a broken guard dents the security boundary; a skill introduces new code. Three risk levels, three approval levels.
Iron law three: effect observation is data, not conclusions. The Auditor produces deltas and confidences, with notes stating the window and sample size, and makes no causal claims. A single-session sample cannot support a causal conclusion; small samples are explicitly down-weighted; when the sample is insufficient, it says so plainly. Honesty over completeness—this thesis cashes out once again, here in the learning loop.
At design acceptance, the design was put through adversarial testing: seven attack paths constructed one by one—injecting a malicious skill, a relaxing proposal, a forged evidence chain, proposal flooding, self-grading inflation, applying while bypassing approval, an automatic policy over-reaching its scope. Every one must be stopped by its corresponding defense, with the assertion error messages verified correct. Take the over-reaching automatic policy: the test case must include the assertion "guard-class proposal rejected by kind"—held by type discrimination, not by prompt constraint.
Three representative threats against three invariants: proposal flooding exhausting approval bandwidth—enforced by gate quotas, a turn window plus a per-session cap; privilege escalation through learning—sealed by iron laws one and two; unprovable effects—backstopped by iron law three's observation discipline.
And one governing principle: the loop itself is an event log. Every round—what was learned, what was approved, what the effects were—is fully auditable, including the auditor itself. What a self-improving system fears most is the improvement process becoming a black box. There is no black box here.
Roadmap
P0, one to two weeks, read-only start. The /learn-review slash command: no model turns, a pure-function extractor hunting the three pattern classes, read-only presentation, zero learned events landed. Risk is zero; the value stands up immediately—first see the quality of pattern discovery, then decide whether to go further. The acceptance bar is ready-made: construct test sessions containing known patterns, a fixture set of fifty-plus cases, precision and recall no lower than 90% for each of the three pattern classes.
P1, about a quarter, reviewed landing. The six events plus the gate's three checks go in fully; the prompt and skill apply paths first, the guard path after. Runtime assertions on all invariants, audit replay complete—replaying the adaptation history and the management panel agree with zero difference.
P2, cross-session aggregation, honestly labeled an open problem. Where the pattern store lives, who reviews it, how cross-tenant leakage is prevented—each of these is enough for a design document of its own. The direction holds real leverage: only a cross-session pattern base can support statistically credible effect attribution; single-session samples never will. But drawing it into P2 says "yet to be designed," not "already thought through." Same for the oscillation constraint: the tighten → bad effect → rollback → re-propose cycle currently has only quotas as a backstop; the leaning is a cooldown—same payload hash barred from re-proposal within K turns—undecided.
Coda
This design does not predict who will build it, or when it will be built. It predicts one thing: put event sourcing, monotonic policy, and reviewed changes together, and the learning loop stops being flights of fancy—it is the natural next step. The foundation has been in place all along; what it waits for is the first consumer to move.
The previous piece said DSH can execute but cannot learn. Strictly speaking, that verdict's shelf life may be down to a few months. Not because DSH will catch up—but because the first team to get the eighth consumer right will redraw the boundary line of the agent harness. Looking back from that day, "it can execute, but it cannot learn" will stand as this era's finest epitaph.
Declaration: This article was written from DeepSeek Harness open-source repository facts (github.com/deepseek-ai/deepseek-harness, v0.1.0-rc.5, analysis baseline commit 47f9438) together with the reference design "Learning Loop Design v1.2" (Judy's second review, 8.5/10); the dsh facts are anchored to the source, and the design portions are proposals—not descriptions of dsh as it stands. The first three pieces of the series are on this site. Not investment advice. Data as of August 17, 2026.