> ## Documentation Index > Fetch the complete documentation index at: https://docs.accelmars.com/llms.txt > Use this file to discover all available pages before exploring further. # Planning a compatible request > Resolve what the caller needs before a provider adapter writes the request. A good execution plan answers a specific question: **can this approved offering perform this request without changing its required meaning or violating its restrictions?** Gateway plans before it sends. The planning step is deterministic: given the same requirements, approved capability facts and policy, it should produce the same resolved parameters or the same incompatibility result. It does not discover capabilities by making a paid provider call. ## Begin with requirements, not provider parameters The application states the result it needs: the required answer allowance, reasoning behavior, output format and delivery mode. Applicable policy and authority constrain the permitted model, provider, region, data handling and available resources. Some requirements are mandatory. Others may be optional under an explicit policy. Gateway cannot turn a mandatory requirement into a preference merely because a cheaper or healthier candidate is available. A purpose helps select and constrain an execution plan; writing a purpose name in a request does not create permission. ## Intersect the constraints Imagine a request requiring a schema-valid result from an approved region. Offering A satisfies the schema but is outside the allowed region. Offering B is in the region but lacks verified schema support. Neither is eligible. Combining A's capability with B's location on paper does not create a third offering. The correct outcome is no eligible candidate unless another already-approved offering satisfies all mandatory conditions. Capability, permission, credential validity and current availability answer different questions. All applicable checks must hold. Passing one is not a substitute for another. ## Produce one resolved call The resolved plan is called an **EffectiveCall**. It records the selected offering and the effective execution controls, including the relevant capability and policy versions. For example, a provider may count reasoning and visible answer tokens under one output ceiling, while another uses a different accounting rule. The planner resolves that meaning using verified facts. It does not give a generic limit to an adapter and ask it to guess. The [reasoning and budget example](/public/gateway/supply/reasoning-and-budgets) shows why this distinction matters. ## Translate without changing the decision The provider adapter converts the resolved parameters into the selected protocol. It must not silently disable reasoning for a JSON request, remove a schema constraint or shrink the required answer allowance. Adding a model whose controls already fit the accepted schema should primarily require qualified data. Genuinely new protocol semantics require an explicit supported schema and encoder change, not a hidden conditional in shared orchestration. ## Keep the plan stable during execution Permitted recovery selects only from the original authorized plan and remaining budget. A provider hop does not refresh the call's limits. Exact model or provider pins can eliminate otherwise possible alternatives. New catalogue versions do not rewrite the history of a call already running. Current safety restrictions may narrow what is still allowed, but runtime observations cannot broaden the approved capabilities. Planning can establish that sufficient capacity is allowed. It cannot guarantee that a stochastic model will use that capacity well or produce a useful answer. Actual usage and output must still be observed and checked. Continue with [Reasoning and answer budgets](/public/gateway/supply/reasoning-and-budgets) or [When the answer must follow a schema](/public/gateway/supply/structured-answers). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.