8. How the framework shapes an evaluation · Convergence Programming

A useful implementation makes discoveries survive the next change. When a message preview reveals that a confirmation exposes private details, the system can record the requirement, repair the message, and retain a check for future revisions. A harness is the surrounding code, tools, state, and review process that helps a generator carry this work through.

The figure is a reference architecture: one arrangement of functions that supports discovery, evidence, preservation, and scoped action. Convergence Programming studies the whole trajectory. These functions can be combined, delegated to people, or implemented through different tools.

The reference architecture places a generator among functions for proposing assumptions, discovering requirements, recording known requirements and supporting evidence, checking behavior, preserving prior requirements, handling critical blockers, and bounding an action window. Each function addresses a possible failure. The arrangement is illustrative; equivalent support can live in other tools or human workflows.

A practical starting point is to record assumptions as tentative, seek observations that could change the readiness decision, carry established requirements into later checks, and state which actions the evidence covers. An assumption becomes a confirmed requirement through a relevant observation or an authorized decision. The record remains a record of what has surfaced, with open questions still visible.

Which question should the evaluation answer?

A task can ask whether an outcome was achieved, which requirements were discovered, or whether the evidence supports an action. This qualitative map separates those questions without ranking existing benchmarks.

Crossing stated versus initially latent constraints with task completion versus evidence for permission yields four evaluation questions. Benchmarks can cover several regions. The proposed convergence focus includes hidden-constraint discovery and calibrated permission; the map provides no measured benchmark placement or performance score.

For builders

Start with one requirement and trace it end to end: where it came from, what behavior changed, which version was checked, and how a later edit will preserve it. Existing tests, logs, review practices, and runtime checks may already provide parts of this support. A separate service for every box is unnecessary.

For each evidence record, keep the observation, the tested version, the relevant world conditions, and the remaining uncertainty together. When a policy, tool, or operating condition changes, inspect which earlier claims still apply before extending the action window.

For researchers

The paper relates these functions to conditional failure constructions. If a critical distinction never enters the observation history, a world consistent with that history can still require a different action decision. If an established requirement is never rechecked, a later repair can violate it. These are reasons to provide the corresponding functions, not a proof that this particular diagram is a sufficient or uniquely necessary implementation.

The remaining limits depend on the setting: some requirements may be unreachable within the available budget; evidence sources may be corrupt or share a blind spot; operating conditions may change. Readiness claims therefore remain conditional on evidence quality, scope, and the assumptions behind any risk estimate.