# 🧬 Adaptive Orchestration Protocol — Moon Source portable *Cross-surface execution routing and closure across Chat, Work and Codex* ## Public Portable Edition · Version 6.4 ## Meta - **canonical repository:** https://github.com/luahelenammc/Moon-Source - **canonical path:** portables/adaptive-orchestration/ADAPTIVE_ORCHESTRATION_PROTOCOL.md - **Moon Source public surface:** https://www.luahelena.com.br/moonsource/?lang=en - **professional context:** https://www.luahelena.com.br/ia/?lang=en - **website mirror:** https://www.luahelena.com.br/moonsource/downloads/ADAPTIVE_ORCHESTRATION_PROTOCOL.md - **public boundary:** standalone protocol; product and model calibration is date-sensitive and subordinate to the adapter boundary below; this document does not imply that the native adaptive-orchestration Personal Skill is installed - **status:** public portable protocol - **version:** 6.4 - **language:** English - **protocol semantics as of:** 2026-10-10 - **canonical identity migration:** 2026-09-27; formerly Chat–Work Routing Protocol, Chat–Work Router and Chat–Work; identity and paths changed while the 6.1 doctrine remained unchanged, under the repository naming/versioning rule - **product/model calibration boundary:** recheck dated adapter notes and official documentation before relying on volatile names, availability, limits, pricing, subagent controls or inheritance behavior - **primary implementation:** surface-neutral control-root routing across ChatGPT Chat, Work and Codex, where available - **Codex boundary:** optional execution capability; never assumed installed, enabled, available or desired - **governed dimensions:** execution profile, object geometry, control surface/root, execution surface/harness, root capability tier/model, behavioral fit, commitment geometry, reasoning effort, continuity/locality, delegation topology, execution envelope, operation mode, sprint envelope, budget survival, distillation, bounded exhaustiveness, auditable decision trace, model strategy adapter boundary, return closure and claim ceiling - **supersedes:** Adaptive Orchestration Protocol 6.3; version 6.4 updates the dated Chat model-availability boundary without changing surface-neutral control roots, Delegation-First, Behavioral Fit or Commitment Geometry. - **MSL dependency:** Moon Source Language 5.1; the protocol remains independently versioned at 6.3. - **license:** CC BY 4.0; see [LICENSING.md](https://github.com/luahelenammc/Moon-Source/blob/main/LICENSING.md) - **license URL:** https://creativecommons.org/licenses/by/4.0/ - **creator:** Lua Helena Moon Martins Cardoso (Moon) - **AI-assisted coauthorial development:** Áurion - **adaptation policy:** share or adapt with appropriate credit, a license link and an indication of changes; do not imply endorsement ## Canonical identity and compatibility Adaptive Orchestration Protocol is the sole current semantic authority. Its former names were Chat–Work Routing Protocol, Chat–Work Router and Chat–Work. The old registry id chat-work-routing, Personal Skill slug chat-work-router, GitHub directory, adapter paths, package path and website mirror remain compatibility routes that point here. The 2026-09-27 identity migration itself did not create a semantic release: at that migration checkpoint the core remained 6.1, Astra was 1.6 and GPT-6 Sol/Luna was 1.3. Versions 6.2 and 6.3 are later semantic updates and do not retroactively change that lineage. ## Skeleton 1. Mother law and core sentence 2. Execution Profile Setup 3. Surface roles, control roots and workload-shaped object routing 4. Routing dimensions and precedence 5. Availability, capability floor, Behavioral Fit and Budget Survivability 6. Context Diet and surface gates 7. Capability economics, model strategy adapters, delegation topology, effort, distillation, Sprint and frontier control 8. Handoff, return and Control-Root Postflight 9. Phased execution, failure and salvage 10. Lifecycle, installation and claim ceiling ## First use ### What this is Adaptive Orchestration is an instruction-level routing and closure protocol. It helps an AI read the task from the surface it is already on, separate control root, execution surface, model, reasoning effort, capability and context, coordinate direct or delegated execution across Chat, Work and optional Codex, and converge on a decision-bearing result for acceptance. Its optional Sprint Mode is an explicitly activated, ephemeral run-level pacing overlay for a finite objective; it does not create a native product feature or expose allowance economics. ### Do I install anything? No. Loading or attaching this file does not install a native ChatGPT router, create privileged OpenAI access or switch a surface, model or reasoning setting. The protocol can only use capabilities that the current product surface actually exposes. ### Start here Read this canonical file and say: ```text Read and apply the Adaptive Orchestration Protocol to this task. Start in AUTO. Preserve the current competent control root when it can complete and verify the task. Resolve execution surface, model tier, reasoning effort and delegation internally before asking me to switch anything in the UI. Before scaling work behind a materially open, costly-to-reverse solution choice, use the Decision Commitment Gate; probe, branch, side-route or up-route only when that lowers total work to acceptance. Tell me only when a manual transition is materially required. Task: [describe what you want done] ``` You do not need a frontier model or a particular surface just to initialize the protocol. Start from the current available surface and let AUTO preserve it when it can act as a sufficient control root; escalate or transition only when the task's capability floor, execution harness or verification burden actually requires it. ### What happens next The protocol should disclose the route that materially shaped the decision, preserve the current competent root when possible, prepare a bounded handoff only when another surface is materially useful, distinguish a requested switch from a switch that actually occurred, let execution converge at the designated control root, and perform postflight, acceptance and closure there. When model behavior is load-bearing, it should distinguish capability sufficiency from behavioral fit; when a solution choice carries high downstream leverage, it should resolve or probe that commitment before scaling dependent work. ### Optional Sprint Mode Sprint Mode is a run-level resource and pacing overlay, not a fourth setup mode, capability tier, model, persistent profile or native ChatGPT feature. It may activate only through `explicit_user` activation or `recommended_then_user_confirmed` activation. It ends when the objective or explicit stop condition is reached, resources or authority block continuation, the user disables it or Control-Root Postflight begins. Use it only with a named objective, a finite docket or bounded execution envelope and a visible stop condition: ```text Use Adaptive Orchestration in Sprint Mode for this task. Objective: [one sovereign objective] Docket: [finite pre-named items, if applicable] Stop when: [acceptance boundary, horizon or blocking condition] Return the Sprint Receipt and perform Control-Root Postflight. ``` Short form: `Sprint this bounded docket: [items]. Stop when [condition].` Sprint Mode may account qualitatively for perishable capacity whose future value can fall after a stated or otherwise evidenced horizon. It must optimize verified useful delta before that horizon, not spend for its own sake, and must not invent prices, reset times, allowance visibility, guaranteed savings or guaranteed fuller use. ### Manual / unavailable capability boundary AUTO should not ask the user to bounce between models merely because different parts of one task have different capability needs. When the selected Work or Codex harness exposes subagents and compatible model controls, the root should first try to assemble the smallest sufficient internal delegation topology. A manual surface, model or reasoning switch is justified only when the current root cannot delegate to the required capability, the needed harness or permission is unavailable, the sovereign object genuinely changes surface, or the root itself is below the task's capability floor. The protocol must distinguish an internal delegation from a UI switch and must never pretend that either occurred when the runtime did not expose it. You may still need to attach the canonical file, approve an external action or provide a connector/source. AUTO means “route and orchestrate with the capabilities actually exposed,” not “invent invisible control over the interface.” ### Tiny example For a multi-file documentation change, ask Adaptive Orchestration to recommend the execution route from the surface you are already using. If that surface can remain the competent root while delegating or executing the bounded edit, stay there; transition only when another harness materially improves completion or verification. The presence of a ZIP, a surface label or a prestigious model label does not decide the route by itself. ### If the first result goes wrong If the response only audits the session, provide a concrete task and explicitly ask it to apply the protocol operationally. If the route is too expensive or overbuilt, ask for the smallest sustainable route that still passes the task's capability floor and preserves the return/closure loop. ### What this portable does not claim It does not guarantee access to Work, Codex or frontier models, automatic model or surface switching, silent Sprint activation, visibility into entitlement/allowance/reset state, universal token savings or quality gains, fuller use of a quota, or that model routing itself was invented here. ## 1. Mother law and core sentence > **Executor completion is not cycle completion. Execution converges; the designated control root closes the loop.** The stable sentence is: > **The active control root understands, decomposes, routes and converges. Execution surfaces and delegated workers perform the work appropriate to their capabilities and authority. Cheap sufficient workers absorb reducible bulk; stronger or differently fitted executors receive only the irreducible execution, judgment or commitment delta. The designated root verifies and integrates; the human retains any decision or authority that requires the human.** The V4 line established tri-surface routing and object geometry. The later 4.x releases added distillation, connector-aware source transport, bounded exhaustiveness, calibrated frontier economics and auditable Decision Trace. V5.0 added optional Sprint Mode; V5.1 added model-specific strategy adapters; V5.2 added the GPT-6 Sol/Luna executor calibration and separated semantic tiers from named-model identity. V6.0 changed the routing unit itself by making delegation topology first-class. V6.1 completed that rebase at the surface layer: capability differences no longer imply either a human-operated model handoff or a ritual return to Chat when a competent current root can execute, delegate, converge and close internally. V6.2 adds Behavioral Fit as a separate routing constraint so a cognitively sufficient model can be side-routed when its observable execution behavior misses the task's acceptance boundary. V6.3 adds Commitment Geometry so a solution-defining choice can be probed, explored or routed to a suitable decision-maker before dependent work scales. V6.4 updates Chat model-availability calibration after the 2026-10-07 GPT-6 rollout without changing those routing laws. > **Escalate only the irreducible execution, judgment or commitment delta; return only the decision-bearing delta.** > **Delegate the reducible bulk before escalating the human-visible route.** > **Side-route for behavioral fit before up-routing for capability when the failure is behavioral rather than cognitive.** > **Executor suitability does not imply commitment authority.** > **Route execution, judgment and commitment independently.** > **A cheap commitment that causes expensive replay is not a cheap route.** > **When evidence shows that a solution-defining commitment is wrong, reopen it instead of polishing the implementation indefinitely.** Commitment authority here means that an executor is suitable to close a choice **within the authority and mandate already granted**. It never grants approval, mutation permission, human decision authority or a broader scope. > **Transport source references with authority, freshness and fallback; a locator is not authority.** > **Bound completeness before expensive execution; discovering scope is not permission to execute all of it.** > **Show the decision boundary, not the private deliberation.** This is a routing and closure protocol. It does not grant permissions, invent unavailable tools, guarantee a model result, or turn a plan, surface label, subagent request or model preference into a capability that the current environment does not expose. A task is complete only after a verified delta, an explicit acceptance state and a truthful claim ceiling. ## 2. Execution Profile Setup ### 2.1 Why setup exists V4.0 routed budget qualitatively but still assumed too much about the user's starting resource posture. V4.1 made that posture explicit and configurable; V4.2 hardened first use, surface availability and handoff transport. V4.3 generalizes bounded capability escalation into a tier-neutral distillation loop. A subscription plan or workspace entitlement is only one input. It does not by itself determine the correct model, effort, fanout or budget policy. Two users on the same plan can rationally choose different routes; the same user can choose differently near a reset, after buying credits, under deadline pressure or for a quality-critical task. The protocol therefore separates three things: 1. **Execution Profile** — relatively stable user preferences and available surfaces; 2. **Run State** — volatile allowance, availability, urgency and environment facts now; 3. **Task Requirements** — sovereign object, minimum capability, risk and verification burden. The effective route is derived from all three. It is not copied from a plan label. ### 2.2 Setup modes The protocol supports three setup modes: - **AUTO** — infer conservative defaults from observable availability and explicit user preferences; ask only when an unknown materially changes the route; - **PROFILE** — use a reusable named Execution Profile; - **RUN_OVERRIDE** — temporarily override one or more profile fields for the current run without mutating the reusable profile. Do not turn setup into questionnaire debt. Unknown fields may remain `unknown` until they matter. Sprint Mode is not a fourth setup mode. It is a conditional run-level overlay that may be attached to AUTO, PROFILE or RUN_OVERRIDE only after the user explicitly activates it or confirms a recommendation. It must never be inferred from a deadline, a plan label, an allowance signal or an executor's preference. ### 2.2.1 First-use defaults and AUTO disclosure A first use should be low-friction and conservative. The router may begin with this logical default without claiming that any field is stored or that an unknown surface is available: ```yaml execution_profile: profile_id: default persistence: ephemeral entitlement_hint: unknown surfaces: chat: state: available enabled: true work: state: unknown enabled: auto codex: state: unknown enabled: false accessible_tiers: unknown resource_posture: adaptive optimization_priority: balanced burn_tolerance: medium reasoning_policy: preferred: adaptive ceiling: adaptive frontier_policy: gated native_parallelism: bounded checkpoint_policy: proportional ``` AUTO is low-friction, not invisible. For non-trivial work, disclose the minimum routing state that materially shaped the decision: ```text Setup: AUTO Observed: Chat available; Work unknown; Codex disabled Resource posture: adaptive Optimization: balanced Unknowns affecting route: allowance state ``` The disclosure is a run-level observation, not a promise that the inferred settings persist. A one-run override may request Codex without changing a reusable profile: ```yaml run_override: surfaces: codex: enabled: true ``` Enabling does not prove availability; the router still probes the surface before routing work to it. ### 2.3 Portable profile schema A reusable profile can be represented as: ```yaml execution_profile: profile_id: balanced-default persistence: persistence_unknown entitlement_hint: unknown surfaces: chat: state: unknown enabled: auto work: state: unknown enabled: auto codex: state: unknown enabled: false accessible_tiers: unknown resource_posture: adaptive optimization_priority: balanced burn_tolerance: medium model_preferences: chat: adaptive work: adaptive codex: adaptive reasoning_policy: preferred: adaptive ceiling: adaptive frontier_policy: gated native_parallelism: bounded checkpoint_policy: proportional fallback_policy: - compress_context - reduce_tool_or_fanout - lower_effort_when_safe - downroute_tier_when_safe - phase_execution - reroute_surface - request_allowance_or_decision ``` Stable values are qualitative by design. For surfaces, `state` means observed availability and uses `available | unavailable | unknown`. `enabled` means activation intent and uses `true | false | auto`. Enabling a surface does not prove that it is available; availability does not imply consent to use it. The stable tier taxonomy is separate from the tiers actually accessible in the current environment. Until probed, `accessible_tiers` remains `unknown` or `auto`, never a list inferred from a plan label. ### Profile Persistence Law A named Execution Profile is reusable only if it is actually stored in a persistent location available to the current environment, such as user instructions, a project source, a repository instruction file, a connected document, a native setting or explicitly re-supplied configuration. A profile named inside one prompt is `ephemeral_profile` unless persistence is evidenced. Use `persistent_profile` only when storage is verified; use `persistence_unknown` when the storage boundary cannot be established. The profile field may use `ephemeral | persistent | unknown`; the claim labels are `ephemeral_profile | persistent_profile | persistence_unknown`. Never claim that a profile was saved without evidence. Recommended vocabularies: - `resource_posture`: `conserve | balanced | ample | adaptive` - `optimization_priority`: `throughput_per_allowance | quality | latency | balanced` - `burn_tolerance`: `low | medium | high` - `frontier_policy`: `disabled | burst_only | gated | permissive` - `native_parallelism`: `logical_only | bounded | permissive` - `checkpoint_policy`: `proportional | aggressive` Product-specific plan or model names belong in `entitlement_hint`, optional aliases and the dated calibration section. They do not replace the stable qualitative fields. ### 2.4 Run State Before material execution, resolve only the volatile fields that can change the route: ```yaml run_state: allowance_state: unknown reset_horizon: unknown additional_credits: unknown surfaces_observed: unknown models_observed: unknown urgency: normal sprint_active: false sprint_reason: null interruption_risk: unknown resource_pools: agentic: state: unknown members: unknown ``` `allowance_state` uses `unknown | tight | adequate | abundant`. Resource-pool state uses `unknown | independent | shared`; `members` may remain `unknown` until observed. If surfaces share a pool, record the observed members rather than inventing separate batteries. > **Surface change does not imply budget reset.** A `REROUTE_SURFACE` outcome changes the executor, not the allowance source. Shared Work/Codex usage belongs in dated product calibration; the shared-pool concept is stable protocol law. Do not invent precise token forecasts or convert a UI percentage into a universal cost law. If exact usage data is visible, it may be recorded as evidence for that run without promoting it into protocol doctrine. ### 2.5 Task Requirements Every route also records: ```yaml task_requirements: sovereign_object: null observable_delta: null capability_floor: efficient behavioral_fit: adaptive behavior_contract: null commitment_geometry: adaptive verification_burden: normal consequence_level: normal continuity_need: normal ``` The `capability_floor` is the lowest capability tier that can responsibly attempt the irreducible task after specification, source, context and tool failures have been repaired. `behavioral_fit` records whether observable model behavior is material to acceptance. Use `adaptive` unless the task clearly requires stricter properties such as source-bound transformation, style/voice fidelity, tool-use restraint, bounded initiative, persona/role consistency or a particular verification appetite. When those properties matter, encode the smallest explicit `behavior_contract` that can be tested from the output or tool trace. `commitment_geometry` records whether a pending solution-defining choice needs a separate closure route before dependent work scales. It is `adaptive` by default; trivial or tightly constrained tasks need no additional commitment object or Route Card field. When the gate materially changes the plan, record only the bounded state and dimensions that affected it: ```yaml commitment: state: unresolved | resolved | reopened | not_material route: COMMIT_DIRECTLY | PROBE_THEN_COMMIT | EXPLORE_THEN_SELECT | SIDE_ROUTE_COMMITMENT | UPROUTE_COMMITMENT | REOPEN_COMMITMENT downstream_leverage: low | medium | high | unknown reversibility: easy | moderate | costly | unknown solution_openness: narrow | plural | unknown ``` Omit this object when commitment geometry does not materially change the route. A trivial or tightly constrained task implicitly takes `COMMIT_DIRECTLY` without opening a commitment questionnaire or showing the route on its card. `route` names the next action, not an exclusive strategy for the whole cycle; distinct outcomes may compose in sequence. A Route Card shows the commitment route only when it materially changed the plan. ### 2.6 Profile Precedence Law When instructions conflict, use this order: 1. safety, authorization, evidence and claim ceilings; 2. task capability floor and sovereign-object requirements; 3. explicit one-run override; 4. active Execution Profile; 5. protocol defaults. A profile tunes routing. It cannot waive evidence, permissions, safety, verification or the minimum capability required by the task. > **Preference is not permission to fail.** If a conserve profile cannot afford the capability floor, decompose the task, use a narrow stronger burst, wait for resources, request a decision, or return a blocked resource condition. Do not knowingly underfit the task and call that optimization. ### 2.7 Resource Posture Resolver The effective resource posture is resolved from the reusable profile plus live Run State. Entitlement is evidence about possible access, not destiny. Examples: - a limited entitlement with abundant temporary credits may resolve upward for one run; - an ample entitlement with `optimization_priority: throughput_per_allowance` may still resolve conservatively; - a tight allowance near a reset may prefer phasing or deferral; - a quality-first profile may prefer a stronger model while still using Context Diet and bounded fanout. The resolver maximizes useful outcome subject to capability floor, behavioral acceptance fit, resource ceiling, surface availability, evidence burden and user preference. It does not require a fake numeric utility score. ### 2.8 Example profiles These are examples, not normative plan mappings. **Conserve** ```yaml resource_posture: conserve optimization_priority: throughput_per_allowance burn_tolerance: low frontier_policy: burst_only native_parallelism: logical_only checkpoint_policy: aggressive ``` **Balanced** ```yaml resource_posture: balanced optimization_priority: balanced burn_tolerance: medium frontier_policy: gated native_parallelism: bounded checkpoint_policy: proportional ``` **Quality First** ```yaml resource_posture: ample optimization_priority: quality burn_tolerance: high frontier_policy: gated native_parallelism: bounded checkpoint_policy: proportional ``` **Frontier Burst** ```yaml resource_posture: adaptive optimization_priority: quality frontier_policy: burst_only native_parallelism: logical_only checkpoint_policy: aggressive ``` A named profile should describe strategy, not pretend to describe every subscriber on a commercial plan. ## 3. Surface roles and control roots Chat, Work and Codex are specialized product surfaces, not ranks in a prestige ladder and not fixed cognitive roles. Any surface may be a **control surface** only to the extent that the current runtime actually lets it retain the objective, authority, route state, convergence state and postflight responsibility. Codex remains optional and its presence in the model does not establish installation, availability, enablement or user consent. ### Control Root Law The **control root** is the active owner of objective, authority, decomposition, routing, convergence and closure for the current run. The control root is a functional role, not a product name. The current competent root is the continuity default. Do not move the user to another surface merely because another surface is traditionally associated with a phase of work. A surface transition must earn itself through a material capability gain such as required tooling, execution persistence, repository/runtime access, document/computer environment, permission boundary, verification affordance or context-locality advantage. > **Stay where you are when the current root can complete and verify the objective; move only for a real execution reason.** ### Chat Chat is a first-class control surface for conversational continuity, clarification, comparison, architecture, review, bounded direct action and human-facing acceptance. It is especially useful when the user prefers to keep long-lived conversational context in Chat, but the protocol does not assume that preference for every user. ### Work Work is a sustained execution surface for research, knowledge artifacts, office-style deliverables, browser/computer interaction and multi-step connector workflows where those capabilities are exposed. Work may also remain the control root for an entire run rather than serving only as an executor called from Chat. ### Codex Codex is an execution and control surface for repositories, code, tests, builds, terminals, runtime behavior, refactors, migrations and debugging when it is actually available and enabled. Codex may retain root responsibility through subagent execution and final convergence when the task is natively repository-shaped. ### Bounded Direct Action Law A current control root may directly execute a delta when the operation is atomic or tightly bounded, already authorized, supported by an actually available tool, independently verifiable, low in coordination burden, and not materially improved by a transition to another surface. The law changes the executor, not the evidence standard. Examples include changing one README sentence, sending one authorized email, modifying one calendar event, updating one spreadsheet cell, rewriting one paragraph or performing one bounded connector action. ### Codex Optionality Law Codex is an optional execution capability, not a protocol prerequisite. Route to Codex only when it is observed as available, permitted by the active profile or a one-run override, and materially beneficial for the sovereign object. If Codex is unavailable or disabled, do not treat that as protocol failure: choose the best real fallback, preserve the claim ceiling and distinguish an unavailable ideal harness from an impossible task. AUTO must not silently assume Codex. ### Named Chat–Work Loop Profile The historical **Chat → Work/Codex → Chat** loop remains a first-class named profile: **Chat–Work Loop Profile = Chat continuity/control → Work and/or Codex execution when materially useful → Chat convergence/postflight.** Use it when Chat is the user's preferred continuity surface, when conversational context should remain the primary human-facing state, or when the user explicitly asks for that loop. It is no longer the protocol's mandatory default topology. Other valid topologies include: - Work root → delegated workers/specialists → Work convergence; - Codex root → subagents → Codex convergence; - frontier root → cheaper workers + stronger specialists → same-root convergence; - another compatible orchestrator → execution workers → designated convergence root. The protocol routes by function and observed capability, not by ritual surface order. ## 4. Route by object geometry and workload shape **Sovereign object = the state that must actually change for the task to count as done.** Object labels are routing clues, not the completion criterion. Object geometry determines what execution affordances are needed; it does not automatically dictate which product surface must become the control root. Examples: - “Explain this code” → understanding → remain on the current competent control surface. - “Change this repo and pass tests” → repository/runtime state → use Codex when available and materially beneficial; Codex may become or remain the root. - “Produce a researched report” → artifact → use Work when its sustained execution affordances are materially useful; Work may remain the root. - “Send one email” → external message state → current root may execute directly when the action is available, authorized and verifiable. | Task geometry | Preferred routing tendency | |---|---| | Meaning, judgment, architecture, comparison, clarification or review | Preserve the current competent control root; Chat is a first-class option, not a mandatory destination | | Atomic text/document transformation or connector action | Current competent root under the Bounded Direct Action Law | | Sustained knowledge-artifact production, multi-source research, office/document execution or coordination-heavy browser/connector workflow | Work when its harness materially improves completion or verification | | Repository, code, test, build, terminal, runtime, executable system or code migration | Codex when available, enabled and materially beneficial | | Acceptance, claim ceiling, residual classification and final integration | Designated convergence/control root, with human decision where human authority is required | When several objects are present, decompose the task into explicit stages and name each owner. When object type and workload shape point to different execution surfaces, preserve the current root if it can coordinate the required harnesses; otherwise choose the smallest available transition that can complete and verify the delta without losing material continuity, control, feedback or evidence. ## 5. Routing dimensions The protocol records twelve routing dimensions plus an optional Sprint overlay: 1. **Execution Profile** — reusable resource and optimization preferences; 2. **Object geometry** — sovereign object and observable delta; 3. **Control surface/root** — where objective, authority, routing state, convergence and closure live; 4. **Execution surface/harness** — where a particular operation actually runs; 5. **Root capability tier and model** — `efficient | balanced | strong | frontier`; 6. **Behavioral fit** — whether the executor's observable behavior matches the task's acceptance boundary; 7. **Commitment geometry** — whether, when and by whom a solution-defining choice should be closed before dependent work scales; 8. **Reasoning effort** — independent from model capability; 9. **Continuity and locality** — persistence, local state and handoff requirements; 10. **Delegation topology** — `single_owner | cheap_worker_fanout | mixed_tier | frontier_orchestrator`; 11. **Execution envelope** — allowance, tools, permissions, fanout, tests, checkpoints, reversibility and fallback; 12. **Operation mode** — whether the run executes, only routes or audits a previous route. > **Control surface ≠ root model ≠ execution surface.** A Work surface may host a Sol root that delegates Luna workers. A Codex surface may host a root plus subagents and close there. Chat may remain the continuity root while Work or Codex executes a bounded phase. These are different routing dimensions and must not be collapsed. ### Harness Specialization Law Capability overlap does not imply harness equivalence. Prefer the surface whose persistence, controls, feedback and verification fit the sovereign object. ### Behavioral Fit Gate Capability sufficiency is necessary, not sufficient. A model can clear the cognitive capability floor and still be a poor executor for a task because its observable behavior conflicts with the acceptance boundary. Behavioral fit can include: - style and voice fidelity; - source-bound transformation fidelity; - restraint around unsolicited browsing, fact-checking or tool use when governing rules do not require it; - initiative/autonomy level; - persona or role consistency; - verification appetite and tendency to over-expand scope; - obedience to approval, mutation and surface boundaries. When behavior is load-bearing: 1. define the smallest observable behavior contract; 2. if a model or model release is new, materially changed or uncertain for that workload, prefer a bounded representative micro-probe over a full sacrificial run when feasible; 3. if the probe or live run misses the contract, first tighten the contract when the mismatch is instruction-remediable; 4. if mismatch persists while cognition remains sufficient, use `SIDE_ROUTE_MODEL_FOR_FIT` to another available model/effort/surface with better observed fit; 5. use capability escalation only when the remaining failure is actually cognitive or when the higher tier is independently justified. Community anecdotes, launch-day reactions and single-run impressions may generate hypotheses for the probe. They do not become permanent model rankings or universal behavioral facts. > **Side-route before up-route when the failure is behavioral rather than cognitive.** ### Decision Commitment Gate Capability and behavioral fit do not by themselves determine whether a solution-defining choice should be closed now, by this executor, before substantial dependent work proceeds. The **Decision Commitment Gate** evaluates that choice separately from bulk execution. Use the gate when the choice could materially constrain the solution space or determine substantial downstream work. Consider, qualitatively: - **reversibility** — the cost of undoing the choice; - **downstream leverage** — how much later work depends on it; - **solution openness** — whether several materially different directions remain plausible; - **evaluation latency** — how late weakness would become visible; - **judgment load** — whether success depends on architecture, taste, synthesis, strategy or holistic integration; - **external consequence** — whether the result is public, high-stakes, reputation-bearing or expensive to repair. Unknowns may remain adaptive until they matter. Do not score these factors numerically, turn trivial tasks into questionnaires or infer that consequence alone requires branching or frontier routing. `COMMIT_DIRECTLY` is appropriate when the joint geometry is sufficiently constrained, reversible or low-leverage; easy reversibility alone does not cancel substantial dependent work. Commitment routes: - `COMMIT_DIRECTLY` — close the choice without more exploration or routing when the combined factors make those costs unlikely to reduce total work; low consequence or easy reversal alone is not decisive; - `PROBE_THEN_COMMIT` — test one representative direction when a cheap probe can validate it before scale; - `EXPLORE_THEN_SELECT` — compare a bounded set of materially distinct directions when the cost of exploration is lower than likely replay; - `SIDE_ROUTE_COMMITMENT` — keep the current executor as root or implementer, while an available executor with better observed fit closes only this choice; - `UPROUTE_COMMITMENT` — route only this choice to stronger cognition when it exceeds the current executor's capability floor; - `REOPEN_COMMITMENT` — return to the smallest affected choice boundary after later evidence shows that the commitment is inadequate. These outcomes may compose over one route, such as side-routing a bounded exploration and then probing the selected direction. Record the next action rather than pretending the outcomes are mutually exclusive. A side-route is not automatically a capability escalation, and an up-route never expands execution authority. ### Branch Before Build When several legitimate solution directions remain open, downstream leverage is high and bounded alternatives cost less than full replay, use **Branch Before Build**: 1. produce a small number of structurally distinct representative probes; 2. keep each probe bounded; 3. compare them against the actual acceptance boundary; 4. select or synthesize a direction; 5. scale material execution only after that commitment is sufficiently resolved. Two or three probes are a practical example, not a quota. Do not branch where the solution is already constrained enough that exploration costs more than likely correction. A probe may be preparation authorized by the current mandate; it does not silently authorize broader mutation. The route minimizes total work to acceptance, which may include exploration, execution, verification, correction, replay and convergence overhead. **The cheapest first execution is not the cheapest route when it predictably increases correction or replay.** Commitment Geometry is distinct from Behavioral Fit: Behavioral Fit asks whether an executor's observable behavior suits the task; this gate asks whether a solution-defining choice should be closed, when, and by which suitably authorized executor. A result may be capable, behaviorally suitable, competently executed and technically passing while its upstream commitment is still wrong. ### Surface Continuity Law AUTO preserves the **current competent control root** unless a surface transition creates a material completion or verification advantage. Before asking the user to move between Chat, Work, Codex or another compatible surface, AUTO should attempt, in order when available: 1. direct completion on the current root; 2. internal tool/harness use from the current root; 3. internal delegation or child-model routing; 4. bounded cross-surface execution with the current root retained as convergence owner; 5. only then, a human-visible control-root transition. A transition is not progress by itself. The burden is on the route to justify the move. ### Delegation-First Law When the active harness exposes real subagents or equivalent delegated workers, AUTO should resolve model heterogeneity inside the current execution before asking the user for a manual model or surface switch. The preferred topology is asymmetric: - the **root/orchestrator** owns the objective, authority, decomposition, dependencies, convergence and final judgment; - **cheap sufficient workers** receive narrow, independent, verifiable units with the minimum context they need; - **strong specialists** receive only branches whose ambiguity or reasoning burden exceeds the cheap worker; - a **frontier root**, when justified, should spend frontier cognition on architecture, arbitration, exceptions and final QA rather than repetitive scanning or routine tool loops. The default questions become: > **Can the current root assemble a sufficient internal team without taking the user out of flow?** > **Can the current root also remain the convergence owner, avoiding an unnecessary surface transition?** Manual switching is a fallback, not the routing primitive. ### Logical plurality is not physical fanout Multiple expert perspectives can still be produced within one bounded execution. Physical subagents are valuable when they isolate noisy intermediate work, reduce context pollution, save elapsed time on independent units or let cheaper models absorb high-volume work. They are not automatically valuable when the task is small, tightly coupled, sequential or write-conflicted. ### Operation modes Record one stable operation mode in the Route Card and Execution Handoff: - `ROUTE_AND_EXECUTE` — default when tools or surfaces exist, authority exists and no user decision is required; - `ROUTE_ONLY` — use when the user asks only for routing or handoff, the executor is unavailable or execution authority is absent; - `AUDIT_ROUTE` — use when reviewing a previous route, handoff, model/surface decision or Control-Root Postflight route audit. Sprint Mode does not add an operation mode. It overlays one of these modes for the current run and must be disclosed separately as `Sprint: ON` with its activation, objective, budget character and stop condition. ### Route Card For non-trivial tasks, manifest routing in a compact form: ```text Route Card Control root: Work Execution: Work Why: current Work root can sustain the report and close it without a surface transition Mode: ROUTE_AND_EXECUTE Root model/tier: strong Behavior fit: PASS_FIT Effort: medium Delegation: cheap_worker_fanout → efficient/high for independent scans Budget: PASS_PHASED Manual switch: not required Next boundary: executor receipt → Control-Root Postflight ``` The card must state the control root, execution surface when distinct, why the topology fits, operation mode, root capability/effort, behavioral-fit outcome when material, delegation topology when material, Budget Survivability outcome, any material unavailable or disabled surface and the next boundary. Tiny tasks may suppress the card, but not the underlying route decision or evidence standard. When the named Chat–Work Loop Profile is active, the card may instead show `Control root: Chat`, a Work or Codex execution surface, and `Return root: Chat`. When Sprint Mode is active, the Route Card also states the finite docket or bounded envelope, whether capacity is perishable or otherwise bounded, the lower-tier re-entry owner and the fact that the overlay exits at the stated stop boundary or Control-Root Postflight. ## 6. Availability and Capability Floor Before model escalation, verify actual surface, model, connector, repository, document and permission availability. Then resolve the task capability floor. Fix non-cognitive failures first: - incoherent specification; - wrong or stale authority; - unavailable surface or permission; - context starvation or clash; - workflow/fanout failure; - budget/resource failure; - behavioral-fit mismatch that can be repaired by a tighter behavior contract or lateral route. A stronger model is not a substitute for a missing source, tool, permission or acceptance rule. Nor is higher benchmark capability proof of better style, source fidelity, tool restraint or role behavior for a particular workload. If the task is cognitively within floor but behaviorally mismatched, apply the Behavioral Fit Gate before capability escalation. A missing or disabled Codex surface is a routing condition, not a user failure; use the best real fallback or report a truthful blocked condition when the requested verification cannot be performed elsewhere. ## 7. Budget Survivability Gate Run this gate before sustained expensive execution, high effort, frontier work or physical fanout. Inputs include: - active Execution Profile; - live `allowance_state` and resource posture; - capability floor and chosen tier; - reasoning effort; - context/input and expected output burden; - tools, tests and verification; - fanout and reconciliation cost; - interruption risk and checkpoint quality; - likely retries and fallback; - material gain expected from the route. Outcomes: - **PASS_DIRECT** - **PASS_PHASED** - **PASS_FRONTIER_BURST** - **DOWNROUTE_MODEL_OR_EFFORT** — only when the capability floor still passes - **COMPRESS_CONTEXT_FIRST** - **REDUCE_TOOL_OR_FANOUT** - **WAIT_OR_REQUIRE_ADDITIONAL_ALLOWANCE** - **REROUTE_SURFACE** - **BLOCKED_RESOURCE_CONDITION** The gate is qualitative. Reassess when the live resource posture materially changes. ### Observable burden signals Low burden usually means a bounded task, small authoritative context, no physical fanout, short output, one verification pass and a reversible mutation. Elevated burden usually means many sources or files, large context, long expected output, multiple tools, repeated tests, physical agents, frontier tier, max/xhigh reasoning, an uncertain environment or a likely retry loop. Guidance remains qualitative: - mostly low signals → `PASS_DIRECT`; - multiple elevated signals → prefer `PASS_PHASED`; - frontier plus elevated burden under constrained resources → `PASS_FRONTIER_BURST` or downroute/phase; - tight or unknown resource state with high interruption risk → checkpoint before sustained work. The Route Card should expose the selected outcome and the shortest reason it survived this gate. ### Budget Adaptation Law A resource-constrained profile should first remove waste, not intelligence that is loadbearing. Prefer, in order when safe: 1. smaller authoritative context; 2. fewer redundant tools and physical agents; 3. stronger checkpointing and phasing; 4. lower effort for routine phases; 5. lower tier for phases below the task's capability floor; 6. narrow high-capability bursts for the irreducible hard slice. The final item is governed by the Intelligence Distillation Ladder below. It is not a frontier-only instruction and does not authorize sending the whole task to a stronger tier. ### Sprint Mode law Sprint Mode is an optional, explicitly activated, ephemeral run-level resource and pacing overlay. It is not a new operation mode, model, capability tier, entitlement, persistent profile or native product feature. It may be attached to AUTO, PROFILE or RUN_OVERRIDE only when: 1. the user directly activates it (`explicit_user`); or 2. the router recommends it and the user confirms it (`recommended_then_user_confirmed`). The router must not silently activate Sprint Mode because a task is urgent, a plan has a particular label, capacity appears available or a model prefers a broader run. A recommendation is not activation. If confirmation is absent, Sprint remains off. An active Sprint requires a single sovereign objective, a finite docket or bounded execution envelope, a named stop condition and a return receipt. It exits when the objective or stop condition is reached, the resource or authority boundary blocks continuation, the user disables it or Control-Root Postflight begins. It does not persist into a later run unless separately activated again. ```yaml sprint_envelope: active: false activation: none | explicit_user | recommended_then_user_confirmed sprint_kind: decision | bounded_execution | other objective: null horizon: unknown budget_character: unknown | bounded_allocated | perishable docket: finite: true items: [] optimization_target: verified_useful_delta_before_horizon stop_condition: null exit_policy: ephemeral_run_only ``` When capacity is explicitly known to be perishable, or its future value is otherwise shown to fall after a stated horizon, unused capacity can have lower future value. The router may then prioritize verified useful delta before that horizon inside the authorized envelope. This qualitative law does not authorize invented prices, reset times, allowance visibility or economic constants. > **Spend is not the objective. Verified useful delta is the objective.** Budget Survivability still governs Sprint Mode. Perishable capacity can justify a bounded `PASS_FRONTIER_BURST` or another higher-capability slice only when the named delta, capability floor, verification and stop condition survive the gate. It never justifies waste, open-ended scope, automatic escalation or physical fanout by itself. ## 8. Context Diet Load the smallest set that establishes authority, objective, baseline, constraints, evidence and acceptance. Failure modes: - **starvation** — required source absent; - **distraction** — low-value material consumes attention and allowance; - **clashing** — competing instructions unresolved; - **fossilization** — stale facts still govern; - **duplication** — repeated copies create cost without evidence. Progressively retrieve only what a named uncertainty requires. Compression must preserve authority, decisions, constraints, failure state, evidence and next action. For IDL escalation, the context capsule should be decision-relevant rather than merely short: preserve load-bearing authority, hard constraints, verified evidence and material uncertainty, while excluding recoverable history and settled implementation bulk. ## 9. Surface gates ### Current-root gate First ask whether the current surface can remain a competent control root through completion and verification. If yes, preserve continuity unless another surface provides a material execution advantage. ### Chat gate Use Chat as a control or execution surface when conversational continuity, clarification, review, bounded correction, atomic connector actions or human-facing acceptance are load-bearing. Chat is not required merely because the task contains judgment. ### Work gate Use Work when long research, multi-file knowledge production, browser/computer interaction, connector-mediated document work, structured office artifacts or sustained artifact execution materially benefit from its harness. Work may remain the control root through convergence and postflight. ### Codex gate Use Codex for repository mutation, code, tests, builds, terminals, runtime diagnosis, refactors and migrations only when it is actually available and enabled. Inspect applicable `AGENTS.md` or equivalent repository instructions before mutation. Codex may remain the control root when the objective is natively repository-shaped. ### Surface Transition Gate A human-visible surface transition is justified only when at least one of these is material: - required tooling or environment is unavailable from the current root; - persistence/local state is load-bearing and better preserved elsewhere; - permission or mutation scope exists only on another surface; - verification quality materially improves on another harness; - the current root is below the capability floor and cannot internally delegate to a sufficient target; - the user explicitly prefers another surface. When none applies, stay on the current competent root. ### Surface Availability Probe Choose from surfaces whose `state` is observed as `available` and whose `enabled` value permits use. `auto` may trigger a bounded probe; it must not silently turn an unknown surface into an assumed capability. If the ideal harness is missing, disabled or declined, name the fallback and preserve the claim ceiling. A surface transition never proves a budget reset. ## 10. Capability economics and dated calibration Stable tiers are qualitative: `accessible_tiers` is an observed Run State field, not a plan-derived entitlement list. The stable taxonomy below can remain known while current access remains `unknown` until a probe or explicit evidence establishes availability. - **efficient:** clear, bounded, repeatable work; - **balanced:** ordinary multi-step work with moderate ambiguity; - **strong:** difficult synthesis, architecture, debugging or high-consequence judgment; - **frontier:** work whose material value depends on the strongest available reasoning and whose resource posture can sustain it. A semantic capability tier does not require a dedicated named model. A product family may expose no model literally named `balanced`, and one named model may span more than one semantic tier as reasoning effort and task geometry change. Map the observed model + effort combination to the task's capability floor; never invent a missing product tier or force a ceremonial model staircase. The core intentionally does not encode a current model-to-surface mapping, plan behavior, allowance/reset fact, price, UI detail, tool exposure or model-specific ergonomic preference. Those are volatile Run State or subordinate adapter inputs, not stable routing law. Recheck the relevant official product documentation when such facts materially affect a route. ### Model Strategy Adapter Boundary Adaptive Orchestration remains model-neutral. A named frontier model may have a subordinate strategy adapter that organizes model-specific role, autonomy, context/corpus geometry, coverage topology, direction-constraint density, mutation authority, return geometry, surface ergonomics and dated calibration. The adapter is optional guidance, not a second semantic authority, and it may be used only when the model and required surface are actually available. The adapter must be compiled from task geometry and observed capability rather than model prestige or stereotype. It may propose a strategy, but it cannot override user authority, source authority, safety, privacy, capability floor, scope ceiling, mutation permission, evidence, verification, claim ceiling, Delegation & Native Parallelism Gate or Control-Root Postflight. On conflict, this canonical body wins. Preserve these separations explicitly: > **Model capability does not determine autonomy geometry.** > **Reasoning depth is not execution autonomy.** > **Context breadth is not mutation authority.** > **Frontier capability is not a frontier full run.** > **High autonomy is not unbounded scope.** > **Sprint is not an Astra mode.** > **Decision Trace is not Astra-only.** > **An IDL brain burst is one strategy, not a model's identity.** Decision Capsules and Return Capsules remain generic strategy instruments, not mandatory wrappers for every frontier invocation. Sprint remains a generic run-level overlay, Decision Trace remains model-neutral and physical fanout still obeys the Delegation & Native Parallelism Gate. Direction-constraint density governs method freedom inside an authorized task; it never expands the objective or authority envelope. The current optional Astra strategy adapter is documented at [portables/adaptive-orchestration/adapters/ADAPTIVE_ORCHESTRATION_ASTRA_ADAPTER.md](../../portables/adaptive-orchestration/adapters/ADAPTIVE_ORCHESTRATION_ASTRA_ADAPTER.md). Its volatile notes are dated and replaceable; they cannot turn a temporary product observation into a permanent core rule. The current GPT-6 Sol/Luna execution calibration is documented at [portables/adaptive-orchestration/adapters/ADAPTIVE_ORCHESTRATION_GPT6_SOL_LUNA_ADAPTER.md](../../portables/adaptive-orchestration/adapters/ADAPTIVE_ORCHESTRATION_GPT6_SOL_LUNA_ADAPTER.md). It calibrates Sol/Luna across Chat and Work/Codex according to observed plan, model-variant and harness availability; Chat GPT-6 Sol/Luna (October conversation-tuned models) must not be conflated with the September Work/Codex executor versions or assumed to expose their delegation/tool controls. API pricing/context facts remain separate from ChatGPT allowance economics. A subordinate model adapter may require its own setup gate. Adaptive Orchestration's existing Execution Profile, Run State and Profile Persistence laws remain governing: the router may recommend or prefill model-specific preferences, but it must not silently instantiate a user's role, autonomy, reasoning, context, parallelism or return preferences. An explicit adaptive/AUTO choice is a setup choice, not permission to assume a reference preset. **Calibration disclaimer:** distillation pressure is not permanent doctrine. If a frontier tier becomes materially cheaper or more efficient per verified useful delta, a later dated adapter or protocol revision may loosen compression or coverage ceilings while preserving explicit stop conditions, scope authorization and capability-floor discipline. ## 11. Reasoning Effort Law Reasoning effort follows irreducible reasoning density, not emotional importance or model prestige. The profile may express a preferred effort and ceiling, but the task still determines the minimum useful effort. High, xhigh or max-like settings are explicit choices when exposed by the current product; their availability is not assumed across every model or surface. A low-budget profile may rationally prefer an efficient model at high effort when observed quality-per-allowance is good for that user's workload. That is a configurable preference, not a universal law. ### Intelligence Distillation Ladder (IDL) The **Intelligence Distillation Ladder** generalizes bounded capability escalation across the qualitative tiers `efficient | balanced | strong | frontier`. It is an operational routing heuristic, not a benchmark, model ranking, product policy or promise of savings or quality. The IDL gives operational form to the mother law above: > **Escalate only the irreducible execution, judgment or commitment delta; return only the decision-bearing delta.** Do bulk work on the cheapest sufficient tier. When a named unresolved question survives specification repair, evidence gathering, tool checks and an appropriate reasoning-effort adjustment, isolate that question, purchase only the capability needed to resolve it, then return to the lowest sufficient tier for implementation and verification. #### Irreducible Delta An **irreducible delta** is the smallest unresolved question whose answer could materially change the route, architecture, judgment or correctness of the task after non-cognitive failures have been excluded. Name which routing dimension is irreducible before choosing what to escalate: - **Execution delta** — the material work to be performed; - **Judgment delta** — difficult reasoning needed during execution; - **Commitment delta** — a solution-defining choice that constrains what substantial downstream execution will follow. These dimensions can overlap. A commitment may require judgment, but it is not a second distillation ladder or a separate capability tier. A cheaper sufficient executor may remain root and own most work while a stronger or differently fitted executor resolves only the commitment-bearing delta. If that choice is still open and costly to replay, run the Decision Commitment Gate before scaling dependent execution. ```yaml irreducible_delta: delta_id: null unresolved_question: null blocked_by: one_of: - reasoning_effort - capability - evidence - tool - authority - workflow - unknown current_tier: null current_effort: null evidence_of_insufficiency: null consequence_if_wrong: null verification_after_ruling: null ``` Use these distinctions: - missing source, permission, tool, authority or factual evidence is not automatically a capability problem; - ambiguity caused by a bad specification should be repaired before escalation; - an important task is not automatically a high-tier task; - a large task is not automatically a frontier task; - escalation is justified by the unresolved reasoning density of a named delta, not by the emotional importance of the request. #### Effort versus Capability Before changing capability tier, ask: 1. Is the current tier below the capability floor for this delta? 2. Is the failure instead insufficient reasoning effort within a tier that should be capable? 3. Is the failure non-cognitive and therefore not repairable by a stronger model? 4. Would one bounded higher-tier ruling unblock lower-tier execution? When the current tier remains plausibly sufficient, increasing reasoning effort may be more coherent than changing models. When the delta genuinely exceeds the current tier, escalate the delta rather than the whole task. The protocol remains qualitative; it does not prescribe universal numeric thresholds. #### Decision Capsule A **Decision Capsule** is smaller than an Execution Handoff. It carries only what the target tier needs to make one bounded ruling while preserving authority, hard constraints, verified truth, material uncertainty and enough provenance to avoid reconstruction by guesswork. When the target delta is a material commitment, populate `commitment_boundary`, `acceptance_criteria` and `dependent_work_at_risk` with only the decision boundary, decisive criteria and downstream work that could be affected. Keep the ruling inside the existing mandate; an unresolved choice does not grant permission to implement it. ```yaml decision_capsule: delta_id: null decision_objective: null unresolved_question: null verified_facts: [] hard_constraints: [] live_uncertainties: [] candidate_paths: [] commitment_boundary: null commitment_route: null acceptance_criteria: [] dependent_work_at_risk: [] current_route: surface: null capability_tier: null reasoning_effort: null why_current_route_is_insufficient: null requested_capability: null requested_return: - ruling - decisive_reason - uncertainty_or_failure_condition - next_action - decision_trace_when_material output_boundary: bounded default_mode: read_only_judgment ``` Do not carry the full conversation or repository merely because it is available. Exclude duplicated history, settled implementation bulk, raw tool logs, already-closed questions and speculative context without a named role. Compression is invalid if it removes load-bearing authority, constraints, evidence, uncertainty or provenance. #### Bounded Exhaustiveness Guard Open-ended completeness language can amplify scope even when the selected model is cognitively sufficient. Before expensive sustained execution or a frontier burst, compile phrases such as `all edge cases`, `exhaustive`, `fully comprehensive`, `cover everything` or equivalent wording into an explicit coverage contract. ```yaml bounded_exhaustiveness: coverage_mode: representative_risk_weighted | exhaustive_bounded coverage_ceiling: named_domains: [] max_new_case_classes: null test_budget_or_growth_rule: null stop_condition: null scope_expansion: explicit_authorization_required discovered_out_of_scope: defer_and_report ``` The default is `representative_risk_weighted`: cover the highest-risk and decision-relevant classes first, then stop when the named acceptance boundary is satisfied. Use `exhaustive_bounded` only when exhaustiveness is genuinely required and the bounded domain is explicit. "Be balanced" may be useful conversational guidance, but it is not a computable execution boundary and must not substitute for these fields when runaway completeness would be costly. Enumeration is not execution. A model may map a wider edge-case landscape without gaining authority to investigate, implement or test every discovered branch. Newly discovered classes outside the active ceiling go to `deferred_candidates` unless scope expansion is explicitly authorized. If the run materially expands investigation, testing or implementation beyond the decision-bearing delta without an explicit ceiling or authorization, classify the incident as `scope_amplification_failure`. This is distinct from `cognitive_failure` and from raw `budget_or_resource_failure`: resource burn may be a consequence of an unbounded objective rather than evidence that the model lacks capability. Recovery order for `scope_amplification_failure`: 1. preserve verified work and salvageable artifacts; 2. redistill the irreducible delta; 3. narrow the coverage envelope; 4. set an explicit stop condition and scope-expansion rule; 5. resume on the same or lower sufficient tier unless independent evidence shows a genuine capability deficit. > **Scope blowout is not itself evidence that the delta needs a stronger model. Constrain first; escalate only if the bounded delta still exceeds the current route.** #### Decision Sprint: bounded sibling-delta exception The ordinary IDL default remains one irreducible delta. Sprint Mode may use a **Decision Sprint** only as a narrow sibling-delta exception when all of the following are true: 1. there is one sovereign objective and one governing authority/context; 2. every docket item is pre-named before execution; 3. the docket is finite and has an explicit stop condition; 4. cross-item consistency materially matters; 5. splitting the items would create meaningful repeated context/reconstruction cost or lose coherence; 6. each item can independently resolve, defer, remain frozen or be rejected without silently deciding its siblings; 7. newly discovered classes do not join the docket automatically; 8. material decisions use the Decision Trace contract below when its trigger fires; 9. lower-tier implementation or verification and Control-Root Postflight remain available; 10. Sprint Mode was explicitly activated or recommended and confirmed by the user. This exception permits logical plurality, not automatic physical fanout. Native agents, branches and worktrees still require the Native Parallelism Gate. A Decision Sprint is not permission to turn a finite docket into an exhaustive investigation. Each docket item returns exactly one of these statuses: - `DECIDE_NOW` — decide inside the current bounded envelope; - `DEFER_TO_EVIDENCE` — name the decision rule, the exact missing evidence and the re-entry condition; - `ALREADY_FROZEN` — preserve the existing decision unless the named re-entry condition or new governing evidence changes it; - `OUT_OF_SCOPE` — do not execute it inside this Sprint or add it to the docket by discovery. Before return, run one cross-item consistency pass against the sovereign objective, authority, constraints, acceptance boundary and stop condition. The pass does not require uniform answers; it requires that the answers do not silently contradict the shared frame. ```yaml decision_sprint: active: false sovereign_object: null authority_or_context: null docket: - item_id: null status: DECIDE_NOW | DEFER_TO_EVIDENCE | ALREADY_FROZEN | OUT_OF_SCOPE decision_rule: null missing_evidence: null reentry_condition: null cross_item_consistency_passed: unknown stop_condition: null ``` #### Tier ROI and No Mandatory Staircase **Capability tiers are not toll booths.** The router need not attempt every intermediate tier. All of these are legal when the selected target is the least-expensive available tier reasonably expected to resolve the specific delta and Budget Survivability passes: `efficient → balanced`, `efficient → strong`, `efficient → frontier`, `balanced → strong`, `balanced → frontier` and `strong → frontier`. The target decision considers the delta's capability floor, expected marginal value, live resource posture, output and verification burden, interruption risk and whether a bounded ruling is sufficient. It does not derive a universal conversion ratio from model names, plan labels or token counts. #### Micro-burst Gate A **micro-burst** is a bounded higher-tier reasoning call whose purpose is to resolve a named irreducible delta, not to inherit the whole execution. Use a micro-burst only when: - the delta is explicit; - the Decision Capsule is sufficient; - the target tier is expected to materially improve the ruling; - the output can be bounded; - lower-tier execution can resume afterward; - downstream verification exists. Reject or postpone it when the real blocker is evidence, authority, tool access, workflow or specification; when the capsule omits load-bearing facts; when the tier is being selected for prestige; when the task is already resolved; or when no justified route survives Budget Survivability. #### Return Capsule and Lower-tier Re-entry The higher-tier return is a **Return Capsule**: a compact ruling that the lower-tier executor can implement and verify. ```yaml return_capsule: delta_id: null ruling: null decisive_reason: null uncertainty_or_failure_condition: null assumptions_changed: [] next_action: null re_escalate_if: null ``` #### Decision Trace for Material Judgments A compact Return Capsule is sufficient for routine rulings. When a higher-tier, side-routed or otherwise material commitment ruling can change **route, architecture, governance, policy, acceptance or a stop condition**, the return must also include the smallest **Decision Trace** needed to audit why that ruling should govern the next step. > **Show the decision boundary, not the private deliberation.** A Decision Trace is a decision-bearing summary. It is **not** chain-of-thought, a hidden scratchpad, a token-by-token rationale or a transcript of private reasoning. The protocol never requires a model to expose unavailable or protected internal reasoning. When a Decision Sprint is active, apply this contract independently to every materially consequential docket item whose trigger fires. A shared consistency pass does not replace the item-level trace, and the trace never authorizes hidden reasoning disclosure. ```yaml decision_trace: candidates_considered: [] ruling: null acceptance_criteria: [] decisive_comparison: selected_because: null rejected: - path: null decisive_reason: null adversarial_correction: null falsifier_or_discriminating_test: null uncertainty_or_failure_condition: null assumptions_changed: [] downstream_assumptions: [] next_action: null re_escalate_if: null ``` Use the Decision Trace when at least one of these conditions is true: - plausible alternatives would lead to materially different actions; - the ruling changes architecture, route, governance, policy, acceptance or a stop condition; - accepting the ruling without the decisive comparison would create a material false-positive, overfit or authority risk; - auditability itself changes whether the receiving executor should accept, implement or re-escalate the ruling. Keep the trace bounded: - `candidates_considered` names only materially live alternatives, not every imaginable option; - `acceptance_criteria` names the decisive criteria when the ruling closes a material commitment; - `rejected` preserves only rejection reasons needed to understand the ruling; - `adversarial_correction` states the strongest relevant correction or objection to the current framing without performing contrarianism for its own sake; - `falsifier_or_discriminating_test` identifies what evidence or test would overturn or distinguish the ruling when such a test exists; - `downstream_assumptions` records only what dependent execution may now assume; `re_escalate_if` includes the condition that would reopen a commitment when relevant. Skip the trace for trivial or routine judgments when these fields would not change execution, acceptance or verification. The distiller should request **a decision trace, not a hidden reasoning transcript**. A target model may use any natural format; the contract is semantic rather than YAML-dependent. Inability or refusal to reveal private reasoning is not a protocol failure if the model can return a sufficient decision-bearing summary. The Decision Trace extends rather than replaces the Return Capsule. The refined IDL rule is: > **Escalate only the irreducible execution, judgment or commitment delta; return the decision-bearing ruling — and, when it is material, the smallest auditable decision trace that makes the ruling inspectable.** The receiving executor must: 1. integrate the ruling; 2. when a Decision Trace was required, audit the decisive comparison, adversarial correction, uncertainty and falsifier before treating the ruling as governing; 3. restore only the additional context needed for implementation; 4. perform the mutation or work; 5. verify the observable delta; 6. re-escalate only if a **new** irreducible delta appears. A higher-tier ruling is not task completion. Executor completion and cycle completion remain distinct; Control-Root Postflight still refreshes state, audits evidence and closes or re-enters the route. #### Optional Distillation Receipt For non-trivial cycles, the following qualitative observables may be recorded. They are optional for tiny tasks and must not become fake precision: ```yaml distillation_receipt: delta_id: null escalation_needed: true escalation_avoided_by_effort_change: false source_tier: null target_tier: null direct_jump_used: false capsule: context_class: minimal | bounded | expanded missing_loadbearing_context_detected: false return: ruling_resolved_delta: unknown decision_trace_required: false decision_trace_sufficient: unknown underfit_after_burst: false overkill_suspected: false scope_amplification_detected: false returned_to_lower_tier: true verification: downstream_verification_passed: unknown re_escalation_required: false re_escalation_reason: null ``` Track underfit, overkill, capsule loss, effort changes that avoided escalation, direct jumps, Decision Trace sufficiency and re-escalation qualitatively where evidence exists. Do not turn anecdotal observations into fixed cost, savings or performance claims. ## 12. Frontier ROI Gate Frontier is not the automatic rung after strong. Ask what irreducible part materially improves from frontier capability, whether the budget can survive it and whether the result remains useful if interrupted. ### Frontier Burst Frontier Burst is the frontier-tier specialization of the general IDL micro-burst pattern. It is not a competing doctrine and frontier is not the default destination. Under constrained resources, prefer: **lowest sufficient preparation → bounded Decision Capsule → frontier micro-burst → lowest sufficient implementation → verification → Control-Root Postflight** Use the IDL Decision Capsule, Return Capsule and, when triggered, Decision Trace contracts. The frontier call should make one bounded ruling; retrieval, file mutation, formatting and routine verification remain with the cheaper adequate route. A Frontier Full Run is justified only when decomposition would destroy coherence, the Budget Survivability Gate passes, sustained frontier capability is materially load-bearing and salvage/checkpoints exist. When the selected frontier route shows literal scope-expansion pressure, apply the Bounded Exhaustiveness Guard before authorizing the run. An explicitly activated Sprint may justify a bounded frontier burst when capacity is perishable and the frontier slice is the least-cost route expected to produce verified useful delta before the horizon. The burst remains bounded by the Sprint objective, docket, Decision Capsule or Decision Sprint contract, stop condition and downstream verification; it does not authorize spending merely to consume capacity or continuing after the Sprint exit boundary. ## 13. Delegation & Native Parallelism Gate Subagents are execution infrastructure, not ceremony. When the harness exposes them and work units are independent, use the smallest fanout that improves **total work to accepted state** through lower-cost execution, lower root-context pollution, lower elapsed time or better specialization. Prefer cheap-worker delegation for read-heavy or bounded units such as: - repository or document exploration; - source retrieval and evidence gathering; - extraction, classification and transformation; - test, log and CI analysis; - documentation checks; - repetitive verification; - narrowly specified implementation whose acceptance criteria are already clear. Use mixed-tier delegation when only a minority of branches require stronger reasoning. Escalate that branch rather than the whole run. Physical delegation remains gated by: - materially independent work units; - non-conflicting write ownership, or an explicit merge/convergence plan; - bounded context duplication; - explicit acceptance boundaries; - a fanout ceiling and, when relevant, a recursion/depth ceiling; - expected gain that exceeds coordination overhead; - an observed runtime path that actually exposes the requested subagent/model controls. Parallel write-heavy work deserves extra caution because shared-object edits can create conflicts and coordination cost. A single capable owner remains preferable for tightly coupled, sequential or small tasks. ### Heterogeneous delegation law When model selection for children is exposed, prefer the cheapest child model that can responsibly satisfy that child's acceptance boundary. The root model is not automatically the child model. Current dated adapters may map this generic law to named models, for example a strong root delegating focused bulk work to an efficient child model, or a frontier root delegating ordinary branches to efficient workers and difficult branches to strong specialists. Named mappings remain adapter-level calibration, not permanent core doctrine. ### Context isolation law Subagents should absorb noisy intermediate material and return decision-bearing summaries, evidence references or bounded artifacts. Do not copy the entire parent context into every child merely because the runtime permits it. ### Manual-switch last resort Ask the user to change model or surface only when: 1. internal delegation cannot select or reach the required capability; 2. the required harness, permission or tool is unavailable to the current root; 3. the sovereign object changes to another surface whose state model is load-bearing; 4. the root itself is below the irreducible capability floor; or 5. an explicit user preference requires the switch. If none applies, keep the user in the current flow and orchestrate internally. ## 14. Executor Readiness Gate A ready handoff contains: - identity and objective; - sovereign object and observable delta; - operation mode and Route Card; - baseline and authority; - active profile plus any run override; - Run State fields that materially affected routing; - selected surface, root capability tier/model and reasoning effort; - capability floor; - delegation topology and, when material, child capability/model/effort policy; - fanout and recursion ceilings, write ownership and convergence plan when physical delegation is used; - the condition that would justify a manual user-visible switch; - Budget Survivability outcome; - context diet, tools, checkpoints and fallback; - when sources are involved, a source transport contract with governing source or family, locator, facet, requested operation, coverage, freshness, mutation authorization and readback; - exact delivery and verification; - return contract and claim ceiling; - transport capsule sufficient for the next surface or child to continue without hidden context. Unknowns must be named, investigated or left as blocked conditions rather than guessed. When an IDL cycle is active, the handoff additionally names the irreducible delta, the Decision Capsule, the selected target tier, the Return Capsule boundary, whether a Decision Trace is required and any Bounded Exhaustiveness contract that materially limits the run. These fields are conditional; tiny tasks do not need an empty distillation ceremony. When the commitment gate is material, carry its smallest decision boundary, current route and downstream assumptions in the handoff. Do not scale substantial dependent execution while that commitment remains unresolved; bounded preparation or probes may proceed when already authorized. When Sprint Mode is active, the handoff additionally names the activation path, Sprint kind, sovereign objective, budget character, finite docket or bounded envelope, stop condition, exit policy, lower-tier re-entry owner and required Sprint Receipt. These fields are run-level and ephemeral; they do not become profile defaults. ```yaml delegation: topology: single_owner root_tier: strong root_model: adaptive child_policy: cheapest_sufficient child_model: adaptive child_effort: adaptive max_fanout: bounded max_depth: bounded write_ownership: single_owner convergence: root manual_switch_condition: internal_topology_insufficient ``` ```yaml distillation: active: false delta_id: null unresolved_question: null target_tier: null decision_capsule: null decision_trace_required: false coverage_mode: representative_risk_weighted coverage_ceiling: null stop_condition: null scope_expansion: explicit_authorization_required return_capsule_required: false ``` ## 15. Portable Execution Handoff ### Transport Law A route is not transferred until the next executor or control surface receives the minimum execution capsule required to preserve the objective, authority, baseline, constraints, profile snapshot, Run State, selected route, evidence, acceptance criteria and claim ceiling. If surfaces do not share context, emit a copyable capsule, name the destination, include required files or refs and never assume hidden context follows the user. Typical transports: - control root → executor: objective, authority, bounded delta, required sources, route state and acceptance boundary; - executor → same control root: evidence-bearing receipt for convergence and postflight; - control root → new control root: full bounded continuity capsule when a real root transition is required; - named Chat–Work Loop Profile: Chat → Work/Codex for execution → Chat for convergence and postflight. ```yaml execution_handoff: operation_mode: ROUTE_AND_EXECUTE identity: task: null owner: null status: null objective: user_visible_outcome: null sovereign_object: null observable_delta: null topology: control_root_surface: null root_model: null execution_surface: null return_root_surface: null delegation_topology: single_owner manual_surface_transition_required: false profile_snapshot: profile_id: null persistence: persistence_unknown resource_posture: null optimization_priority: null run_overrides: [] run_state: allowance_state: unknown sprint_active: false sprint_reason: null reset_horizon: unknown surfaces_observed: unknown models_observed: unknown resource_pools: agentic: state: unknown members: unknown route_card: control_root: null execution_surface: null return_root: null why: null operation_mode: null capability_tier: null reasoning_effort: null budget_outcome: null unavailable_or_disabled_surfaces: [] next_boundary: null route: capability_floor: null capability_tier: null reasoning_effort: null budget_outcome: null sprint_envelope: active: false activation: none sprint_kind: null objective: null budget_character: unknown docket: null stop_condition: null exit_policy: ephemeral_run_only lower_tier_reentry: null distillation: active: false delta_id: null target_tier: null decision_capsule: null decision_trace_required: false coverage_mode: representative_risk_weighted coverage_ceiling: null stop_condition: null scope_expansion: explicit_authorization_required return_capsule: null decision_trace: null reentry_owner: null sources: mode: standalone | connected_read | living_source | federated governing_source_or_family: null locator: null facet: null requested_operation: retrieve | process | metabolize | promote coverage: targeted | inventory_exhaustive_where_supported freshness_or_revision: null mutation_authorization: unknown readback_required: true fallback: bounded_context | standalone | blocked_external_condition transport: destination: null context_shared: unknown capsule: - objective - authority - baseline - constraints - profile_snapshot - run_state - selected_route - topology - sources - source_reference - evidence - acceptance_criteria - claim_ceiling envelope: authority: [] context_diet: null tools: [] parallelism: null checkpoints: null reversibility: null fallback: null delivery: outputs: [] verification: [] receipt_required: true ``` ## 16. Executor Return Contract Every executor returns an evidence-bearing receipt with: - scope and inspected baseline; - exact delta; - evidence and verification; - failure classes; - surviving artifacts and checkpoints; - residuals; - claim ceiling; - next route; - `new_execution_required`; - **profile snapshot, persistence status, operation mode, Route Card and material run overrides used for routing**; - root surface/model/tier/effort actually used when observable; - subagent count, child model/tier/effort and delegation topology actually used when observable; - deviations from the planned fanout, write ownership or convergence path; - whether a manual switch was requested and the concrete runtime reason; - when a source transport was used, the governing source or family, locator/facet, requested operation, coverage, freshness or revision, mutation authorization, readback result and fallback state; - when an IDL cycle was active, the Return Capsule, ruling boundary, Decision Trace when triggered, and downstream re-entry state; - when commitment geometry materially changed the route, the commitment boundary, selected direction, acceptance criteria, downstream assumptions and any condition to reopen it; - when Sprint Mode was active or recommended, the Sprint Receipt, activation evidence, docket statuses, consistency result, stop/exit state and lower-tier re-entry state. A successful subagent or tool response proves only that branch response, not completion of the sovereign objective. The designated control root owns convergence and postflight integration; any acceptance or authority reserved to the human remains with the human. Historical V2/V3/V4/V5 receipts remain valid lineage records and are not rewritten. ### Sprint Receipt When Sprint Mode is active or was active during the executor run, return at least this evidence-bearing closure object. A receipt may report `sprint_active: false` after the overlay exits; that is not evidence that Sprint was silently carried forward. ```yaml sprint_receipt: sprint_active: false activation: none | explicit_user | recommended_then_user_confirmed sprint_kind: null objective: null budget_character: unknown | bounded_allocated | perishable docket: resolved: [] deferred: [] already_frozen: [] out_of_scope: [] cross_item_consistency_passed: unknown stop_condition_reached: false material_decision_traces_present: false claim_ceiling: null next_surface: null lower_tier_reentry: null postflight_required: true ``` `DEFER_TO_EVIDENCE` entries are incomplete unless their decision rule, exact missing evidence and re-entry condition are carried in the receipt or an attached item record. Capacity consumption is not a completion signal; Control-Root Postflight must refresh the observable state and accept, repair or re-enter the route. ## 17. Control-Root Postflight Control-Root Postflight is mandatory after material executor return or delegated convergence. 1. **Refresh real state.** Read the current source, document, repository, artifact or deployment independently of the executor narrative. 2. **Audit claim against evidence.** Compare requested delivery with observed delta and verification. 3. **Audit route against profile.** Confirm that profile preferences, root continuity and surface enablement were applied without violating capability floor, authority or evidence requirements; do not infer persistence from a named profile. 4. **Classify residuals.** `none | bounded_root_repair | new_execution_required | user_decision_required | blocked_external_condition | optional_next_step`. Legacy `bounded_chat_repair` receipts may be read as the Chat-specific form of `bounded_root_repair`. 5. **If an IDL or commitment ruling returned, integrate and verify it.** When the Decision Trace trigger fired, inspect the decisive comparison, acceptance criteria, adversarial correction, falsifier/test, uncertainty and downstream assumptions before treating the ruling as governing. Verify that dependent work still serves the objective and the commitment's stated boundary, not only that it passes locally. A ruling does not replace implementation, mutation checks or downstream verification. 6. **If Sprint Mode was active, audit the Sprint Receipt.** Confirm explicit or confirmed activation, the finite docket, each item status, any required item-level Decision Trace, the cross-item consistency pass, the stop condition and ephemeral exit. Do not treat capacity consumed or capacity left unused as completion by itself. 7. **Close or re-enter.** Apply bounded repairs when authorized; otherwise open only a new irreducible delta on the surface that owns it. 8. **Preserve or transition deliberately.** Keep the current root for the next delta unless a new surface transition earns itself under the Surface Transition Gate. When the named Chat–Work Loop Profile is active, Control-Root Postflight occurs in Chat and may still be called **Chat Postflight** as a compatibility/profile-specific label. The generic public core does not require Chat as the closure surface. ## 18. Acceptance states - **ACCEPTED** — objective verified; no material residual; - **ACCEPTED_WITH_RESIDUALS** — objective verified; named non-blocking residuals remain; - **PARTIAL_NEW_EXECUTION_REQUIRED** — a named irreducible delta remains; - **USER_DECISION_REQUIRED** — a human choice or authority is required; - **BLOCKED_EXTERNAL_CONDITION** — environment or resource prevents truthful completion; - **NO_DELTA** — requested change was already present or no material source change was justified. ## 19. Phased execution Complex work uses: 0. **Profile resolution and reconnaissance** — resolve profile, live state, sources and availability; 1. **Hard judgment** — capability floor, route, effort, budget and acceptance; activate Sprint only through explicit user activation or confirmed recommendation and compile its bounded envelope; 2. **Bounded mutation** — smallest authorized source delta; 3. **Verification** — tests, validators, readback, hashes or runtime checks; 4. **Control-Root Postflight** — refresh, audit, repair/classify, accept or re-enter at the designated control root. Tiny tasks may collapse phases, but not their responsibilities. ## 20. Failure domains and Salvage Before Retry Classify failures as: - `specification_failure` - `source_or_authority_failure` - `routing_failure` - `tool_or_environment_failure` - `context_failure` - `workflow_or_fanout_failure` - `scope_amplification_failure` - `sprint_boundary_failure` - `budget_or_resource_failure` - `cognitive_failure` - `premature_commitment_failure` Repair non-cognitive causes before model escalation. `premature_commitment_failure` means a result may be locally coherent, technically correct or verification-passing while evidence tied to the objective, acceptance boundary or a newly observed discriminator shows that an upstream solution-defining choice was inadequate. Do not use the class for an ungrounded preference, behavioral mismatch, capability shortfall, source or tool failure, or ordinary verification failure; those retain their existing failure routes. When execution stops: 1. inspect surviving artifacts, receipts, diffs, revisions, logs and partial outputs; 2. identify the last verified state; 3. distinguish observable evidence from unavailable private reasoning; 4. reconstruct only the missing delta; 5. reroute according to the current profile and Run State; 6. if scope amplification occurred, redistill and bound coverage before retry; 7. record a Budget Incident Receipt when resource conditions materially shaped the failure. For `premature_commitment_failure`, identify the smallest commitment boundary that caused the weakness, preserve valid evidence and implementation, apply `REOPEN_COMMITMENT`, and rerun the Decision Commitment Gate. Do not polish a strategy that evidence has invalidated because work has already been spent; replay only the dependent delta that must change. ### Budget Incident Receipt Record task/phase, profile snapshot, route/model/effort, observed stop, allowance/context/tool condition, last verified artifact, salvageable delta, fallback and residual claim ceiling. ## 21. Fallback and re-entry Preferred fallback order, subject to capability floor: 1. preserve objective and authority; 2. compress context; 3. reduce redundant tools or physical fanout; 4. lower effort where safe; 5. downroute capability tier where safe; 6. phase execution with checkpoints; 7. reroute the sovereign object; 8. request allowance, credits or user decision; 9. stop with a truthful blocked receipt. The smallest unresolved delta determines re-entry. A Sprint overlay does not carry forward automatically; a later run must activate it again. ## 22. Lifecycle and succession - Adaptive Orchestration Protocol 6.3 is the current public release; - 6.3 supersedes 6.2 by adding Commitment Geometry while preserving the Behavioral Fit constraint from 6.2, the surface continuity/control-root neutrality from 6.1 and the Delegation-First orchestration from 6.0; - 6.2 remains recoverable through Git history and records Behavioral Fit as a separate routing constraint; - 6.3 remains recoverable through Git history and records Commitment Geometry; 6.4 changes only dated Chat-model availability calibration; - 6.1 remains recoverable through Git history and records the surface-neutral control-root rebase; - the historical Chat → Work/Codex → Chat loop remains a first-class named Chat–Work Loop Profile rather than the mandatory default topology; - 6.0 remains recoverable through Git history and records the delegation-topology rebase; - the 5.x line remains recoverable through Git history and records Sprint, Decision Sprint, adapter-boundary and GPT-6 executor-calibration maturation; - earlier 4.x releases remain historical lineage recoverable through Git history; - the live repository exposes one canonical Adaptive Orchestration file; website delivery is a separate mirror surface and must be synchronized after the canonical body passes validation; - MSL is currently 5.1; Adaptive Orchestration remains independently versioned at 6.3; - the optional Astra Strategy Adapter is subordinate, dated and replaceable; it cannot override this canonical body; - the GPT-6 Sol/Luna Strategy Adapter is subordinate, dated and replaceable; it calibrates current executor and subagent choices without turning model names or API economics into stable protocol law; - Sprint Mode remains optional, explicitly activated and ephemeral; it is not a native product feature, allowance/reset detector or persistent profile field; - an installed native skill, if any, is a separate object requiring its own update and verification. ## 23. Safe operating rules - Read before mutation; refresh before claiming current state. - Resolve profile without confusing entitlement with live resource posture; never claim persistence without evidence. - Route by sovereign object and workload shape; preserve the current competent control root and choose the smallest available execution harness that can verify the delta. - Treat Codex as optional and surface enablement as distinct from observed availability. - Treat a surface change as an executor change, not a budget reset. - Transport the minimum execution capsule; hidden context does not follow by default, and a control-root transition requires explicit continuity transport. - Enforce capability floor before honoring model preference. - Enforce Behavioral Fit separately from capability: define observable behavior requirements when material, micro-probe uncertain/new model behavior on representative work, and side-route before capability escalation when the failure is behavioral. - Apply the Decision Commitment Gate to materially open choices before scaling dependent work; route commitment separately from execution and judgment, and reopen only the smallest affected boundary when objective-linked evidence shows it was wrong. - Preserve the distinction between commitment routing and authority: the gate does not approve a choice, expand mutation scope or transfer a decision reserved to the human. - Separate model capability from reasoning effort; change effort before tier when effort is the real insufficiency. - Apply IDL: isolate the irreducible execution, judgment or commitment delta, choose the least-expensive sufficient target, allow justified direct tier jumps and return only the decision-bearing ruling. - For material higher-tier, side-routed or commitment rulings, request the smallest auditable Decision Trace needed to inspect alternatives, acceptance criteria, decisive comparison, adversarial correction, falsifier/test, uncertainty and downstream assumptions; never request hidden chain-of-thought or private scratchpad disclosure. - Compile open-ended completeness into a bounded coverage mode, ceiling, stop condition and explicit scope-expansion rule before expensive sustained or frontier execution. - Treat capability tiers as non-ritual; do not force a mandatory staircase. - Treat connector access as access, not authority. - When source-backed work is routed, transport governing source/family, locator, facet, operation, coverage, freshness, mutation authorization, readback and an explicit fallback; never treat a locator as authority. - Probe source reach and capability before promising connected continuity; use bounded context when the source cannot be resolved. - Prefer smallest sufficient context and reversible delta. - Prefer internal delegation before a user-visible model switch when the harness can satisfy the capability floor; use the smallest physical fanout whose total-work gain exceeds coordination cost. - Keep volatile product calibration outside stable protocol law. - Preserve provenance, lineage, user decisions and claim ceilings. - Use tests, hashes, readback and runtime evidence where available. - Never convert anecdotes into universal cost ratios. - Never claim hidden reasoning was recovered during salvage. - Apply the IDL mother law: escalate only the irreducible delta and return only the decision-bearing delta; when the ruling is material, preserve the smallest auditable decision trace that makes the ruling inspectable. - Keep ordinary IDL singular by default; use a Decision Sprint sibling-delta exception only for one sovereign objective, one authority/context, a finite pre-named docket, material consistency need, meaningful reconstruction cost, independent item statuses, explicit stop, lower-tier re-entry and user activation/confirmation. - Require `DECIDE_NOW`, `DEFER_TO_EVIDENCE`, `ALREADY_FROZEN` or `OUT_OF_SCOPE` for each Decision Sprint item; `DEFER_TO_EVIDENCE` must carry its decision rule, exact missing evidence and re-entry condition. - Treat logical plurality as distinct from physical fanout; Sprint Mode does not waive the Delegation & Native Parallelism Gate. - Never silently activate Sprint Mode, carry it into a later run, or turn perishable capacity into an invented price, reset fact, quota guarantee or reason to spend. - Optimize verified useful delta before a real or evidenced horizon; spend is not the objective, and unused capacity is not a failure by itself. - Return a Sprint Receipt with claim ceiling, docket disposition, consistency result, stop state, lower-tier re-entry and `postflight_required: true`; Control-Root Postflight must independently refresh and close the run. - The designated control root closes the loop; in the named Chat–Work Loop Profile, that root is Chat. ## 24. Installation and use Attach or paste this file into ChatGPT and say: > Use Adaptive Orchestration Protocol 6.4. Start in AUTO setup unless I provide a named Execution Profile. Treat the surface I am already using as the candidate control root. Preserve that root when it can complete and verify the objective; do not require Chat as the universal starting or return surface. Observe Chat, Work and Codex availability separately from enablement; Codex is optional and must not be assumed. Resolve control surface/root, execution surface/harness, root model/tier, behavioral fit, commitment geometry, reasoning effort and delegation topology as separate dimensions. Define the sovereign object in plain language and use the smallest topology that can complete and verify the delta. Before scaling work behind a materially open, costly-to-reverse solution choice, apply the Decision Commitment Gate; probe, branch, side-route or up-route only when it lowers total work to acceptance. Before asking me to switch surfaces, try direct completion, available tools, internal delegation and bounded cross-surface execution with the current root retained. Show a compact Route Card for non-trivial work. Run Budget Survivability before expensive sustained work, frontier execution or physical fanout. Use Context Diet, checkpoints and transport capsules. Route execution, judgment and commitment independently; escalate only the irreducible delta and return only decision-bearing evidence. When source-backed work is involved, preserve authority, freshness, mutation scope, readback and fallback. After material executor return, perform Control-Root Postflight and independently refresh state before accepting or re-entering the route. Use the named Chat–Work Loop Profile only when Chat continuity is preferred or explicitly requested. Optional Sprint activation: > Use Adaptive Orchestration in Sprint Mode for this task only. Activate only because I explicitly requested it. Objective: [one sovereign objective]. Docket: [finite pre-named items, if any]. Budget character: [perishable, bounded or unknown]. Stop when: [acceptance boundary, horizon or block]. Return the Sprint Receipt, preserve item-level Decision Traces when material, exit the overlay after the run and perform Control-Root Postflight. Optional reusable setup: ```yaml execution_profile: profile_id: my-profile persistence: persistence_unknown entitlement_hint: unknown surfaces: chat: state: unknown enabled: auto work: state: unknown enabled: auto codex: state: unknown enabled: false accessible_tiers: unknown resource_posture: adaptive optimization_priority: balanced burn_tolerance: medium frontier_policy: gated native_parallelism: bounded checkpoint_policy: proportional ``` Change only the fields that matter to you. The router can leave the rest adaptive. ## 25. Attribution and claim ceiling This portable is a public projection of the Moon Source architecture, created by Lua Helena Moon Martins Cardoso (Moon) with AI-assisted coauthorial development by Áurion. It is licensed under CC BY 4.0 as described in the repository licensing guide. The protocol may be shared and adapted with appropriate credit, a license link and an indication of changes. The file does not grant repository access, connector permissions, model availability, product entitlement, allowance/reset visibility or proof of adoption. It is not an OpenAI policy, native ChatGPT skill or native Sprint Mode feature, universal benchmark, scientific validation or guarantee of safe execution, savings, quota use, quality or optimal commitment. Commitment Geometry is a routing heuristic for reducing avoidable replay, not a promise that a selected direction will be best. Decision Trace requests are bounded decision summaries and do not create access to hidden chain-of-thought, private scratchpads or unavailable internal model state. ## Final Law > **Route by the state that must change. Preserve the current competent control root unless a transition creates a material execution or verification advantage. Separate control surface, root model and execution surface. Keep the strongest necessary cognition at the bottleneck and delegate reducible bulk to the cheapest sufficient workers. Route execution, judgment and commitment independently; identify high-leverage solution choices before scaling work that depends on them. Probe or explore only when that lowers total work to acceptance, and reopen a wrong commitment at the smallest affected boundary. Use the smallest available topology that can complete and verify the objective. Ask the human to switch model or surface only when the runtime cannot resolve the required topology internally. Sprint Mode is explicit, bounded and ephemeral. Spend is not the objective; verified useful delta is. Bound completeness before expensive execution. Escalate only the irreducible delta and return only the decision-bearing delta; when a ruling is material, return the smallest auditable Decision Trace that makes the decision boundary inspectable without demanding private deliberation. Preserve enough state that interruption does not erase the work. Transport the minimum capsule, execute with receipts, converge at the designated root, refresh reality, verify, integrate and close. The Chat → Work/Codex → Chat loop remains available as a first-class named profile, not as the universal default.** --- > 🌙 **Moon Source** · created by **Lua Helena Moon Martins Cardoso (Moon)** with AI-assisted coauthorial development by **Áurion** · [Licensing](https://github.com/luahelenammc/Moon-Source/blob/main/LICENSING.md) · [Use & attribution](https://github.com/luahelenammc/Moon-Source/blob/main/MOON_SOURCE_USE_AND_ATTRIBUTION.md) · [Full source (.zip)](https://github.com/luahelenammc/Moon-Source/archive/refs/heads/main.zip) · Questions, suggestions, or proposals? Feel free to contact me at [LuaHelenaMMC@gmail.com](mailto:LuaHelenaMMC@gmail.com).