When the Process Learns

Part 6 — Put Intelligence Into the Process

The book that changed its own tools

I was writing a book about Pi agents while building the tools I was using to work on it.

That made an ordinary difficulty behave differently. A problem in the tooling was also a question for the book. A concept I was trying to explain in the book was also something I could try in the tooling. The explanation and the implementation were close enough to disagree with each other while both were still being made.

The book was becoming something I could read to understand my own working environment.

That is how I describe the experience. It is an author’s account, not a reconstructed experiment. I cannot attach a particular chapter to every subsequent change, and the surviving records do not establish that the work became faster each time. But the experience raises a question that follows naturally from the preceding chapter:

What happens when the work produces knowledge that can change the process producing the work?

Chapter 30 gave your tools a disciplined way to change. Friction becomes evidence, an assistant proposes an adaptation, you authorize a bounded effect, and the result is verified and measured before it is retained.

This chapter asks where the understanding behind those adaptations can come from. Sometimes it comes from a failed run. Sometimes it comes from explaining the very machinery you are using. Sometimes the artifact you are producing exposes a weakness in its producer.

That is a feedback mechanism. Whether it is an improvement mechanism depends on what happens next.

The chatbot ceiling

My earlier book-writing process was mostly coordination through conversation. Discuss an idea. Ask ChatGPT for a draft. Read and amend it. Send it to Claude or another model. Compare the review, revise again, and repeat for the next chapter.

It produced substantial content. It also left me carrying the connections between every operation.

I chose which version to copy, selected the context, remembered which review belonged to which draft, and decided what to move back into the manuscript. The books could grow while the production arrangement stayed almost unchanged. A better paragraph did not automatically produce a better way to manage the next paragraph.

Chapter 1 named this arrangement: you are the runtime.

There is a reason it works for a small task. A person can reconcile ambiguous feedback without building a schema. The ceiling appears when the same reconciliation is required hundreds of times. The cost of writing is joined by the cost of remembering what was written, selecting what another model should see, checking what it said, and putting the right result in the right place.

A second model can improve a draft. It can also give you another result to coordinate. Those are different consequences, and the second belongs in the invoice.

The important transition is from an answer you can use once to a capability you can use again. A reviewer notices an unsupported citation; that helps one chapter. A tool reliably binds source checks to the current chapter bytes; that may help many chapters. Its value still has to be measured, but it has acquired a place where future value could accumulate.

When the machine entered the process

OpenCode changed what I could attempt. An assistant could inspect files, implement software and execute longer sequences in the development environment. It could participate in the connections I had previously operated by hand.

That was a substantial practical expansion in my experience. It was not yet a dependable production system.

Experiments with roughly twenty plugins and associated tooling produced context interference, excessive resource consumption and accidental credential exposure. Those failures are part of the account. They cannot be turned into a charming story about learning quickly.

A credential exposure is an unwanted effect. Too much context can bury the task. Too much activity can consume the budget before anything is accepted. An installation full of capable components can still be a badly governed arrangement.

The account supplied for this chapter does not include a dated incident inventory or enough sanitized evidence to apportion responsibility among the plugins. I cannot report an incident rate or prove which later design choice followed from which failure. What the episode establishes as testimony is that expanding the assistant’s operational reach expanded the consequences of the arrangement around it.

The book’s boundaries matter even more when the target is that arrangement itself. An assistant that proposes changing a tool must not acquire permission to apply the change merely because it can edit the file. A runtime capable of modifying its own checker must not decide that the checker is wrong because the checker rejected its proposal.

Keep the roles where the book put them:

The object being changed can move up a level. Ownership of the decision does not have to move with it.

Learning Pi by writing Pi

Pi offered another architecture to explore. I researched its boundaries, wrote explanations of them, used the mechanisms in software, and worked on Writer, Worker and Workbench alongside the manuscript.

