Generic observation supervisor

The generic Observation Supervisor provides the core coordination mechanism for supervising the consistency of observing states in the presence of asynchronous updates.

It is responsible for controlling when state evaluations occur, independently of how those evaluations are performed or which domain-specific rules are applied.

This component is intentionally domain-agnostic: it contains no CSP-specific knowledge and can be reused in different contexts by combining it with appropriate consistency policies and publication logic.

Purpose

The generic supervisor implements the timing, synchronization, and orchestration logic required to handle observing state updates arriving asynchronously from multiple sources.

Rather than reacting immediately to every update, it introduces a controlled evaluation cycle that balances stability, responsiveness, and completeness.

Its responsibilities include:

  • buffering update notifications,

  • enforcing stability through debouncing,

  • guaranteeing progress through a maximum latency constraint,

  • triggering evaluations at well-defined points in time,

  • interpreting the evaluation outcome returned by the concrete supervisor implementation,

  • deciding whether the current evaluation cycle is complete, should enter a reconciliation phase, or must remain active for a subsequent re-evaluation.

The actual policy semantics, state publication, and domain-specific decision handling are delegated to specialized implementations built on top of this base class.

Debounce, max-latency, and reconciliation

Three complementary mechanisms govern when an evaluation occurs and how long an evaluation cycle may remain active:

  • Debounce interval Updates must remain stable for a minimum time window before evaluation is triggered. This prevents rapid oscillations caused by transient or intermediate subsystem states.

  • Maximum latency Even if updates keep arriving, evaluation is forced after a bounded amount of time since the first pending update. This guarantees timely progress and avoids indefinite postponement.

  • Reconciliation window If an evaluation is inconclusive, the supervisor may open a bounded reconciliation phase. During this phase, the current evaluation cycle remains temporarily active so that delayed subsystem updates can be incorporated before reaching a final conclusion.

The reconciliation window is used to distinguish between a genuinely inconsistent system state and a transient condition in which some subsystem updates have not yet arrived.

Together, these mechanisms ensure that evaluations are both meaningful and timely, while preserving bounded responsiveness in the presence of asynchronous event propagation.

Threading and orchestration

The Supervisor runs a dedicated background thread responsible for managing timing and evaluation scheduling.

The thread remains idle while no updates are pending and wakes up only when:

  • new updates are received,

  • a timing condition such as debounce or maximum latency is satisfied,

  • or a reconciliation timeout expires.

Evaluations are performed outside the internal lock so that update notifications are not blocked while domain-specific logic is executed.

This design minimizes CPU usage while remaining responsive to critical state changes and late subsystem convergence.

Evaluation cycle semantics

The generic supervisor does not interpret subsystem state semantics directly. Instead, it relies on the concrete implementation to evaluate the current snapshot and return an EvaluationOutcome.

This outcome informs the generic loop whether the current cycle should:

  • complete with a final applied state,

  • complete with a fault condition,

  • remain open because more information is still expected,

  • or trigger a refresh/retry path defined by the concrete implementation.

This contract allows the generic loop to remain focused on orchestration while still supporting multi-step and multi-pass evaluation flows.

Extensibility

The generic supervisor defines a clear separation between:

  • coordination and orchestration, handled by the generic supervision loop;

  • decision semantics, handled by the domain-specific policy;

  • decision execution, handled by the concrete supervisor implementation.

Concrete implementations are expected to provide the domain-specific behaviour, such as:

  • evaluating the current system snapshot,

  • applying consistency or validity rules,

  • interpreting policy actions,

  • publishing the resulting observing state,

  • reporting an EvaluationOutcome to the generic loop.

This separation allows the same coordination mechanism to be reused across different components and domains without duplicating timing or concurrency logic, while still supporting richer policy semantics such as explicit waiting, bounded reconciliation, and multi-pass evaluation.