Spaces that wrap spaces

The capability spine decided who may reach a resource. This chapter is about what happens to a request on the way — the governors that make a resource resilient and bounded: rate limits, retries, circuit breakers, failover, timeouts, and concurrency caps. In ikigai these are not features baked into each endpoint. They are overlays: a space wraps another space and changes how requests pass through it, and because a space can wrap a space, they stack.

This builds directly on dynamic spaces from The ikigai Book. An overlay is a space whose job is not to answer but to govern the space it wraps, so a wrapped resource answers exactly as before until a governor has something to say — at which point what it says is a refusal.

   request
     │
     ▼
  ┌──────────────────────────────────────────────────┐
  │ Retry (idempotent verbs, spends a budget)        │
  │  ┌─────────────────────────────────────────────┐ │
  │  │ CircuitBreaker (open / closed / half-open)  │ │
  │  │  ┌────────────────────────────────────────┐ │ │
  │  │  │ Timeout (a deadline on the call)       │ │ │
  │  │  │  ┌───────────────────────────────────┐ │ │ │
  │  │  │  │  the space being guarded          │ │ │ │
  │  │  │  │  (a door, a mount, an endpoint)   │ │ │ │
  │  │  │  └───────────────────────────────────┘ │ │ │
  │  │  └────────────────────────────────────────┘ │ │
  │  └─────────────────────────────────────────────┘ │
  └──────────────────────────────────────────────────┘

The three facts every overlay reads

The overlays share a vocabulary. Each one makes its decision from the same three facts about a request, and no more:

• Is the verb idempotent? A Source or an Exists can be safely re-issued; a Sink that is not idempotent cannot. Retry and Failover refuse to re-run what is unsafe to re-run.
• What class is the failure? A failure is transient (worth another try or a different target) or permanent (do not bother). A 429-style “try again after” carries its own delay.
• What is left of the retry budget? A single counter shared across the whole resolution tree.

That third fact is the one security hook in the resilience family, and it is worth dwelling on. Nested retries multiply: a Retry wrapping a space that itself wraps a Retry could turn one request into many. A shared retry budget caps the total number of re-issues across the entire tree, so no arrangement of nested governors can amplify one request into a storm. It is a blast-radius bound, expressed as authority — you hold a budget, and when it is spent, re-issues stop.

The two faces, overlay by overlay

Here is the split that makes this chapter part of the book rather than an appendix. Every governor has a security reading and a UX reading, and the verdict is which one it is primarily for:

The pattern in the table is the pattern of the whole book. A refusal that protects the dependency or the host (RateLimit, CircuitBreaker, Timeout, Throttle) has a security face; a re-issue that protects the caller’s experience (Retry, Failover) is UX-facing, with the budget its only security hook. Same mechanism, read by what the refusal is for.

Transparency: a governor you can see through

One property makes all of this drawable, and it is worth naming because it is unusual. The overlays are transparent to structure: a governor reports the topology, the identity, and the cache identity of the space it wraps. So Retry(CircuitBreaker(Timeout(space))) still reports the doors underneath it; the system’s own introspection sees through the stack to what is guarded. What a governor adds is only ever a refusal — and the kernel never caches a refusal — so the arrangement can be harvested from the topology while the governor’s state (a breaker open or closed, a budget’s remaining count) is a separate thing drawn on top.

The governor as a constraint made explicit

Step back and the whole chain has one organizing idea, borrowed from the theory of constraints (Goldratt): a system’s throughput is set by its bottleneck, and the useful moves are to exploit the bottleneck, subordinate everything else to it, and make the constraint explicit and enforceable. The overlays are the governance half of that: a rate, a timeout, a concurrency cap is a constraint written down as a resource and enforced by the kernel, so “do not exceed this” stops being a hope in a code review and becomes a refusal at resolution. Non-conforming behavior simply fails to resolve. (The throughput half of the same idea — cache and golden thread as ways to exploit the constraint — is the next chapter.)

Drive the overlays yourself

The box diagram above is a picture. Below it runs: a resilience harness in this page, the real ikigai-throttle governors wrapped around a stub dependency you control, so you can make the dependency fail, stall or push back and watch what each governor does about it. Nothing is mocked except the dependency. The breaker that trips here is the CircuitBreaker every ikigai host runs, and the timeout is its Timeout.

