# Governance (/docs/strategies/governance)
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 — 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 [#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 [#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.
```mermaid
stateDiagram-v2
[*] --> draft
draft --> active
active --> paused
paused --> active
active --> stopped
stopped --> archived
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 [#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](/docs/management/experiments) for the lifecycle, subject
scopes, API calls, exposure contract, and delayed-scoring flow.
## Strategy optimization proposals [#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 [#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/`).
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 [#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](/docs/strategies/contracts#strategy-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](/docs/strategies/writing-a-custom-strategy) for the
hands-on path.
## Related [#related]
The declarations certification and promotion gates enforce.
Bandits that must declare a learning dataset to be certified.
Run live tests with sticky variants, immutable exposure receipts, and delayed scores.
Build, register, certify, and remotely deploy your own strategy.