In my account, these activities informed one another. Explaining an agent made a design choice more visible. Using an implementation made an explanation harder to leave vague. A problem in the tools gave the research a concrete question. The resulting explanation could suggest another implementation.

The surviving repositories make parts of that story inspectable, but they also bound it.

The Pi manuscript currently contains 44 numbered chapter files; the original plan was approximately 45. It is distinct from the pi-agents examples repository. Writer compiles and checks writing-related structure. Worker owns shared execution concerns. Workbench provides a surface for context, candidate edits, review and application. These are separate responsibilities, not evidence that one self-improving agent wrote the book.

Consider three local records.

On 28 September 2026, Writer removed its legacy model-execution runtime. Its commit records a consolidation of execution ownership in Worker, with substantial deletion. That is a concrete architectural change. The line count does not measure improved productivity, and the record inspected here does not name a Pi chapter as the cause.

On 12 October, a Pi documentation review identified errors at the manuscript’s existing version pin as well as differences in a newer release. The correction commit changed five chapter files. The review kept documentation comparison separate from live-runtime qualification, and the existing pin remained authoritative. Research about the system changed the description of the system; it did not justify pretending the whole book had been qualified on the new version.

On 13 October, Workbench strengthened the boundary at which a reviewed chapter candidate can be applied. The inspected code checks identities for the chapter bytes, candidate, review, metadata, improvement specification and validation version. If the evidence changes after the author has seen it, the application refuses before reaching the write path.

That is the shape of Chapter 21’s binding obligation in actual tooling. It is a source observation about that path, not a fresh proof of the entire application.

These records support a modest conclusion: the work was accompanied by explicit, versioned correction of books and tools, including changes that preserve authority and evidence. They do not supply the missing causal chain from a particular passage in Pi Agents to a particular tool improvement, or the cost of the next accepted chapter.

The stronger personal account therefore remains attributed. I experienced the book as teaching me how to improve the tools. The historical evidence establishes changes consistent with that experience. A prospective experiment must establish what the mechanism buys.

The case-study evidence map kept with the author’s research notes keeps testimony, commits, source observations, recorded tests and new checks separate so the narrative cannot quietly borrow the authority of a measurement.

Three locations of amplification

It helps to separate three places where the gain could occur.

Inside the process

The model contributes to the immediate work. It drafts a chapter, identifies a possible contradiction, proposes a repair or writes a test.

The result belongs to that task. Even when it is good, the next task may start with the same workflow and the same weaknesses.

Outside the process

The assistant helps change the surrounding machinery: context selection, evaluation infrastructure, accounting, recovery or mechanical manuscript checks.

A verified improvement may be used repeatedly. A reliable quote checker can remove a recurring source of clerical work. A faulty quote checker can remove a recurring source of scrutiny. Persistence multiplies both possibilities.

As a result of the process

Doing the work changes what the author understands. Explaining an execution boundary makes an implicit assumption explicit. A code example fails and exposes an incorrect sentence. An implementation forces a distinction the prose had blurred.

This third location is easy to miss because it does not immediately produce a patch. Its product may be a better question.

It is also easy to overstate. Having a long explanation on disk does not establish that its author has learned it. If the assistant writes the explanation and the author barely reads it, the artifact may contain knowledge the operator cannot apply. Learning has to be assessed through later decisions or independent performance, not through word count.

Preparation for teaching offers one possible mechanism. Nestojko and colleagues found better organized recall when participants expected to teach material; nobody actually taught in those experiments. That supports investigating explanation as a learning activity, not assuming that generating an AI-written book improves its author’s engineering judgment. Nestojko et al., 2014.

The coupled arrangement is:

    flowchart TD
    W["Versioned production workflow"] --> A["Artifact and preserved observations"]
    A --> K["Source-linked insight or unresolved question"]
    K --> P["Candidate process change"]
    P --> T["Isolated comparison with incumbent"]
    V["Independent evaluation<br/>fixed reference and unseen tasks"] --> T
    T --> D{"Meets declared rule<br/>and authorized?"}
    D -->|No| R["Reject or revert<br/>retain the reason"]
    D -->|Yes| N["Retained workflow version"]
    N --> W
    R --> K
  