The harness is a kernel of its own (crates/resilience-harness), started the first time you press Run in a cell below that says “in the resilience harness”, or a button beside the picture. It binds a handful of names:

• urn:iki:tutorial:harness:mode, the one thing you write: what the stub does when called. ok answers; slow takes 10 seconds, past the timeout’s budget; fail fails transiently (unavailable); limited asks to be called again after a second (retry after). Anything else is refused as an invalid argument.
• urn:iki:tutorial:harness:upstream, the stub itself, ungoverned. It numbers every call it receives, so an answer tells you whether a call reached it.
• urn:iki:tutorial:harness:call, the same stub behind the stack this chapter draws: Retry(CircuitBreaker(Timeout(upstream))).
• urn:iki:tutorial:harness:clock, the harness’s time. It moves only when you move it (Sink a duration such as 5s) or when a governor waits.
• urn:iki:tutorial:harness:service, the same stub again, in a primary space, behind a Failover whose second space is a backup that always answers.
• urn:iki:tutorial:harness:work, the stub once more, behind a Throttle that lets two calls run at once, and urn:iki:tutorial:harness:burst, which starts several calls to it at once (Sink a number such as 5).
• urn:throttle:state, the governors’ state in words, and urn:diagram:state, the harness’s arrangement with that state drawn over it: the picture below.

The stack is built like this, innermost first:

/// The harness's root: the governed call, the stub's own space, the board, and the
/// diagram, in that order.
///
/// The stack is the one the chapter draws, innermost first: `Timeout` bounds each invocation
/// of the upstream, `CircuitBreaker` counts the transient failures that come out of it
/// (a timeout among them), and `Retry` re-issues what is worth re-issuing from the run's
/// budget. Only the breaker has state worth showing (`Retry` and `Timeout` hold nothing past
/// one call), so it is the one observed on the board.
pub fn root(
    state: &Arc<HarnessState>,
    clock: &Arc<HarnessClock>,
    board: &StateBoard,
    background: &Arc<Background>,
) -> Arc<dyn Space> {
    let timer = Arc::clone(&background.timer);
    let stub: Arc<dyn Endpoint> = Arc::new(upstream(Arc::clone(state), Arc::clone(&timer)));

    let governed = EndpointSpace::new()
        .bind_arc(Exact::new(CALL), Arc::clone(&stub))
        .named(space_iri("tutorial:harness:governed"));
    let timed = Timeout::new(governed, TIMEOUT).with_timer(timer.clone());
    let breaker = CircuitBreaker::new(timed, THRESHOLD, COOLDOWN)
        .with_clock(Arc::clone(clock) as _)
        .observed(board, GOVERNOR)
        .expect("one governor, named once");
    let retry = Retry::new(breaker, ATTEMPTS)
        .with_timer(timer.clone())
        .with_max_wait(MAX_WAIT);

    // Failover: the stub in a primary space, bounded by the same timeout, else the backup.
    let primary = EndpointSpace::new()
        .bind_arc(Exact::new(SERVICE), Arc::clone(&stub))
        .named(space_iri("tutorial:harness:primary"));
    let spare = EndpointSpace::new()
        .bind(Exact::new(SERVICE), backup())
        .named(space_iri("tutorial:harness:backup"));
    let failover = Failover::new(vec![
        Arc::new(Timeout::new(primary, TIMEOUT).with_timer(timer.clone())) as Arc<dyn Space>,
        Arc::new(spare),
    ])
    .observed(board, FAILOVER)
    .expect("one governor, named once");

    // The bulkhead: the stub again, at most SLOTS calls at once; the rest park.
    let pool = EndpointSpace::new()
        .bind_arc(Exact::new(WORK), Arc::clone(&stub))
        .named(space_iri("tutorial:harness:pool"));
    let bulkhead = Throttle::new(pool)
        .limit(WORK, SLOTS)
        .observed(board, BULKHEAD)
        .expect("one governor, named once");

    let own = EndpointSpace::new()
        .bind(Exact::new(MODE), mode(Arc::clone(state)))
        .bind(
            Exact::new(CLOCK),
            self::clock(Arc::clone(clock), Arc::clone(background)),
        )
        .bind_arc(Exact::new(UPSTREAM), stub)
        .bind(Exact::new(BURST), burst(Arc::clone(background)))
        .named(space_iri("tutorial:harness:upstream"));

    Arc::new(Fallback::new(vec![
        Arc::new(retry) as Arc<dyn Space>,
        Arc::new(failover),
        Arc::new(bulkhead),
        Arc::new(own),
        Arc::new(board.space().named(space_iri("tutorial:harness:board"))),
        Arc::new(ikigai_diagram::space()),
    ]))
}

