Context
Bering should own the canonical runtime liveness/degradation contract. Sheaft and mb3r-stack should consume and validate this contract instead of inventing their own status model.
Failure detector motivation
This work is explicitly motivated by failure detector theory, but it should be implemented as practical runtime semantics rather than an academic subsystem. The important idea is that absence of a response is an observation with uncertainty, not immediate proof of failure.
The contract should preserve ideas such as eventual accuracy/completeness, accrual-style suspicion, stale observations, monotonic observation handling, and recovery convergence. This keeps downstream systems from collapsing suspect, stale, unknown, and unreachable into one generic failure state.
Scope
- Define canonical component status values:
healthy, degraded, suspect, unreachable, stale, unknown.
- Add or extend the health observation contract/schema with fields such as
component, status, observed_at, last_seen_at, latency_ms, missed_heartbeats, suspicion, and reason.
- Specify timeout/suspicion policy without treating every timeout as a hard failure.
- Keep
unknown distinct from failed/unreachable.
- Define monotonic handling for observations so stale reports cannot overwrite newer reports.
- Consider leases/epochs where needed to avoid accepting old runtime claims after recovery or restart.
- Add fixtures/tests for delay, missed heartbeat, stale report, recovery, and out-of-order observation cases.
Definition of done
- The Bering contract/schema documents the status model and required/optional fields.
- Tests cover normal, degraded, suspect, stale, unreachable, unknown, and recovery paths.
- Docs explicitly mention the failure detector motivation and explain the runtime semantics in practical terms.
- Downstream work in Sheaft can consume this contract directly.
Context
Bering should own the canonical runtime liveness/degradation contract. Sheaft and mb3r-stack should consume and validate this contract instead of inventing their own status model.
Failure detector motivation
This work is explicitly motivated by failure detector theory, but it should be implemented as practical runtime semantics rather than an academic subsystem. The important idea is that absence of a response is an observation with uncertainty, not immediate proof of failure.
The contract should preserve ideas such as eventual accuracy/completeness, accrual-style suspicion, stale observations, monotonic observation handling, and recovery convergence. This keeps downstream systems from collapsing
suspect,stale,unknown, andunreachableinto one generic failure state.Scope
healthy,degraded,suspect,unreachable,stale,unknown.component,status,observed_at,last_seen_at,latency_ms,missed_heartbeats,suspicion, andreason.unknowndistinct fromfailed/unreachable.Definition of done