import type { ChainSelectionInput, ChainSelectionWithFallbackInput, SelectionOutcome } from './types.js';
/**
 * Select the one chain an action is decided against, out of the set an agent holds.
 *
 * draft-03 section 3.3 (lines 594-596) states the rule this implements: "Each action
 * selects one root-to-leaf authority chain.  A verifier MUST NOT union scopes or budgets
 * from multiple chains.  Cross-principal composition requires a separate profile."
 * Required behaviour, not a proposal. The one part of this module that is proposed
 * rather than specified is the fallback surface, and it lives in `selectWithFallback`.
 *
 * Selection rule, which draft-03 does not state and this implementation therefore fixes
 * and documents. Candidates are evaluated in held order. The FIRST candidate that both
 * verifies `valid` and covers every needed scope grant is the selected chain, and the
 * action's spend is then reserved against that chain and no other. A spend refusal is that chain's
 * refusal, and no further candidate is read. Scope selects, spend admits or refuses. The
 * alternative, continuing past a spend refusal to a chain with a larger ceiling, is a
 * fallback in everything but name, and this function does not do it silently.
 *
 * `held` never shrinks to the one chain: every candidate this call read appears in
 * `evaluations`, and the chosen `chain_id` is one string, so a caller and an auditor can
 * both see which chain the action was decided against and which chains were passed over.
 *
 * A caller that already had a chain selected and is now asking again because that chain
 * failed is switching, not selecting, and should use `selectWithFallback`. This function
 * does not know that a previous selection existed and cannot report a switch.
 *
 * Nothing here reads a clock, a random source or the network: `options.now` and the three
 * resolvers are the caller's, exactly as `verifyAuthorityDelegationChain` takes them.
 * This function never throws.
 */
export declare function selectChainForAction(input: ChainSelectionInput): SelectionOutcome;
/**
 * Decide an action against the chain it already selected, and switch to another held
 * chain only when the caller has explicitly authorized a switch.
 *
 * The preferred-chain half is draft-03 section 3.3: one chain, no union. The fallback
 * half is PROPOSED and has no counterpart in draft-03, where `fallback`, `fall back`,
 * `resurrect` and `reselect` occur zero times. It serves a proposed rule this SDK does
 * not claim is specified anywhere: a switch to another stored grant should be a visible
 * decision, not a retry.
 *
 * `fallback: null` is that proposed rule in one parameter. It reads no held chain other
 * than `preferred_chain_id`, so `evaluations` has exactly one entry and
 * `fallback_considered` is false. There is no code path on which this function reaches
 * another chain without the caller having passed an authorization object.
 *
 * With an authorization object, the remaining held chains are evaluated in held order
 * and the first that authorizes the action is selected. The result then carries
 * `switched_from`, the chain the action had selected, and `fallback_ref`, the caller's
 * opaque reference, so the switch is in the result rather than only in the caller's head.
 * That reference is recorded and NEVER interpreted: nothing specified defines what makes
 * a fallback explicitly authorized, and this SDK does not invent a definition, so a
 * `fallback_ref` is not evidence that anything authorized anything.
 *
 * The preferred chain is always evaluated first and its own outcome is always
 * `evaluations[0]`, including when a fallback then succeeds, so the reason the action
 * left its selected chain stays in the record. A later finding never rewrites it.
 *
 * This function never throws.
 */
export declare function selectWithFallback(input: ChainSelectionWithFallbackInput): SelectionOutcome;
//# sourceMappingURL=select.d.ts.map