Architecture

1. Architectural Principles

The design of HOSA is governed by five non-negotiable principles. These are not aspirational guidelines — they are hard constraints that every design decision must satisfy.

2. The Perceptive-Motor Cycle

HOSA operates in a continuous cycle with three functional layers, inspired by the biological separation between sensory system, nervous system, and motor system. These layers map directly to the reflex arc pattern described in §1 — Core Concepts.

3. Warm-Up and Proprioceptive Calibration

Upon starting, HOSA executes a calibration phase termed Hardware Proprioception — a term borrowed from the biological sense by which an organism perceives its own body configuration. During this phase, HOSA learns both the hardware topology and the behavioral baseline of the node.

1. Topological discovery. Via reading /sys/devices/system/node/ and /sys/devices/system/cpu/, the agent identifies NUMA topology, physical and logical core count, L1/L2/L3 cache sizes, and memory configuration.
2. State vector definition. Based on topology, HOSA determines which variables to include in x(t) and their respective eBPF sources. A single-socket server with NVMe storage produces a different vector than a dual-socket machine with spinning disks.
3. Baseline accumulation. During a configurable period (default: 5 minutes), the agent collects samples without executing mitigation, accumulating the initial μ₀ and Σ₀ via Welford incremental updates. This is the node's baseline profile.
4. EWMA calibration. The smoothing factor α is calibrated for each resource based on the variance observed during warm-up. Higher-variance signals receive lower α (more smoothing) to prevent false derivatives.
5. Adaptive threshold definition. The thresholds θ₁ through θ₄ for each response level are calculated as multiples of the standard deviation observed in the baseline regime (e.g., Level 1 = 2σ, Level 3 = 4σ).

After warm-up, μ and Σ continue to be updated incrementally, allowing the baseline profile to evolve with legitimate workload changes (see §5 — Habituation).

4. Graduated Response System

The graduated response is one of HOSA's most critical architectural decisions. Rather than implementing a binary switch (healthy → kill), the system defines a spectrum of six proportional response levels, each with specific activation conditions, actions, and reversibility guarantees.

5. Habituation — Adapting to the New Baseline

A recurring problem in anomaly detection systems is chronic false positives: when the legitimate workload changes permanently (e.g., deployment of a new application version that consumes more memory), the detector continues signaling anomaly indefinitely.

HOSA implements a habituation mechanism inspired by neuroplasticity:

1. If D_M remains elevated but stable (derivative near zero) for a configurable period without any real failure (no OOM, no timeout, no process crash);
2. And the covariance structure is preserved (the deformation ratio ρ(t) is below threshold — resources still correlate in the same proportions, just at higher magnitude);
3. And no indicators of compromise are present (syscall entropy ΔH and propagation index ICP below thresholds);
4. Then HOSA recalibrates μ and Σ with increasing weight on recent samples, effectively shifting the baseline profile to the new operational regime.

This is implemented via exponential decay of weights in the Welford algorithm, assigning lower influence to older samples and allowing Σ to reflect the contemporary covariance of the system.

6. Selectivity Policy — The Throttling Problem

While throttling via cgroups is an effective mitigation against resource exhaustion, it introduces secondary risks that must be explicitly addressed:

• Cascading timeouts. A throttled HTTP backend can cause connection accumulation upstream, propagating degradation to healthy services.
• Transaction deadlocks. A process throttled during a database transaction may hold locks indefinitely, blocking other processes.
• Critical component starvation. If the Kubernetes kubelet is throttled, the node is marked NotReady and all pods are evacuated — potentially causing more damage than the original problem.

HOSA addresses these risks through a safelist — a protected list of processes and cgroups that are never targets of throttling:

• Kernel processes (kthreadd, ksoftirqd, etc.)
• The HOSA agent itself
• Orchestration agents (kubelet, containerd, dockerd) when detected
• Processes explicitly marked by the operator via configuration or cgroup label

Throttling is applied preferentially to the processes identified as greatest contributors to the anomaly, determined by the decomposition of x(t) — the processes whose resource consumption most contributes to the dimensions where D_M diverges from baseline. This dimensional contribution analysis (c_j decomposition) is documented in §3 — Math Model.

