4. A build that carries its learning forward · Convergence Programming

Each feature should carry forward what the build has learned about the work.

The studio owner starts with booking. Trying the app reveals that her team needs fifteen minutes to prepare the room between sessions. Once she confirms that rule, the build can implement it and check the result. When she later adds rescheduling, the preparation time becomes part of what the new feature must preserve.

This growing record is the trajectory: the prompts, assumptions, actions, observations, repairs, and decisions made over time. Convergence Programming treats that trajectory as the unit of programming. It connects what a person needs, what the system interprets, and what the software actually does.

Follow one build as it learns

Step through an illustrative studio-booking app. A rule emerges, a feature changes, and a second location gives the builder a new set of questions. Watch how the evidence carries forward while its scope stays explicit.

Six steps in an illustrative build. 1. A studio owner asks for a booking app; the first version allows back-to-back sessions. 2. Trying a full calendar reveals a problem: the team needs preparation time between sessions. 3. The owner confirms a fifteen-minute gap, the app is repaired, and the relevant booking scenarios are rerun. 4. The owner asks for rescheduling; the confirmed preparation rule remains a requirement. 5. Checks cover the earlier booking behavior and the new rescheduling behavior in the original studio. The record supports only the behavior and conditions checked. 6. The owner adds another location. Its preparation rules are unknown, so the build reopens discovery before extending that evidence to the new location.

The owner can keep shaping the software without restating every previous lesson. The build records the preparation rule, links it to the owner's confirmation and observed behavior, and carries its check into later changes. A passing retest supports the case that was run. Other requirements may still need discovery, and the second studio may operate differently.

What the record lets you decide

Two copies of an app can contain the same booking rule while carrying different evidence. One build checked that rule against the studio's actual procedure and observed the result. The other has yet to do so. The code alone does not establish that the rule matches this studio. The trajectory makes the basis for that judgment available to the next person or agent working on the build.

The practical question becomes: what can this version do, under which conditions, and what evidence supports that decision? The answer can expand as the build learns. A change of location, policy, or tool can require new observations before that answer carries over.

For builders

Keep a short record with each requirement: its source, the behavior checked, the observation, the version and conditions, and the next action it supports. Record assumptions as tentative until they have support. Attach repairs and regression checks to the requirements they affect. When the environment changes, use this record to identify which checks still apply and which questions need reopening.

For researchers

Formally, a world-grounded convergence trajectory at time t is a sequence of tuples (u_t, x_t, p_t, a_t, o_t, r_t, d_t): a lossy intent signal, world state, executable procedure or agent state, action, observation, revision, and decision. Evidence is a provenance-bearing interpretation of observations. The framework concerns latent intent, lossy signals, executable outputs, and feedback from a scoped world. It does not assume every relevant constraint can be discovered or every repair reduces the true gap. The studio is a hand-constructed explanation of the proposed process, not an empirical result.