The diagram is a proposed architecture. It is not a drawing of a measured productivity curve.

Its useful loop is not “the AI agreed with itself.” It is an artifact exposing an insight, an insight becoming a candidate, and a candidate surviving a comparison that it does not control.

The principle is older than the model

The proposal belongs to a long history of people improving the means by which they think and work.

Engelbart’s augmentation framework treats artifacts, methods, language and training as interacting parts of a system. Reading a book alongside a changing tool fits that tradition; the mapping is ours. Engelbart, 1962.

Organizational learning distinguishes correction within governing rules from changing those rules. Argyris, 1977. In this workflow, fixing a citation inside an unchanged review procedure is one kind of learning. Discovering that the procedure mistakes source presence for source support is another.

Software already does much of the practical work. Tests expose deviations. Continuous integration brings feedback closer to a change. Version control preserves alternatives and makes rejection recoverable. Fowler, original Continuous Integration article.

Generative AI changes the supply of proposals and the cost of some construction. It can help an operator articulate a weakness, search for a possible repair and implement a candidate without first mastering every implementation detail. It does not invent the feedback principle. It does not make the proposed repair correct, and it does not make the remaining engineering free.

The new possibility is a shorter distance between discovering a need and trying a bounded adaptation. Whether that shorter distance produces more value depends on the evaluation and selection that follow it.

When the loops meet

We need enough state to distinguish a learning system from a busy one.

Let the state at step t be:

S_t = (W_t, K_t, V_t, R_t, I_t+, I_t−)

W  workflow, tools, contracts and permissions
K  source-linked knowledge, including unresolved and refuted claims
V  evaluation version, reference set and known limitations
R  remaining human time, attention budget, money and compute
I+ retained changes and the evidence for retaining them
I− rejected, failed, reverted or superseded changes

This is proposed notation. The records can be ordinary files and a ledger; nothing here requires a model to hold the state.

Artifact quality is a separate observation: did this chapter meet the declared factual and editorial criteria? Process quality is a profile: accepted work, rework, latency, cost, recovery and wrong acceptances. Evaluation capability is another profile: what defects the checks cover, how often they miss or falsely flag examples, and which judgments remain unresolved.

Human attention is particularly hard to turn into a scalar. Review minutes, interruption count, pending-review age and detection of seeded defects are observable approximations. None reads a person’s mind. Record them separately instead of inventing an “attention score” that makes all four look equivalent.

The starting equation from this investigation can now be read carefully:

Capability(t+1)
    = Capability(t)
    + VerifiedImprovement(t)
    − Degradation(t)

It is bookkeeping shorthand, not a validated law. To make it meaningful, choose one capability metric, one task distribution, one budget and one evaluation regime. You cannot add a gain in citation accuracy to a loss in review minutes without declaring how those quantities are valued. A later model, easier task set or more permissive evaluator can increase the number without improving the workflow.

A more useful definition is a performance profile:

P(W, D, b, V)

performance of workflow W
on task distribution D
under resource budget b
measured by evaluation regime V

If the workflow changes, compare it with the incumbent under the same regime. If the evaluation changes, establish a bridge before comparing scores. If the author learns, an old workflow run by the newly experienced author is not the same baseline as the original run. The person is part of the system and part of the causal problem.

Five things can now move independently:

The first row can increase while the other four fall.

Feedback is not improvement

A related local experiment makes the distinction unusually concrete.

Sidecar observes and proposes beside an agent rather than quietly editing its context. During a Language review exercise, three proposals were assembled into packets containing the frozen chapter, proposed text, validation record and scope information.

The third proposal changed a qualitative decision rule into a numerical one: gain should be at least twice cost. The packet caught the unsupported threshold. It also produced a false finding of its own.