with these settings: a call may run 2 seconds; the breaker trips after 3 consecutive transient failures and stays open for 5 seconds; Retry waits out a retry after of at most 2 seconds; and the kernel gives every run a retry budget of 2 re-issues in all, whatever Retry’s own attempts would allow:

/// How long `Timeout` lets a call run.
pub const TIMEOUT: Duration = Duration::from_secs(2);
/// How long the upstream takes in `slow` mode: past the timeout's budget.
pub const SLOW: Duration = Duration::from_secs(10);
/// Consecutive transient failures that trip the breaker open.
pub const THRESHOLD: u32 = 3;
/// How long an open circuit refuses before it lets one call through as a probe.
pub const COOLDOWN: Duration = Duration::from_secs(5);
/// The most invocations `Retry` makes of one call: more than the budget allows, so the
/// budget is what stops it.
pub const ATTEMPTS: u32 = 5;
/// The longest `RetryAfter` delay `Retry` waits out; a longer one is returned unchanged.
pub const MAX_WAIT: Duration = Duration::from_secs(2);
/// The delay the upstream asks for in `limited` mode.
pub const LIMITED_DELAY: Duration = Duration::from_secs(1);
/// Re-issues one run may spend in all, across every overlay: the run's retry budget.
pub const RETRY_BUDGET: u32 = 2;
/// How many calls to [`WORK`] the bulkhead lets run at once; the rest park.
pub const SLOTS: usize = 2;
/// The most calls one burst may start.
pub const MAX_BURST: usize = 10;

Why the harness has its own clock. A breaker’s cooldown, a timeout’s budget and a retry’s wait are all time, and on the wall clock this page would answer differently for every reader and for every run of the test that replays it. So the harness clock moves only when you say (“wait 5 seconds”) or when a governor waits, and a governor’s wait is virtual: the earliest wait pending finishes first and moves the clock to its deadline, in no real time. A timeout racing a 10-second call against its 2-second budget fires at 2 seconds, exactly, on every page, and the call it abandoned never finishes. That makes every answer below the same for you as for the chapter.

What the picture draws, and what it cannot. The circuit breaker and the bulkhead appear in the picture as governors, each in the box of the space it governs. That is the transparency property above at work: Retry and Timeout hold nothing past a single call (an attempt count, a deadline), so they have no state to draw, and they report the topology of the space they wrap, so the picture sees through them to the door they govern. Failover is the exception: it encloses two spaces and picks the one that answers only when it is called, and no kind of space says that, so it reports no structure at all, and the picture draws it as an opaque box. Its state, which space the last call ended at, is said in words below the picture with everyone else’s.

The walkthrough, in stages

The walkthrough below is a sequence of stages. A stage is the harness after a step that changed its picture, and each one is a numbered tab. Below the tabs, two pictures sit side by side (stacked on a phone): After is the open tab’s stage, and Before is the stage you compare it with, the one just before unless you pick another from the “Compare with” list above them. Under them is what changed from Before to After, in words (the board’s words, compared line by line: the words that differ are marked, and the line they replaced is said beside them). Below that is the tab’s step: a sentence or two and the cells you run.

Each picture says whose it is. Until you run a tab’s step, its picture is the chapter’s own, in a dashed frame; run it, and After becomes the picture your page drew, in a solid frame. Run the tabs in order: each step starts where the one before left the harness. A step that changes nothing the picture shows makes no stage, and the picture says “no change” instead. Twelve stages: the breaker from every circuit closed to a circuit half-open again, then the failover moving to its backup and back, then the bulkhead filling and draining. (The tabs are the books’ stages viewer, js/stages.js, which knows nothing about governors: the page names the line that draws the picture and the line that says it in words, and the viewer does the rest.)

Watch the governors, not the upstream. The picture draws the governors, not the stub they govern. Setting the stub’s mode changes nothing in the picture: a governor learns of a mode only when a call goes through it. The line above the tabs keeps the facts that change current, each read from the name that holds it after every step: the upstream’s mode (urn:iki:tutorial:harness:mode), the circuit (urn:throttle:state:breaker), the failover’s route (urn:throttle:state:failover), the bulkhead (urn:throttle:state:bulkhead) and the harness time (urn:iki:tutorial:harness:clock).

