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:
| Surface | Traffic | Side effects | Question it answers |
|---|---|---|---|
| Shadow campaign | live | none | What would the candidate have picked, vs. authoritative? |
| Experiment | live slice | authoritative for that slice | Is the candidate actually better on real outcomes? |
| Simulation | offline curated | none | How does it behave on hand-built scenarios? |
| Replay | recorded | none | Does re-executing a recorded decision reproduce it? |
| Canary | shifting slice | authoritative, guardrailed | Can 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.
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.
Related
Contracts
The declarations certification and promotion gates enforce.
Learning strategies
Bandits that must declare a learning dataset to be certified.
Experiments
Run live tests with sticky variants, immutable exposure receipts, and delayed scores.
Write a custom strategy
Build, register, certify, and remotely deploy your own strategy.
Contracts
The governance layer — strategy contracts, versioned recipes, the contract/recipe API and MCP surface, feature snapshots, and the durable strategy state plane.
Writing a Certified Strategy
Implement the Strategy interface, register it with the registry, add tunable params and capabilities, and declare a contract for certification.