Skip to content

Canary Handoff Sequence

Protocol — instantiates Mobile-Defect Reconfiguration

Passes the defect to the next unit through a fixed handoff contract, proving the change on a small parallel slice before committing the whole unit.

Canary Handoff Sequence governs how the moving defect crosses from one unit to the next. At each boundary it does two things: it enforces a fixed handoff interface — a contract the receiving unit must satisfy before it accepts the change — and it proves the change on a small canary slice running in parallel before the full unit is committed. Its defining trait is the representative small-slice test at the boundary: rather than trusting that a move which worked upstream will work here, it exposes a fraction of the next unit to the change on a parallel scaffold, watches it, and only then promotes the whole. The handoff is gated on evidence from a live sample, not on assumption.

Example

A carrier is migrating subscribers from an old packet core to a new one, region by region. Each region is a unit, and the handoff can't be a leap of faith — a bad cutover strands thousands of phones. The Canary Handoff Sequence moves the migration across regions through a fixed interface: the new core must pass a readiness contract (routing, billing hooks, and the emergency-call path all green) before it may receive any traffic. Then, instead of switching the whole region, it moves roughly 1% of subscribers — a canary cohort — onto the new core in parallel with the old, and watches call-setup success and drop rates on that live slice. If the canary holds through the soak window, the region is promoted; if it degrades, the cohort is pulled back through the same interface and the handoff aborts before the other 99% ever move.

How it works

  • Enforce the handoff contract. The receiving unit must satisfy a fixed readiness interface before it can accept the defect — the same contract at every boundary, so handoffs are uniform and auditable.
  • Route a canary in parallel. A small, representative slice of the next unit takes the change on a parallel scaffold alongside the unchanged remainder.
  • Judge on live signal. Promotion waits for the canary to hold against defined health signals over a soak window — evidence, not elapsed time.
  • Promote or abort atomically. A healthy canary promotes the whole unit; a sick one is withdrawn through the same interface, containing the blast radius to the slice.

Tuning parameters

  • Canary fraction — how large the sampled slice is. Larger canaries surface rarer faults but expose more of the unit if the change is bad.
  • Soak window — how long the canary must hold before promotion. Longer soaks catch slow-burning faults at the cost of migration speed.
  • Promotion signal — which health metrics gate the handoff and how strict their thresholds are.
  • Interface strictness — how demanding the readiness contract is before a unit may receive the change at all.

When it helps, and when it misleads

Its strength is that it makes each handoff fail small: a bad move is caught on a fraction of one unit, behind a uniform contract, instead of propagating across the boundary. This is the discipline of canary releasing / progressive delivery — expose a little, watch, then widen.[1]

Its assurance is only as good as the canary is representative. A slice that misses the conditions where the fault actually bites — an untested device type, a peak-load hour — passes green and promotes a defect anyway. The other classic misuse is promoting on a timer rather than on signal, treating the soak window as a formality to wait out rather than a test to pass. The discipline is to choose the canary to cover the risky conditions, and to promote strictly on health evidence, aborting through the same interface the moment the slice degrades.

How it implements the components

  • defect_handoff_interface — the fixed readiness contract every unit must satisfy to receive the change, making handoffs uniform and abortable.
  • parallel_service_scaffold — the parallel path that lets a canary slice run the change beside the unchanged remainder.

It governs crossing a boundary but does not bound how many crossings run at once — that concurrency cap is Defect-Population Limit Protocol — and it is not the final delivery to a sink, which is Terminal-Sink Handoff.

References

[1] Canary releasing — a form of progressive delivery — rolls a change out to a small, monitored slice of traffic first and widens only if the canary stays healthy. It is named for the caged canaries once carried into mines as early-warning sentinels. ↩