Base observation consistency policy =================================== The base observation consistency policy defines the generic CSP.LMC rules used to evaluate whether the aggregated CSP Subarray ``ObsState`` is consistent with the current subsystem states and with the command currently being supervised. The base policy is not specific to scanning. It provides the common behaviour used by the observation supervisor to detect, classify, and handle inconsistent observation state distributions across all observation states. Scan-specific policies build on top of this base behaviour. They do not replace the base policy; they extend it only where scan-specific semantics are required. Policy inputs ------------- The base policy is evaluated using a consistent snapshot of the supervision state. The inputs normally include: * the candidate aggregated CSP Subarray ``ObsState``; * the previous or currently published CSP Subarray ``ObsState``; * the subsystem ``ObsState`` snapshot; * the active command context, when available; * the command semantics stored in the command context; * the active observing modes; * policy configuration parameters, such as thresholds and hard-fault behaviour. The command context is optional from a structural point of view, but it becomes semantically important whenever the consistency decision depends on the command that is currently running or whose effects are still being observed. Generic behaviour ----------------- The base policy defines the default behaviour for CSP observation consistency. During each evaluation cycle, the policy determines whether the candidate aggregated state can be applied directly, whether the system should wait for a more conclusive state distribution, whether subsystem information should be refreshed and re-evaluated, or whether the inconsistency must be treated as a fault. The base policy is responsible for: * detecting inconsistent subsystem state distributions; * distinguishing transient transitions from stable inconsistencies; * applying configured thresholds when required; * producing diagnostic information; * selecting the policy action to be executed by the observation supervisor. This behaviour is shared by specialised policies. A specialised policy should reuse the base consistency behaviour and override only the parts of the decision that require domain-specific semantics. Policy decision --------------- The result of a consistency evaluation is a policy decision. A decision contains: * the final CSP Subarray ``ObsState`` to apply, when applicable; * the selected policy action; * whether the inconsistency is a hard fault; * a diagnostic message; * a severity level. The policy action makes the control-flow intent explicit. The supervisor does not infer the next action only from severity or from the final state. Policy actions -------------- The base policy can return the following actions. ``APPLY`` The final observation state can be applied to the CSP Subarray observation model. Diagnostic attributes are updated accordingly, and the evaluation cycle completes successfully. ``WAIT`` No final state is applied yet. The state distribution is not considered conclusive, and the supervisor keeps the evaluation cycle pending so that the generic supervision loop can trigger a new evaluation later. ``FAULT`` The inconsistency is non-recoverable. The supervisor transitions the CSP Subarray into ``FAULT`` and reports the associated diagnostic information. ``REFRESH_AND_REEVALUATE`` No final state is applied yet. The supervisor refreshes subsystem information and performs a new policy evaluation using the refreshed snapshot. This action is used when the current state is not conclusive, but an additional refresh may provide enough information to reach a final decision. Severity levels --------------- The base policy classifies inconsistencies using severity levels. ``LOW`` The inconsistency is recoverable, transient, or diagnostic only. If the selected action is ``APPLY``, the final state can still be applied. ``MEDIUM`` The inconsistency represents a degraded but potentially valid condition. The selected action determines whether the degraded state can be applied immediately or whether the evaluation should remain pending. ``HIGH`` The inconsistency is considered non-recoverable and normally results in a ``FAULT`` action. Severity describes the impact of the inconsistency. It does not by itself define the control flow. The control flow is defined by the selected policy action. Interaction with the observation supervisor ------------------------------------------- The ``CspObservationSupervisor`` applies the policy decision to the CSP Subarray observation model. For each evaluation cycle, the supervisor: * takes an atomic snapshot of subsystem ``ObsState`` values from the state store; * computes the candidate aggregated ``ObsState`` through the observation model; * selects the active command context, when available; * evaluates the consistency policy; * updates diagnostic attributes; * executes the returned policy action; * returns an evaluation outcome to the generic supervision loop. The supervisor is responsible for applying the decision. The policy is responsible for classifying the state distribution and expressing the intended action. Consistency faults ------------------ If the policy returns a ``FAULT`` action, the supervisor latches the CSP Subarray into ``FAULT`` with cause ``CONSISTENCY``. This condition is reported through the scan or observation consistency diagnostic attributes, depending on the policy being evaluated. A consistency fault is cleared only when the inconsistency is no longer present and the current fault cause is ``CONSISTENCY``. Relationship with specialised policies -------------------------------------- Specialised policies reuse the base consistency policy to preserve the default CSP.LMC observation behaviour. For example, the scan consistency policy uses the base policy to preserve the standard inconsistency handling model, but adds scan-specific rules for ``SCANNING``. The scheduled scan policy further specialises scan handling to support the pending phase between ``Scan`` command completion and actual scan execution. This layered model avoids introducing separate and incompatible consistency models for different observation phases.