One criterion searched for the original phrase and, when that phrase disappeared, claimed the requirement that gain exceed cost had been lost. At positive cost, however, a gain of at least twice cost still exceeds cost. The wording had changed; the reported semantic weakening had not occurred.

The evaluator’s explanation was itself an unsupported claim.

The review record preserved the original packet, narrowed the reason used in future packets, and separated the genuine threshold problem from the false positive. A later recorded reviewer account rejected the threshold but also disagreed with the agent about the other edits. The packet had changed one reviewing agent’s decision. It had not been shown to change the reviewer’s decisions. The record is the Sidecar project’s planning/packet-review-batch.md.

This is a related tool episode, not a missing Pi chronology filled in by analogy. Its value is that it shows both directions of feedback: the process found a defect in the artifact, and examination of that finding found a defect in the process.

For this investigation, the packet verifier was read and rerun against all three saved packets. All three passed its hash, change-count and containment checks. The third packet still records failed editorial criteria. The verifier reports those criteria; it does not recompute their meaning, nor does it validate the contents of the saved diff. Its PASS establishes the properties it actually rechecked.

Chapter 21’s three questions apply without modification:

• Independence: Did something other than the generator’s completion claim obtain the observation?
• Adequacy: Does that observation test the property being asserted?
• Binding: Does it concern the exact candidate and state being accepted?

A frozen evaluator can still be wrong. A separate evaluator can still share the generator’s assumptions. A correctly bound check can still prove only that a phrase changed.

The improvement loop therefore needs a way to correct its evaluator. That must be a separate intervention. Preserve the old observations and verdicts, validate the new checker against an external reference, record its changed scope, and establish a new measurement regime. Do not let an optimization candidate change its own pass condition in the middle of a comparison.

The system can improve the process that improves the process. It cannot do so responsibly by erasing the boundary that made improvement distinguishable from a claim.

Can improvement compound?

When the process learns — feedback is not improvement:

When the process learns.

“Compound” can mean several things, and the stronger meanings need stronger evidence.

A retained checker saving the same ten minutes on each later task produces recurring benefit. That can be valuable without acceleration. A collection of retained changes may accumulate into a better production workflow. Stronger still, one change may make it easier to find and verify the next change.

That last possibility is the question here:

Does an accepted process improvement reduce the total time or cost of producing subsequent verified improvements, without weakening their quality or evaluation?

Recent agent research makes the distinction practical. AFlow searches code-represented workflows. Gödel Agent modifies agent logic under task feedback. These are precedents for changing the procedure; neither supplies a result about this author’s book-production economics. AFlow, Gödel Agent.

AIDE² reports seven accepted harness improvements during an eight-day experiment, with external benchmark transfer. But its separate test of whether an improved agent was a better improver was inconclusive. That is precisely the stronger question this chapter must preserve. Srikanth et al., 2026, §3.6.

MASS combines workflow optimization and training, reporting token-efficiency gains over two cycles. Its homogeneous evaluation and sharp intermediate regressions limit the inference; accelerating the gains remains future work. The proposed experiment here keeps model weights fixed and acceptance outside the candidate. Lee et al., 2026.

These reports are evidence for bounded mechanisms in their own settings. They do not establish accelerating improvement in open-ended writing. The distinction between harness changes, output refinement, evaluator changes and model training also matters; a recent taxonomy separates these targets rather than grouping them under one name. Chen, Wang and Qu, 2026.

For our workflow, a lower cost on the next improvement might mean the new machinery helped. It might also mean the next defect was easier, the author had practiced, or a provider changed. A run of accepted changes might reflect a rich backlog of obvious faults rather than a permanently improving search process.

There are economic limits even when the changes work. Easy improvements run out. Maintenance grows. Evaluation consumes attention. A more complex harness can require more work to understand than it saves. A change that pays off for one book may be unusable for the next.