The picture marks what changed. After every step the page also reads the board as Turtle (urn:throttle:state as=text/turtle) and hands it to the next read of the picture as before= (ikigai-diagram 0.2.4): each key that changed since is marked in the picture, after its state word (OPEN (was CLOSED), (new)), and the words in the picture begin with what changed. The chapter’s pictures are marked against the stage before; the first stage you make yourself is not marked, because the page reads nothing until you take a step.

The buttons are yours. They drive the same harness the cells do. A press that changes the picture adds a stage after the chapter’s, numbered on, and opens it as After, beside the stage the harness was at before the press, so you can compare any two states the harness has been in.

Every picture is drawn once. A stage’s picture is urn:diagram:state, a pure composition of two resources: the harness’s topology and the governors’ board. It is cacheable, and it hangs from what it read: the board hangs from the breaker’s golden thread, urn:throttle:governor:breaker, which the breaker cuts on every change its board shows (a failure counted, a circuit tripped or closed). A cooldown running out cuts nothing; the board’s answer is cached only until it would run out, on the harness clock. So a picture stays true until the state moves. After every step the page asks for it as your own lines would: a step that moved a governor cut its thread, so the picture is drawn again, once; a step that changes nothing cuts nothing, so the page’s read is a cache hit, and the page says so (stage 4 shows one in a trace). Switching tabs, or what you compare with, asks for nothing at all: each tab keeps the picture its step drew. The chapter’s twelve pictures are files the same harness drew natively, held to it byte for byte by a test, so they show before the page’s kernel loads, without it, and in print. Every picture is kept in both the light and the dark colors (scheme=light, scheme=dark), and the page shows the one the book’s theme needs.

throttle state: 3 governors visible
breaker: circuit-breaker, governs urn:iki:space:tutorial:harness:governed, trips after 3, cooldown 5s
bulkhead: throttle, governs urn:iki:space:tutorial:harness:pool
  bulkhead `urn:iki:tutorial:harness:work`: 0 of 2 running, 0 parked
failover: failover over 2 spaces
  candidate 0: governs urn:iki:space:tutorial:harness:primary
  candidate 1: governs urn:iki:space:tutorial:harness:backup

the upstream is now fail
[uncacheable]

error: unavailable: upstream failed (call 3)

throttle state: 3 governors visible
breaker: circuit-breaker, governs urn:iki:space:tutorial:harness:governed, trips after 3, cooldown 5s
  circuit `urn:iki:tutorial:harness:call`: open, 3 consecutive transient failures
bulkhead: throttle, governs urn:iki:space:tutorial:harness:pool
  bulkhead `urn:iki:tutorial:harness:work`: 0 of 2 running, 0 parked
failover: failover over 2 spaces
  candidate 0: governs urn:iki:space:tutorial:harness:primary
  candidate 1: governs urn:iki:space:tutorial:harness:backup

breaker: circuit-breaker, governs urn:iki:space:tutorial:harness:governed, trips after 3, cooldown 5s
  circuit `urn:iki:tutorial:harness:call`: open, 3 consecutive transient failures
[cached]

error: retry after 5000 ms: circuit open for `urn:iki:tutorial:harness:call`

the harness clock moved 5s: it reads 5s
[uncacheable]
breaker: circuit-breaker, governs urn:iki:space:tutorial:harness:governed, trips after 3, cooldown 5s
  circuit `urn:iki:tutorial:harness:call`: half-open, 3 consecutive transient failures
[computed]

throttle state: 3 governors visible
breaker: circuit-breaker, governs urn:iki:space:tutorial:harness:governed, trips after 3, cooldown 5s
  circuit `urn:iki:tutorial:harness:call`: half-open, 3 consecutive transient failures
bulkhead: throttle, governs urn:iki:space:tutorial:harness:pool
  bulkhead `urn:iki:tutorial:harness:work`: 0 of 2 running, 0 parked
failover: failover over 2 spaces
  candidate 0: governs urn:iki:space:tutorial:harness:primary
  candidate 1: governs urn:iki:space:tutorial:harness:backup

