# An escalation policy after the Sol and Luna launch

Sol and Luna widened escalation choices, but a useful gate depends on missing evidence and acceptance conditions rather than confidence alone.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-09-22
Original announcement: https://developers.openai.com/api/docs/changelog
Canonical URL: https://retrivium.ai/retrospectives/sol-luna-escalation-evidence/

A model portfolio needs a way to say that a case has not been resolved. Without that state, an escalation policy can become a disguised preference for whichever model answers most confidently. Sol and Luna made this problem visible by expanding the choices beneath Astra.

## A release sequence, not a routing instruction

The [Responses explanation](https://developers.openai.com/blog/responses-api) from September 22, 2025 provided an earlier tool-work interface. The [dated changelog](https://developers.openai.com/api/docs/changelog) records Astra on September 3, 2026 and Sol and Luna on September 22, 2026. The [family announcement](https://openai.com/index/introducing-gpt-6-sol-and-luna/) explains the broader capability and budget range. None of these dates supplies the application-specific boundary between answering, investigating and escalating.

## Confidence is not a sufficient trigger

Consider a service answering equipment compatibility questions. A request may be easy when the exact revision appears in an approved table, and difficult when the same product name has several incompatible revisions. Similar language can hide different evidence requirements.

Escalating only after a visibly confused answer misses confident use of the wrong revision. Conversely, escalating every long question wastes capacity on well-supported answers. The trigger should concern evidence availability and acceptance conditions, not only answer length, style or self-reported confidence.

## Keep unresolved work representable

Define an outcome for insufficient evidence before choosing model tiers. It can preserve the missing field, conflicting documents and the next permissible investigation. A higher-tier model then receives a concrete unresolved problem instead of an unstructured request to try harder.

This design also protects against an invalid assumption: a stronger model cannot guarantee access to absent information. Some cases should return to a source owner or a human reviewer rather than circulate indefinitely between models. Escalation is a change of process, not necessarily another inference request.

## Test the gate with contrasting cases

Prepare illustrative cases containing an explicit answer, a missing revision and conflicting source tables. Judge them before tuning the gate. Compare whether the initial path answers the first, requests evidence for the second and preserves the conflict in the third.

Inspect cases where escalation changed the answer. Determine whether the later stage found additional evidence, corrected reasoning or merely produced a more persuasive explanation. Those are different mechanisms and should not share one unqualified success label. Retain the evidence that justified acceptance.

## The useful policy is conditional

A reasonable allocation rule links the first model, evidence requirement, escalation reason and final review object. Recheck that rule when documents, tools or task populations change. A rule learned from straightforward lookups may fail on an investigation queue.

The Sol and Luna release made more allocation strategies feasible. Its retrospective lesson is that a cheaper first stage becomes useful only when uncertainty remains visible and the next stage has a justified job to perform.

## Related reading

- [Execution authority around model decisions](/journal/openrouter-tool-calling/)
- [Comparing accepted outcomes](/journal/inference-benchmark-method/)