Wiki · Updated August 14, 2026
Trajectory
The whole path of a build, not the state it is in today. The unit of programming, and the thing readiness is actually a property of.
In plain terms
A trajectory is the whole recorded path of an AI build: every instruction, action, observation, repair, and decision over time. It matters because two systems with identical outputs can carry opposite risks, and the difference lives in that record, not in the outputs.
A trajectory is the whole path of a build, not the state it is in today: prompts, procedures, actions, observations, repairs and decisions over time. In Convergence Programming, the trajectory replaces the artifact as the unit of programming.
The plain version
Two systems can look identical right now and be heading in opposite directions. One has been actively surfacing hidden requirements and closing them. The other has been accumulating a high score. The current snapshot cannot tell you which is which. The trajectory can. Status reports describe a snapshot; risk lives in the direction.
The same is true of people. References ask about a candidate's history rather than their best day. An artifact is a system's best day. The trajectory is its references.
Why the artifact stopped being enough
For seventy years the artifact was a reasonable unit of judgment, because a person wrote it and a person could read it. Language models broke both halves: software can now be produced from a sentence, by someone who could not read the result, and it can act before anyone has established what it was supposed to do. When the artifact cannot be inspected by the person accountable for it, the only place evidence can come from is the path that produced it. What did the process ask? What did it discover? What did it preserve after each repair?
Readiness is a property of that history. Two identical artifacts can deserve opposite deployment decisions, because one trajectory surfaced the hidden requirements and satisfied them while the other never looked. Judging the artifact alone cannot tell them apart. That single fact is why demos, final code review and one-shot evals fail in the same way.
The unit of programming stops being the artifact and becomes the trajectory.
What a trajectory records
Concretely, the record the framework cares about carries four kinds of entries. What was asked: instructions, elicited requirements, and the assumptions recorded as anchors. What was done: actions taken through the system's action surface, with their permissions. What was observed: outcomes, checks, and the evidence each claim rests on, each entry carrying the conditions it was gathered under. And what was decided: repairs, approvals, escalations, and the re-verification that followed each change. An operation that can answer "checked by what, against what, when" from its records has a trajectory in this sense. An operation that can only answer with its current dashboard has a snapshot.
What a trajectory can do
One human, one system, one world, iterating. Where the loop ends up depends entirely on what the trajectory discovers and what it manages to preserve. The paper distinguishes five outcomes of the same loop, of which only one is a success, and only two of the other four announce themselves while they are happening. The quiet failures are the false convergence cases: the loop that never asked, the score that was never the thing, the repair that broke last month's fix.
A healthy trajectory has a signature that feels wrong until you understand it: it looks worse before it looks better. Discovering a hidden requirement raises the measured gap, so genuine progress shows up as bad news. Any process that rewards the dashboard will punish the discovery.
Neighbors in the field
The move from output to path has parallel versions across AI research, and they are evidence the unit is right. Process supervision (Lightman et al., 2023) found that rewarding each reasoning step outperforms rewarding the final answer, and makes gaming harder: judging the route, not the destination, inside a single response. Chain-of-thought monitoring extends the same bet to deployed reasoning models, with a 40-author position paper arguing the legible path is a real but fragile safety resource. AI control evaluations judge deployment protocols by their full interaction histories under adversarial pressure, not by per-output quality. And the older engineering institutions the framework borrows from, flight recorders, audit trails, chain of custody, all encode the same conclusion reached earlier by other industries: when the outcome cannot be trusted to explain itself, keep the path.
The trajectory generalizes these from a response, a protocol, or an incident to the unit organizations actually sign off on: the whole build.
Why it matters
Everything downstream changes when the trajectory is the unit. Evaluation stops asking "does the output look right" and starts asking "what has this path extracted from the world." Autonomy stops being a standing grant and becomes a budget the trajectory spends, which is the fourth structural limit. And accountability gets a shape: the person who signs is signing a history they can audit, not an artifact they cannot read.
What we do not claim
We do not claim every trajectory converges, or that a good trajectory guarantees a good outcome. The claim is that readiness can never exceed what the trajectory observed, so the trajectory is where readiness has to be measured. A perfect path through an unscoped world proves nothing; the bound is only meaningful inside a defined envelope.
Sources
- Superalignment, Convergence Programming, where the trajectory is defined as the unit of programming.
- Lightman et al., Let's Verify Step by Step, arXiv, 2023.
- Korbak et al., Chain of Thought Monitorability, arXiv, 2025.
- Greenblatt et al., AI Control: Improving Safety Despite Intentional Subversion, arXiv, 2023.