the upstream is now ok
[uncacheable]
ok (call 4)
[uncacheable]
breaker: circuit-breaker, governs urn:iki:space:tutorial:harness:governed, trips after 3, cooldown 5s
  circuit `urn:iki:tutorial:harness:call`: closed, 0 consecutive transient failures
[computed]

throttle state: 3 governors visible
breaker: circuit-breaker, governs urn:iki:space:tutorial:harness:governed, trips after 3, cooldown 5s
  circuit `urn:iki:tutorial:harness:call`: closed, 0 consecutive transient failures
bulkhead: throttle, governs urn:iki:space:tutorial:harness:pool
  bulkhead `urn:iki:tutorial:harness:work`: 0 of 2 running, 0 parked
failover: failover over 2 spaces
  candidate 0: governs urn:iki:space:tutorial:harness:primary
  candidate 1: governs urn:iki:space:tutorial:harness:backup

the upstream is now limited
[uncacheable]
trace  urn:iki:tutorial:harness:call
  client      ikigai repl  ·  capability: root (full authority)
  transport   embedded · in-process
 
urn:iki:tutorial:harness:call   upstream · failed · … · 2000ms · failed=retry-after answered-by=urn:iki:space:tutorial:harness:governed
├─ urn:iki:tutorial:harness:mode   harness-mode · computed · … · 0ms · answered-by=urn:iki:space:tutorial:harness:upstream
├─ urn:iki:tutorial:harness:mode   harness-mode · cached · … · 0ms · answered-by=urn:iki:space:tutorial:harness:upstream
└─ urn:iki:tutorial:harness:mode   harness-mode · cached · … · 0ms · answered-by=urn:iki:space:tutorial:harness:upstream
urn:iki:tutorial:harness:call   error: retry after 1000 ms: upstream limited (call 7)

the harness clock reads 7s
[uncacheable]
breaker: circuit-breaker, governs urn:iki:space:tutorial:harness:governed, trips after 3, cooldown 5s
  circuit `urn:iki:tutorial:harness:call`: closed, 0 consecutive transient failures
[cached]
trace  urn:throttle:state
  client      ikigai repl  ·  capability: root (full authority)
  transport   embedded · in-process
 
urn:throttle:state   throttle-state · cached · … · 0ms · answered-by=urn:iki:space:tutorial:harness:board   → …

the upstream is now slow
[uncacheable]
error: timeout: `urn:iki:tutorial:harness:call` exceeded 2000ms

throttle state: 3 governors visible
breaker: circuit-breaker, governs urn:iki:space:tutorial:harness:governed, trips after 3, cooldown 5s
  circuit `urn:iki:tutorial:harness:call`: open, 3 consecutive transient failures
bulkhead: throttle, governs urn:iki:space:tutorial:harness:pool
  bulkhead `urn:iki:tutorial:harness:work`: 0 of 2 running, 0 parked
failover: failover over 2 spaces
  candidate 0: governs urn:iki:space:tutorial:harness:primary
  candidate 1: governs urn:iki:space:tutorial:harness:backup

the harness clock reads 13s
[uncacheable]
breaker: circuit-breaker, governs urn:iki:space:tutorial:harness:governed, trips after 3, cooldown 5s
  circuit `urn:iki:tutorial:harness:call`: open, 3 consecutive transient failures
[cached]

ok, slowly (call 11, after 10s)
[uncacheable]

throttle state: 3 governors visible
breaker: circuit-breaker, governs urn:iki:space:tutorial:harness:governed, trips after 3, cooldown 5s
  circuit `urn:iki:tutorial:harness:call`: half-open, 3 consecutive transient failures
bulkhead: throttle, governs urn:iki:space:tutorial:harness:pool
  bulkhead `urn:iki:tutorial:harness:work`: 0 of 2 running, 0 parked
failover: failover over 2 spaces
  candidate 0: governs urn:iki:space:tutorial:harness:primary
  candidate 1: governs urn:iki:space:tutorial:harness:backup

ok from the backup (backup call 1)
[uncacheable]

throttle state: 3 governors visible
breaker: circuit-breaker, governs urn:iki:space:tutorial:harness:governed, trips after 3, cooldown 5s
  circuit `urn:iki:tutorial:harness:call`: half-open, 3 consecutive transient failures
bulkhead: throttle, governs urn:iki:space:tutorial:harness:pool
  bulkhead `urn:iki:tutorial:harness:work`: 0 of 2 running, 0 parked