Suppose, illustratively, a checker takes four hours to build and validate and saves ten minutes per accepted task. Ignoring maintenance, it breaks even after 24 uses. Add an hour of maintenance and the threshold becomes 30. If it also causes false alarms, those minutes belong in the calculation. These numbers are invented to show the accounting, not measured results.

More improvements are not always the objective. The best improvement may be deleting a component, freezing a satisfactory procedure or deciding that the next candidate does not earn another hour.

A process that learns must be able to learn when to stop.

Where the feedback becomes harmful

The failure modes are the book’s existing ones, coupled more tightly.

A mistaken explanation becomes a tool. The manuscript says source presence establishes support. The checker implements that rule. Later drafts pass the checker, and those passes are used to defend the sentence in the manuscript. The same assumption has traveled around the loop and returned wearing a verdict. Break the circle with source-level adequacy and an external example that exposes it.

The evaluation learns the wrong lesson. A useful-looking edit fails; the assistant weakens the criterion; the score improves. That measures accommodation. Evaluator changes require their own evidence, independently of the candidate they would rescue.

Context accumulates faster than understanding. Logs, plugins, previous judgments and manuscript drafts compete with the current task. Durable memory does not require indiscriminate context. Preserve the observations, then select what this call needs and record why.

The improvement budget becomes unbounded. One problem suggests a framework, the framework suggests an index, the index suggests a dashboard. Every step looks useful. None has finished the original task. Budget generation, execution, storage and review separately; define a terminal state for each increment.

Power crosses authority. A tool can edit its host, read credentials or write acceptance records. That says nothing about whether it may do so. Grants, isolation and verification remain external to the proposal. Repository rules are useful declarations; they are not containment.

The proxy improves while the book gets worse. A score rewards more citations, more headings or longer explanations. The chapter becomes cumbersome and unsupported claims hide among the additional text. Mechanical metrics should measure their declared properties. Reader usefulness and factual adequacy need their own assessment.

Complexity compounds instead of capability. Each repair introduces another component. The number of moving parts becomes the system’s main accomplishment. Include deletion and simpler alternatives in the candidate space, and count lifecycle cost.

More output consumes the reviewer. Generation outpaces meaningful acceptance. Queue age grows, scrutiny thins and nominal approvals replace evidence. This is Chapter 5’s problem with a new source of volume. A bounded admission rate can be more valuable than a faster generator.

One workload wins and another regresses. A checker works on plain prose but rejects tables or wrapped paragraphs. Aggregate scores hide it. Compare per item and preserve critical regressions; replay previously accepted material before retaining a change.

Book, code and runtime diverge. A release changes the rule. The chapter describes the old version. The example uses a third version. Pin the claim’s authority, link it to source or execution, and record the drift. A documentation review is not live qualification.

The apparent gain was free labor omitted from the bill. The tool saves model calls but costs an evening of author attention every week. Count building, review, retries, failed candidates, rework, cleanup and maintenance. If unknown costs remain, the conclusion remains qualified.

The architecture makes these failures observable and some of them refuseable. It does not make every verifier adequate, every grant authenticated, every process contained or every useful insight true. Chapter 29’s composition warning still holds: the arrows need evidence too.

Build the loop

Begin with a prospective comparison rather than a retrospective productivity story. A fuller preregistration template is in the author’s research dossier; the essential design follows.

Three conditions

A — Manual AI workflow. Use the existing chapter drafting and cross-model review arrangement, with human coordination and no new workflow adaptations.

B — Fixed AI-assisted production. Use an instrumented production workflow for chapter tasks, but freeze its machinery throughout the comparison.

C — Controlled process improvement. Start with B’s workflow. Permit bounded proposals for changing C’s isolated copy, subject to independent checks, explicit authority and versioned rollback. Retain passing changes in C between task blocks.

A already uses AI. The question between A and B concerns the arrangement around production. The question between B and C concerns the added improvement mechanism. Do not call an existing manual AI process a no-AI control.

