Routing Strategies

Governance

Ship strategy changes safely — shadow campaigns, experiments, certification, optimization, and governed remote strategies, plus the five distinct evaluation surfaces.

Governance is the safety layer around changing routing behavior. It lets you evaluate a candidate strategy against real traffic with zero side effects, prove mechanical safety before promotion, tune parameters within guardrails, and run bring-your-own strategies under strict controls. None of these route directly — they govern the strategies that do.

Ductor provides shadow campaigns, certification, optimization, experiments, and remote tenant-defined strategies. This is also the gate a marketplace needs: for certified strategies, governed skills, and connector actions to become a priced catalog that a Worker — human or agent — draws against a budget, every candidate must first prove mechanical safety here. That priced catalog is on the roadmap; the certification, shadow, and remote-runtime controls that make it safe ship today.

The five evaluation surfaces

Before promoting a strategy change you can evaluate it five different ways. They are not interchangeable — each answers a different question with a different risk profile:

SurfaceTrafficSide effectsQuestion it answers
Shadow campaignlivenoneWhat would the candidate have picked, vs. authoritative?
Experimentlive sliceauthoritative for that sliceIs the candidate actually better on real outcomes?
Simulationoffline curatednoneHow does it behave on hand-built scenarios?
ReplayrecordednoneDoes re-executing a recorded decision reproduce it?
Canaryshifting sliceauthoritative, guardrailedCan we ramp real traffic to it safely?

The usual path is left to right: shadow gathers evidence with no risk, an experiment tests it on a controlled slice, and a canary ramps it under guardrails.

Strategy shadow campaigns

A live counterfactual evidence plane. A shadow campaign runs one or more candidate strategies against real routing traffic while it never influences the authoritative decision, capacity, connector effects, strategy state, or workflow runs. Each shadowed decision records what the authoritative strategy selected, what each candidate would have selected, why they diverged, and — once outcomes arrive — which candidate would have matched the winning recipient.

Why it matters. Shadowing is the zero-risk way to validate a strategy: the candidate sees exactly the traffic the incumbent sees, but its output is recorded and discarded, not acted on. Any state mutation intents it returns are thrown away. Candidate failures are captured as typed results (candidate_error, candidate_timeout, candidate_panic) and never surface as live routing errors.

How it's shaped. Campaigns move through a bounded lifecycle; only an active campaign evaluates traffic.

draft active paused stopped archived

Sampling is a stable function of the decision id (so replays reproduce the sampled set). Bounded guardrails — divergence_rate, critical_divergence_count, candidate_error_rate, and more — evaluate over a minimum live sample, and a promotion gate can require zero critical divergences before a candidate may canary. A candidate is only eligible if its contract permits the shadow execution shape.

Where it fits. The evidence source that precedes an experiment — it produces what a promotion gate requires, not a traffic-shifting mechanism itself.

Live experiments

A tenant-scoped A/B test that governs live behavior across three supported surfaces: routing_strategy, workflow_step, and agent_definition. Ductor keeps entity assignments sticky, persists immutable exposure receipts for workflow and agent executions, and accepts idempotent delayed scores when the real outcome arrives later.

For routing, variant strategy options are applied before the authoritative decision and committed outcomes can be sampled automatically. For workflow and agent experiments, the assignment response binds the chosen variant to the run, step, or agent session; your runtime applies that variant and later scores the receipt. Unlike a shadow campaign, an experiment does change live behavior for its admitted traffic slice.

See Experiments for the lifecycle, subject scopes, API calls, exposure contract, and delayed-scoring flow.

Strategy optimization proposals

Auto-tuning runs that search a bounded, auditable parameter space against an objective with guardrails, protected cohorts, and fairness floors — then emit reviewable change proposals with expected lift, guardrail evidence, risk level, and rollout/rollback plans (application/routing/strategyoptimization/).

How it's shaped — tuning is governed, not free. Each tunable parameter declares a StrategyParamTuningSpec that bounds what optimizers may touch: a mode (offline, online, manual_review), required evidence (learning_dataset, feature_snapshot, scenario_pack, promotion_guardrail), guardrail metrics that must hold, a state impact (any stateful impact forces manual_review), and bounded max relative/absolute deltas. The spec narrows the searchable domain; it never widens runtime validation. Promotion preflight resolves a proposal's strategy_config artifact through the latest certification receipt.

Strategy certification

The durable evidence plane that proves a strategy version / contract / deployment / policy / state-mode / replay-mode satisfies Ductor's mechanical safety rules before it becomes authoritative (application/routing/strategycertification/).

Certification proves mechanical safety only

A passing receipt means the strategy matches its Ductor contract, fixtures, no-side-effect policy, and activation requirements. It does not certify legal fairness, regulatory compliance, or business approval — those are separate sign-offs.

How it's shaped. A versioned suite is derived from the live contract registry and declares required categories — golden, dry_run, determinism, explanation, scenario, outcome_fixture, state_plane, remote_runtime. Runs produce immutable receipts with pass/fail matrices and expiry; waivers require an actor, reason, expiry, and policy scope, and are disallowed by default for authoritative remote/optimization activation. Activation checks fail closed when a fresh passing receipt is missing, stale, failed, or blocked. A contract that declares a certification governance requirement can't be activated without a passing (or explicitly waived) receipt.

Custom and remote strategies

Bring-your-own selection logic runs as a governed tenant-specific promoted deployment over a gRPC PluginService.Select (Connect RPC) — the same Select boundary as a built-in, but out of process (application/routing/remotestrategy/, pkg/strategy/remotegrpc/, domain/strategydeployment/).

How it's shaped. A remote strategy carries a nondeterministic_remote determinism profile and — if it claims replayability — must record remote evidence, a rule the contract validator enforces. Enterprise remote deployment activation fails closed without a fresh passing certification receipt, and remote strategies should be shadowed before production binding. The custom_strategy_canary recipe drives the rollout. See Writing a custom strategy for the hands-on path.