The default Fief.Leadership adapter (implementation.md §3, design §6.5): a notify loop campaigning through the Fief.Leadership.Store storage primitives of the instance's StateStore — try_lead/3 (monotonic term issuance, TTL-based like leases) and leader/1. It is generic over any store module implementing that two-callback behaviour; today that is Fief.Authority.Local, at M7 the Postgres adapter's fief_leader row.

One seam-timer cadence with jitter (Fief.Seam) drives everything:

• standby → campaign every campaign_interval (lazy poll, design §6.5);
• leading → renew every renew_interval (ttl ÷ 3 by default).

Notifications to opts[:notify] (pid or registered name):

{:fief_leadership, :elected, term}
{:fief_leadership, :deposed}

Deposition is detected at the next campaign step: {:error, {:held, ...}} (someone else took the expired seat) → :deposed; a fresh, higher term granted to us (our seat expired unnoticed and nobody claimed it) → :deposed then :elected with the new term, so the consumer's planner restarts under the new term rather than writing under a stale one. {:error, :unreachable} changes nothing: leadership gates only term-fenced writes (design §5.1), so the adapter keeps its posture and keeps trying — a genuinely-deposed-while- unreachable planner is fenced at every CAS regardless, and the arbiter-loss posture is the planner's business (on_arbiter_loss).

leader/1 answers from the store, never from adapter state.

Follows THE process discipline: sim bind at init, :handled checkpoint on every path via try/after, no raw timers, stale-timer catch-all.