Back to overview →
Module 01 / 04

Mission → Function → Service → Resource.

The hierarchy survives the research revision. The key change is at the resource level: a resource is anything whose condition limits the ability to realise a function — including models and algorithms.

Four abstraction levels

Mission → Function → Service → Resource.

The hierarchy survives the research revision. The key change is at the resource level: a resource is anything whose condition limits the ability to realise a function — including models and algorithms.

Mission layerPriorities, horizon and minimum acceptable mission outcome.
Function layerRequired functions, degraded variants and mission contribution.
Service layerRuntime implementations, mappings, software/platform services and communication paths.
Resource layerPhysical resources + epistemic resources with health / validity \(\boldsymbol\rho(t)\).
Four-level abstraction hierarchy used by Væringjar II

The hierarchy remains a structural backbone. The current model extends its resource layer and adds transition admissibility and timing outside the hierarchy itself.

The supervisor does not observe hardware alone.Open section
Extended runtime state

The supervisor does not observe hardware alone.

\[ Z(t)=\langle x(t),\boldsymbol\rho(t),cfg(t),\boldsymbol\alpha(t)\rangle, \qquad \mathcal R=\mathcal R_{phys}\cup\mathcal R_{epist}. \] Dynamic state · resource health/validity · active configuration · mission priorities.

An estimator or learned model whose predictions no longer agree with observations is represented as a degraded epistemic resource. This allows physical faults and loss of model adequacy to enter the same capability calculation.