7. Project Structure

The codebase follows a layered organization that mirrors the biological metaphor:

hosa/
├── cmd/hosa/
│   └── main.go                # Entry point — agent initialization
├── internal/
│   ├── sysbpf/
│   │   └── syscall.go         # Custom eBPF loader via native syscalls
│   ├── linalg/
│   │   └── matrix.go          # Linear algebra (matrices, inversion, covariance)
│   ├── syscgroup/
│   │   └── file_edit.go       # Direct cgroup file manipulation via VFS
│   ├── bpf/
│   │   ├── sensors.c          # eBPF C code injected into the kernel
│   │   └── bpf_bpfeb.go       # Auto-generated Go↔C bridge (cilium/ebpf)
│   ├── sensor/                # ── The Sensory System
│   │   └── collector.go       # Reads eBPF maps → state vector x(t)
│   ├── brain/                 # ── The Predictive Cortex
│   │   ├── matrix.go          # Covariance matrix management (Welford)
│   │   ├── mahalanobis.go     # D_M calculation
│   │   └── predictor.go       # EWMA, derivatives, level determination
│   ├── motor/                 # ── The Reflex Arc (Actuators)
│   │   ├── cgroups.go         # Process throttling via cgroups v2
│   │   └── signals.go         # Process signaling (SIGSTOP/SIGCONT)
│   └── state/                 # ── The Limbic System
│       └── memory.go          # Short-term ring buffer for baseline
├── docs/
│   ├── whitepaper.pdf         # Full academic whitepaper v2.1
│   └── *.html                 # Documentation pages
└── Makefile                   # make build → compiles eBPF C + Go

The naming convention deliberately uses biological terms (brain/, sensor/, motor/, state/) to maintain the conceptual mapping between architecture and metaphor throughout the codebase.

8. Key Design Decisions

9. Self-Protection Mechanisms

A legitimate concern for any autonomous agent running with kernel privileges is: can the agent itself become the cause of the problem? HOSA addresses this through multiple layers of self-protection:

1. Self-contained footprint. HOSA operates within its own cgroup v2 with hard limits on memory.max and cpu.max. If the agent exceeds its own limits, the kernel constrains it before it affects the system.
2. Safelist self-inclusion. HOSA is the first entry in its own safelist — it never throttles itself. Kernel processes and orchestration agents are also protected by default.
3. Reversible mitigation. Levels 0–4 are automatically reversible. No destructive action (process kill, interface deactivation) is executed below Level 5.
4. Escalation hysteresis. Level transitions require sustained conditions, preventing oscillation. The agent cannot jump from Level 0 to Level 4 in a single cycle.
5. Dry-run mode. The agent can be executed in observation mode (logging and decision calculation without action execution), allowing validation of decision quality before enabling actuation.
6. Deterministic compilation. The binary is compiled statically with no dynamic dependencies. No risk of failure due to absent or incompatible shared libraries.
7. eBPF verifier as safety net. All eBPF programs are validated by the kernel's eBPF verifier before loading. A bug in the eBPF C code causes the program to be rejected at load time (fail-safe), not at runtime.

10. References

1. Welford, B. P. (1962). Note on a Method for Calculating Corrected Sums of Squares and Products. Technometrics, 4(3), 419–420.
2. Hadamard, J. (1902). Sur les problèmes aux dérivées partielles et leur signification physique. Princeton University Bulletin, 13, 49–52.
3. Heo, T. (2015). Control Group v2. Linux Kernel Documentation. kernel.org
4. Gregg, B. (2019). BPF Performance Tools: Linux System and Application Observability. Addison-Wesley Professional.
5. Vieira, M. A., et al. (2020). Fast Packet Processing with eBPF and XDP: Concepts, Code, Challenges, and Applications. ACM Computing Surveys, 53(1), Article 16.
6. Horn, P. (2001). Autonomic Computing: IBM's Perspective on the State of Information Technology. IBM Corporation.
7. Hellerstein, J. L., Diao, Y., Parekh, S., & Tilbury, D. M. (2004). Feedback Control of Computing Systems. John Wiley & Sons.