Comparable tasks, declared before assignment

For a feasibility pilot, enroll six matched triplets of frozen chapter-revision packages: 18 bounded tasks. Match length, factual burden, citation complexity and intended revision. Randomize each triplet across the arms and counterbalance the order in which the author performs them.

Use distinct but comparable packages. Having one author revise the exact same chapter three times mostly tests what they remember. A machine replay on identical inputs can answer a different, narrower question about the software.

Freeze the style guide, source packets, allowed models and acceptance criteria. Record the actual responding model where observable; unknown revisions remain unknown. Keep C’s changes out of A and B. The author cannot unlearn C’s insights, so a single-author comparison will still have human carryover. Name it and use independent authors or operators in a confirmatory study.

Six blocks make the protocol tangible; they are not a sample-size argument. Use pilot variance to plan the study that could detect the effect required for adoption. Do not count individual paragraphs as independent replications of an author.

Equal total budgets

Give each arm the same ceilings for model/compute spend and active human time. C’s proposals, tests and failed changes consume its ceiling. Its improvement work is not a free service beside the production bill.

Illustrative pilot ceilings are $300 and 12 active author hours per arm, with a separately bounded reviewer allocation. C can attempt at most one change per block, six in total, using at most an hour of author time per change. Those values must be chosen for the actual tasks and frozen before a run; they are policy examples, not discovered optima.

Reserve verification capacity independently of generation. An exhausted model budget must not prevent the process from checking, classifying and recording what it already produced.

Record active author time, waiting time and reviewer time separately. Concurrent agent work complicates elapsed-time accounting. A task running in the background while the author does other work does not occupy the author for its entire duration, but interruption and reintegration may still consume attention.

The measurement problem is real: METR’s early developer trial found a slowdown despite perceived speedup, while its later update described severe selection and timing problems and only weak evidence for newer gains. Carry both findings; neither gives this workflow its result. METR, 2025, METR, February 2026.

Accept outside the generator

Mechanical checks come first where they are adequate: parseability, reference existence, exact quotes, number consistency and edit containment. They do not settle whether a source supports the argument or whether the explanation helps the reader.

Give anonymized outputs and source packets to two qualified reviewers using a frozen rubric. Randomize presentation order. Preserve their separate verdicts and adjudicate disagreement with a third reviewer. Model self-grades are not part of the outcome. The author retains authority over publication separately from experimental acceptance.

Reviewers can disagree, and writing style can reveal a condition. Blinding reduces some bias; it does not prove independent judgment. Calibrate on a separate set containing known unsupported claims, stale evidence and substantive contradictions, then retain both misses and false alarms.

For each accepted task, preserve the exact artifact, checks, reviewer evidence and workflow version. Follow it for a declared period, such as 14 days, for rework and regressions. That window is a bound, not proof that no later error exists.

Count the cost of failure

The headline outcome should combine arrival with the cost of reaching it: total active human minutes per independently accepted task meeting the declared factual and regression criteria. Show the accepted-task count, unresolved count and total spent beside the ratio. If nothing was accepted, the ratio is undefined; the failure and its cost remain results.

Also report model and computational cost, reviewer effort, elapsed time, factual errors per audited claim, unsupported claims, cross-chapter contradictions, rework and regressions. Preserve C’s proposed, accepted, rejected and reverted changes. Unknown provider spend must not be replaced with zero.

Compare matched blocks and per-item outcomes, with uncertainty at the block level. Do not exclude unfinished tasks or relabel them as setup work after assignment. Show total investment and later production cost separately; a steady-state saving can exist while the total intervention remains uneconomic.

Stop at the enrolled blocks or budget. Halt after an unauthorized effect or credential exposure, and preserve a sanitized incident record. Revert a change that violates the frozen critical regression rule. Do not extend the run because a favored candidate nearly passes.

Then test the stronger claim

The production experiment can show that process improvement helps produce chapters. It cannot, by itself, show that the improvement mechanism compounds.

