Superalignment

Wiki · Updated August 14, 2026

Convergence Programming

Treating a build as a trajectory that converges on intent, rather than an artifact that gets delivered.

By the Superalignment Team · Last reviewed September 8, 2026

In plain terms

Convergence Programming is this group's research program. Its core move: stop judging an AI build by its output and start judging it by its whole recorded path, what requirements it discovered, what it preserved, and what evidence backs each claim, because that record is where readiness actually lives.

Convergence Programming is treating a build as a trajectory that converges on intent, rather than an artifact that gets delivered. It is our research program, set out in the paper "Convergence Programming: Iterative, World-Grounded Alignment of Lossy Human Intent with Executable Behavior."

The plain version

Delivery thinking asks: is the thing built, and does it look right? Convergence thinking asks a different question: are human intent, the system's interpretation of it, and its real behavior getting closer together or further apart? Intent is never fully written down, signals are lossy, and behavior is what actually matters, so the unit of work is the whole path rather than any single output. What you manage is the closing of that gap, and what you measure is whether it is actually closing or only appearing to.

The problem it starts from

Language models produce executable behavior directly from lossy signals. A non-programmer can generate an artifact they cannot inspect; an agent can act through tools whose side effects exceed anything the conversation would reveal. The result is a gap between a weak inspector and a strong generator, where neither party does anything wrong and the result is still unsafe.

The gap became a mass phenomenon with what Andrej Karpathy named vibe coding in early 2025: software produced from conversation, accepted on the strength of its visible behavior, by people who could not audit what they accepted. The failure pattern that follows was documented long before the name existed, which is the subject of our teardown of the vibecoding record. The research context is the same gap at higher stakes: the alignment field's supervision problem, checking work you cannot out-think, arrives at ordinary scale the moment generation outruns inspection. This is the weak-supervisor regime that weak-to-strong generalization studies inside training, appearing at the level of a whole build.

Why the obvious remedies are not enough

Everyone who has shipped an AI system has a favorite defense. Prompt engineering. Demos. Model self-reflection. A second model as judge. Generated tests. Retrieval. A human approval step. Formal verification. Runtime monitoring. Each is useful, and the program's proposition is that each is individually insufficient for the same reason: none of them certifies a distinction that never entered the observation history. The judge model cannot check a requirement nobody stated. Generated tests test the specification's contents, and the danger lives in its omissions. The human approver is the weak inspector the problem started with.

That proposition is the paper's, and it is argued rather than proven here. It has a known partial exception: formal methods do certify behavior over inputs never observed, within the model they are stated against, which is why the boundary in this framework is the observation history of the requirement rather than of the input. What a type system cannot do is notice a constraint nobody expressed, and that is the case this program is about.

What the paper does

Three things. It names the failure: false convergence, where visible signals say a system is ready while hidden requirements remain unsatisfied, unmeasured or untested, in six distinct forms. It proves the constraint: readiness is information-limited, meaning a system cannot certify distinctions its trajectory has not extracted from the world, developed as four structural limits. And it prescribes the architecture those limits imply: record assumptions as anchors, seek falsifying observations, preserve every confirmed anchor as a regression obligation, and gate action by the scope of its evidence.

The target is not maximal uninterrupted autonomy. It is calibrated permission to act: discover the hidden constraints, repair and preserve them, bind every readiness claim to independent evidence, act inside the envelope that evidence covers, and reopen grounding when the budget runs out.

Generation produces an artifact. Convergence produces a system.

The epistemic contract

The framework's assumptions are stated as a contract, and each one is a boundary where it declines to claim something:

  • A scoped, executable task world. Claims are made about behavior in a defined world where actions can be taken and observed, not about open domains.
  • A hidden but finite ledger of requirements. The requirements that matter exist and are discoverable in principle; the framework does not assume they are known, only that they are finite.
  • Claims limited by the observation history. Readiness assertions may not exceed what the trajectory actually extracted from the world. This is the load-bearing assumption, and the four structural limits are its consequences.
  • A defined action surface. What the system may do is enumerable, so permission can be scoped to actions rather than granted wholesale.
  • Costed oversight. Checking is not free; the framework budgets it rather than assuming unlimited review.
  • Evidence valid only under stated conditions. Every observation carries the envelope it was made in: world version, policy version, tool set, distribution.

Position among neighboring ideas

Convergence Programming is convergent with several established lines, and the paper's claim to novelty is specific rather than total. Its insistence on written, auditable readiness arguments is the safety case discipline applied at organizational deployment scale. Its refusal to trust the model's own account, and its verification of the surrounding process instead, shares AI control's reframing: verify what is verifiable, which is the protocol, not the mind. Its information-theoretic bound, no certification of unobserved distinctions, is the organizational cousin of the eliciting latent knowledge worst case. And its elevation of the path over the output rhymes with process supervision in training (Lightman et al., 2023): judge the route, not just the destination. What the framework adds is the unit that ties these together, the recorded trajectory of one build in one world, and the failure taxonomy defined over it.

What it is not: a theory of all human values, a replacement for formal methods, a claim that natural language is a sufficient specification, or an assumption that every hidden constraint is discoverable.

Bounded on purpose

Convergence Programming is bounded not because it is small, but because bounded worlds make oversight measurable. Every boundary in the contract above is a place where the framework declines to claim something. The boundedness is not a retreat from the alignment problem. It is what turns abstract oversight failures into measurable trajectory failures you can run today.

Why it matters

It is the framework the products are built from. Praxis is Convergence Programming surviving contact with a real operation: Verity is the harness the limits prescribe, Resolve is what happens when autonomy reaches the edge of its evidence, and Lattice is how a build starts with operational memory instead of an empty prompt paying full specification debt. It is also our working answer to superalignment: evidence gathered from the world is the one check that does not require out-thinking the system.

Status

The paper is being prepared for release; ask us for a copy at [email protected]. It is a conceptual and evaluation-design contribution with a preliminary pilot, not a benchmark or a leaderboard, and the figures on the research page are illustrations of its arguments rather than measured results.

FAQ

How is Convergence Programming different from agile or test-driven development?

Iterative development practices iterate on the artifact and check it against tests someone wrote. Convergence Programming's claims are about the evidence, not the iteration: requirements are actively hunted rather than assumed captured, every readiness claim must be bound to independent observations, every confirmed requirement becomes a standing regression obligation, and permission to act is scoped to what the accumulated evidence covers. An agile team can exhibit false convergence sprint after sprint with a green board; the framework exists to make that visible.

Is the Convergence Programming paper published?

Not yet. It is being prepared for release and is available on request at [email protected]. It is a conceptual and evaluation-design contribution with a preliminary pilot, and the figures on the research page are illustrations of its arguments rather than measured results.

Sources