failover: failover over 2 spaces
  candidate 0: governs urn:iki:space:tutorial:harness:primary
  candidate 1: governs urn:iki:space:tutorial:harness:backup
  route `urn:iki:tutorial:harness:service`: last call answered at candidate 1

the upstream is now ok
[uncacheable]
ok (call 13)
[uncacheable]

throttle state: 3 governors visible
breaker: circuit-breaker, governs urn:iki:space:tutorial:harness:governed, trips after 3, cooldown 5s
  circuit `urn:iki:tutorial:harness:call`: half-open, 3 consecutive transient failures
bulkhead: throttle, governs urn:iki:space:tutorial:harness:pool
  bulkhead `urn:iki:tutorial:harness:work`: 0 of 2 running, 0 parked
failover: failover over 2 spaces
  candidate 0: governs urn:iki:space:tutorial:harness:primary
  candidate 1: governs urn:iki:space:tutorial:harness:backup
  route `urn:iki:tutorial:harness:service`: last call answered at candidate 0

the upstream is now slow
[uncacheable]
started 5 calls to urn:iki:tutorial:harness:work at once: none answered and 5 calls still in flight
[uncacheable]

throttle state: 3 governors visible
breaker: circuit-breaker, governs urn:iki:space:tutorial:harness:governed, trips after 3, cooldown 5s
  circuit `urn:iki:tutorial:harness:call`: half-open, 3 consecutive transient failures
bulkhead: throttle, governs urn:iki:space:tutorial:harness:pool
  bulkhead `urn:iki:tutorial:harness:work`: 2 of 2 running, 3 parked
failover: failover over 2 spaces
  candidate 0: governs urn:iki:space:tutorial:harness:primary
  candidate 1: governs urn:iki:space:tutorial:harness:backup
  route `urn:iki:tutorial:harness:service`: last call answered at candidate 0

the harness clock moved 10s: it reads 35s; in the background, 2 calls answered and 3 calls still in flight
[uncacheable]

throttle state: 3 governors visible
breaker: circuit-breaker, governs urn:iki:space:tutorial:harness:governed, trips after 3, cooldown 5s
  circuit `urn:iki:tutorial:harness:call`: half-open, 3 consecutive transient failures
bulkhead: throttle, governs urn:iki:space:tutorial:harness:pool
  bulkhead `urn:iki:tutorial:harness:work`: 2 of 2 running, 1 parked
failover: failover over 2 spaces
  candidate 0: governs urn:iki:space:tutorial:harness:primary
  candidate 1: governs urn:iki:space:tutorial:harness:backup
  route `urn:iki:tutorial:harness:service`: last call answered at candidate 0

the harness clock moved 10s: it reads 45s; in the background, 2 calls answered and 1 call still in flight
[uncacheable]

throttle state: 3 governors visible
breaker: circuit-breaker, governs urn:iki:space:tutorial:harness:governed, trips after 3, cooldown 5s
  circuit `urn:iki:tutorial:harness:call`: half-open, 3 consecutive transient failures
bulkhead: throttle, governs urn:iki:space:tutorial:harness:pool
  bulkhead `urn:iki:tutorial:harness:work`: 1 of 2 running, 0 parked
failover: failover over 2 spaces
  candidate 0: governs urn:iki:space:tutorial:harness:primary
  candidate 1: governs urn:iki:space:tutorial:harness:backup
  route `urn:iki:tutorial:harness:service`: last call answered at candidate 0

the harness clock moved 10s: it reads 55s; in the background, 1 call answered and none is in flight
[uncacheable]

throttle state: 3 governors visible
breaker: circuit-breaker, governs urn:iki:space:tutorial:harness:governed, trips after 3, cooldown 5s
  circuit `urn:iki:tutorial:harness:call`: half-open, 3 consecutive transient failures
bulkhead: throttle, governs urn:iki:space:tutorial:harness:pool
  bulkhead `urn:iki:tutorial:harness:work`: 0 of 2 running, 0 parked
failover: failover over 2 spaces
  candidate 0: governs urn:iki:space:tutorial:harness:primary
  candidate 1: governs urn:iki:space:tutorial:harness:backup
  route `urn:iki:tutorial:harness:service`: last call answered at candidate 0

Rate limits are still only described here, by the table above: a RateLimit refuses where a Throttle parks, and the harness does not drive one yet.