Superalignment

Return to the clinic intake app. A form, a queue, and a confirmation message can look complete while important local requirements remain unexamined. The useful question is what each interaction establishes, what each repair changes, and whether the next revision preserves what has already been learned.

A repair has to preserve what came before.

In this synthetic adaptation of the paper’s clinic example, an urgent-case scenario reveals a nurse-review rule. A repair and repeated checks preserve it. An SMS preview then reveals a privacy problem. Deleting the visit-reason field fixes the outgoing message but breaks duplicate matching. A narrower repair retains the field internally and excludes it from the SMS payload.

Permission and override scenarios establish access and audit requirements. A missing-insurance case establishes a staff follow-up requirement. Repairs, repeated scenario checks, and a bounded sandbox replay supply evidence for the illustrated revision. They do not certify every future condition.

The eight stipulated local requirements
  1. Capture required intake fields, established by a form review.
  2. Route urgent symptoms to nurse review, established by an urgent-case scenario and local triage policy.
  3. Order the queue by arrival and urgency, established by a queue preview and the local ordering rule.
  4. Exclude visit reasons and symptoms from SMS, established by an SMS preview and local privacy rule.
  5. Merge duplicate submissions, established by a repeated-submission scenario.
  6. Route missing insurance to staff follow-up, established by a missing-data scenario and local follow-up rule.
  7. Hide patient data on unauthenticated views, established by a permission test.
  8. Log manual triage overrides, established by an admin-override scenario and local audit rule.

The full ledger is available to the evaluator in this stipulated world. The deployed system has only the requirements and evidence its trajectory has established. The example describes fictional local software policies, not medical guidance or measured research results.

An original interactive adaptation of Figure 6 and Table 9. Discrete requirement states drive the counts; the paper’s separate illustrative weighted traces are not reused. A passing check is scoped to the stated case and revision.

Discovery changes the record. Repair changes behavior.

A newly discovered failure can increase the number of known unmet requirements even when the program has not changed. Conversely, one repair can break another requirement while leaving that count unchanged. The privacy and duplicate example makes both the identity and the provenance of a requirement matter. The aggregate alone cannot tell that story.

A rising known gap can reflect useful discovery. Its absence does not, by itself, establish either safety or blindness. Assess the observations that were sought, the distinctions they support, and the requirements that later changes preserve.

Permission stays attached to its evidence.

The target is calibrated permission to act: discover relevant constraints, repair and preserve them, bind a readiness claim to supporting evidence, and keep action inside the conditions that evidence covers. When those conditions change, or the supported autonomy budget is exhausted, reopen grounding and reassess the affected actions.

Reliable AI-assisted programming will require better generation. It will require something deeper as well: better convergence.