For that, freeze two versions of the improvement machinery: the initial one and the evolved one. Give them a fresh bank of comparable, pre-enrolled improvement opportunities under equal total budgets, using the same independent acceptance and transfer rule. Counterbalance operators or use separate operators. Keep an untouched final task set outside both searches.

Count the complete cost of finding, testing and retaining a change, including failed attempts. Repeat across several batches and books. A lower cost per verified transferable improvement, with quality and regression bounds preserved, would support the stronger mechanism. It would still not establish an exponential law.

This is a harder comparison. That is why it is worth separating from the easier one.

Do this now

Forty-five minutes. Make one improvement claim reviewable.

1. Choose one recent recurring failure in your real workflow. Preserve a small, sanitized input and its observed result.
2. Identify where the idea for a repair came from: a failed run, a book passage, an implementation, a review or a source. Write the link down. If it is memory alone, label it testimony.
3. State one intended benefit, one property that must not regress, and the exact permission the change would need.
4. Freeze an incumbent version and specify an unseen task that could expose overfitting. Keep the acceptance check outside the candidate’s write access.
5. Define a budget and stopping rule. Include review, failed attempts and rollback in the costs.
6. Ask an assistant for the smallest candidate in an isolated workspace. Record it as proposed until checked and authorized. Do not install it in the production workflow during this exercise.

Use this brief:

Propose one bounded improvement to this workflow.
Work from the preserved failure and the named source of the insight.
State what should improve and what must not regress.
Keep deterministic operations deterministic.
Produce an isolated, versioned candidate and a comparison with the incumbent.
Do not change the reference evaluator, authority policy or production context.
Record all attempts, costs and negative results.
Stop at the declared budget; unresolved is an acceptable outcome.
Return evidence for an adoption decision. Do not adopt the change yourself.

The result of the exercise is a reviewable experiment, not an improved process by declaration.

What this chapter established

• Production, process improvement and learning through production are different mechanisms. They can be coupled when an artifact supplies an insight that survives a governed comparison and changes the machinery used next.
• The author’s Pi Agents account supplies the motivating experience. Local records establish versioned corrections and explicit boundaries, but do not establish a complete chapter-to-tool causal chronology or measured productivity gain.
• The Sidecar packet episode supplies a narrower concrete lesson: a process can expose an artifact’s defect while its own explanation is wrong. Correcting the evaluator must preserve the historical result and establish a new evaluation regime.
• Persistent benefit, accumulated capability and more efficient improvement are different claims. More artifacts or accepted commits establish none of the stronger claims by themselves.
• The practical method preserves the book’s separation: cognition proposes, the runtime coordinates, tools act, verifiers obtain evidence, and human intent and authority remain explicit.
• The experiment must count whole-process cost, unresolved tasks, regressions and unseen-task transfer. Compounding remains a hypothesis; acceleration requires a separate comparison of the improvement machinery.

Next

The book began by moving the work around a model out of the operator’s memory and into an inspectable process. That process can now preserve more than the answer. It can preserve what the work taught you, what you tried because of it, and why you retained or rejected the result.

That does not make improvement inevitable. It makes improvement a question the system can answer with evidence.

Before you ask how much more your assistant can produce, ask which recurring limitation of the production process you can now describe, test and repair. Then keep the repair only if the next work justifies it.

The broader co-development of people, their language and their tools can continue in the companion books. Here the engineering obligation is precise: when the work teaches the process something, give the lesson a source, give the change a boundary, and give the improvement a test.

References and evidence

Publication metadata, methods, limitations and additional primary sources are in the research dossier (research/when-the-process-learns/research-dossier.md in the book repository). The literature cutoff is 13 October 2026. The 2026 self-improvement papers are primary preprint reports, not independently replicated results here. Local histories, exact source paths, evidence classes and the executed packet checks are in research/when-the-process-learns/case-study-evidence-map.md.