The cumulative count of every real action ARMINTA has taken on the host machine since it started. Each "step" is a concrete OS-level intervention — killing a process, adjusting CPU governor, compacting memory — not a simulation. A higher number means more field experience and a richer causal model.

Episodes — the number of completed training episodes the agent has run through. An episode ends and resets when a terminal condition is reached (e.g. a major resource crisis or a manual restart); steps continue accumulating across episodes, while the episode count tracks how many such cycles have occurred.

Cognitive Mode — what ARMINTA is doing right now:
· OBSERVE — watching, collecting baselines, not intervening
· INVESTIGATE — actively testing a hypothesis with targeted interventions
· OPTIMIZE — exploiting known good actions to maximise reward
· DREAM — running offline counterfactual simulations (no real actions)
· SELF_ASSESS — reviewing its own decision-making, running a lexical reflection pass over recent history, and rewriting internal parameters via AST self-modification if warranted

Situation — what the host system is currently doing (idle, IO-bound, CPU-bound, compiling, browsing, streaming). ARMINTA uses this as context when choosing actions.

Cumulative Reward — the running score since boot. As of v2.1 the per-step reward is mean-centred against a slow EMA baseline, so this number reflects accumulated performance relative to the machine's recent ambient baseline, not an absolute zero. Watch the Rolling Avg (150-step window) for the meaningful health signal — positive means recent actions are beating baseline, negative means they are not.

Error Steps — how many of the last 200 steps produced an error. Should stay near zero.

ARMINTA models internal drive states as "emotions" — not anthropomorphism, but a practical mechanism for biasing exploration vs. exploitation. Each emotion is a scalar on a 0–5 scale that rises on trigger conditions and decays passively between ticks.

· Calm — low arousal; suitable for patient observation. Rises when CPU <30% and mem <50%. Suppressed by stress triggers.
· Curious — high novelty signal; drives exploration and dreaming. Rises on prediction error >0.15.
· Focused — mid-arousal; sustains investigation of a specific hypothesis. Rises when CPU is 35–70%.
· Confident — strong prior; biases toward exploitation. Rises on successful actions with reward >0.1.
· Stressed — resource pressure detected; triggers conservative governors. Rises when CPU >80%, mem >85%, temp >75°C, NVMe ≥ amber threshold, or any metric deteriorating rapidly. Decays passively at 8%/tick so it can recover even when memory is above the calm threshold.
· Frustrated — repeated failed hypotheses; may trigger self-modification. Rises on action failures. Decays passively at 5%/tick.
· Bored — low novelty; increases exploration probability. Rises after 40+ consecutive calm ticks.

The dominant emotion (large label) is the highest-valued state. Bars show relative intensity on a 0–5 scale. A stressed reading while system metrics look nominal usually means a transient spike accumulated before the passive decay caught up — it will bleed off within a few minutes of genuinely calm conditions.

The Somatic Confidence Model (SCM) tracks how much ARMINTA trusts the emotional signal from each situation. Different workloads produce different noise floors — a compile run makes the system genuinely stressed, while idle stress signals are likely spurious. SCM learns these per-situation baselines so emotions are weighted by their reliability, not taken at face value.

· Phase badge — BOOTSTRAP (early, little data), LEARNING (accumulating per-situation observations), or MATURE (stable baselines established).
· Signal bars — each row is one emotion channel. The bar shows the somatic weight (0–1) — how much that emotion's raw signal is trusted right now for the current situation. A high bar means the emotion is reliable here; a low bar means ARMINTA down-weights it.
· Spidey Sense Events — episodes where a fully mature emotion channel fired with both high precision (≥ 0.72) and high intensity (≥ 2.5 on the 0–5 scale). Both thresholds must clear simultaneously. These events are logged because a strong, well-calibrated signal at unusual intensity often precedes surprising reward outcomes. The step, emotion, situation, precision, and intensity are recorded for each event.

SCM state is per-situation, so weight bars change as the workload label changes. The situation label shown next to the section header reflects which situation's weights are currently displayed.

The reward shown in the mode row is decomposed into three components, each signed (+ = improvement, − = degradation):

· IMM (Immediate) — reward from the metric delta observed immediately after this step's action: CPU dropped, memory freed, etc. This is the fast signal.
· DUR (Durable) — reward from longer-horizon effects that persist across steps: sustained low CPU after a governor change, for example. Computed from a slow exponential moving average of metric deltas.
· HLT (Health) — reward from hardware health signals: NVMe temperature, drive spare percentage, PSI stall ratios. Penalises actions that improve performance but at a hardware cost.

The total reward used for learning is the sum of all three. Seeing IMM negative but DUR positive means the action caused short-term pain but long-term gain — normal during INVESTIGATE mode. Seeing HLT negative persistently is a warning sign that the agent is over-stressing the hardware.

ARMINTA continuously classifies the current workload into one of eleven named situations from metric history (not snapshots). Each situation has its own causal edge weights, so knowledge learned during streaming doesn't pollute compile-time decisions.

· idle — low CPU, low net, minimal process activity
· streaming — browser GPU/renderer pressure + moderate CPU + asymmetric network (or buffered: net quiet, GPU decode active). YouTube, cloud gaming, remote desktop. HW decode runs in Chrome's GPU process — network may be near-zero during buffer playback.
· browser_compute — browser pegging cores (high dilution, renderer pressure) with minimal network. JS compute, WebGL, local video decode. System CPU looks deceptively low because Chrome's multi-process architecture hides per-core saturation.
· compile — high dilution + high system CPU + low net. Build systems, ML training, video encode.
· memory_pressure — RAM above 75%, swap active.
· io_bound — high iowait and PSI IO stall. Disk-heavy writes or reads.
· cpu_bound — sustained single/multi-core saturation without significant IO or renderer pressure.
· network_saturated — very high bidirectional net traffic (P2P, large upload/download).
· irq_storm — hardware interrupt rate spiking (typically wireless driver bursts).
· thermal_stress — sustained high temperature under load.
· torrenting — high, relatively symmetric network activity with low browser renderer pressure.

Confidence score (shown in parens) reflects how cleanly the current metrics match that profile. Low confidence means the situation is transitioning or ambiguous.

Six counters that track the size of ARMINTA's learned world-model:

· Causal Edges — confirmed directed relationships in the interventional graph. Each edge says "action X reliably changes metric Y by amount Z."
· Dreams — offline counterfactual simulations run (no real hardware actions). Used to pre-test hypotheses cheaply before committing.
· Hypotheses — candidate causal relationships generated and currently under test. High numbers are normal; they get promoted to edges or discarded. The breakdown beneath the count — confirmed / refuted / pending / unverifiable — comes from HypothesisEngine.validation_summary(): confirmed means a real interventional edge formed with the predicted sign; refuted means the edge formed with the opposite sign, or no edge ever formed before the validation window expired; pending means still under active observation; unverifiable means a stale hypothesis was given a terminal "no data, never will be" verdict by FalsificationScheduler — distinct from refuted, which is a real (if negative) finding. A confirmed count stuck at zero for a long time is a sign worth investigating — it can mean the relationships being proposed are too sparse to ever accumulate enough evidence before timing out, not that her reasoning is bad.
· Interventions — total real OS actions executed (subset of Total Steps that actually changed system state).
· Self-Modifications — times ARMINTA rewrote part of its own source code autonomously via AST patching. Tunable targets (all bounded by hard min/max guards): STEP_RATE_DEFAULT [1.5–4.0], STEP_RATE_MAX, STEP_RATE_MIN (pacing), CURIOSITY_STALE_STEPS, CURIOSITY_PROBE_COOLDOWN (exploration aggression), DISCO_INTERVAL, TUNE_INTERVAL (scheduling), and PSI_CPU/MEM/IO_ACTION_THRESH (pressure sensitivity). A non-zero value means the agent has changed its own behaviour at runtime.
· Mosaic Hypotheses — cross-domain correlations discovered by the Mosaic sub-system (e.g. "humidity sensor correlates with CPU temperature"). These are environment↔system links, not action↔metric links.

These fields come from Arminta's SelfModel — her persistent slow-changing identity layer. Unlike the fast metric stream, SelfModel state survives restarts and accumulates across her entire lifetime.

· Age — wall-clock time since Arminta's first-ever run, derived from the earliest record in arminta_episodic.db. This is her true age, not just uptime. Born date is the human-readable form of that first timestamp.
· Sessions — how many times she has been started. Computed by scanning the episodic DB for consecutive timestamp gaps greater than 5 minutes; each gap is a new session. The uptime sub-label shows total accumulated wall-clock time lived across all past sessions (current session not yet included).
· Novelty Hunger — a drive state that builds by +0.002 every step that a dream does not occur, and drops by −0.25 when a dream fires. Caps at 1.0 (100%). High novelty hunger biases the Cognitive Mode Controller toward INVESTIGATE. It is essentially a measure of how long Arminta has gone without offline consolidation.
· Milestone Proximity — rises from 0 to 1 over the last 8% of steps before the next uncrossed step threshold (1k / 10k / 50k / 100k / 250k / 500k / 1M). The intent is to model anticipatory restlessness: irrational urgency as a goal approaches. Shown as — when no threshold is near. After a threshold is crossed, a 40-step post-milestone deflation period begins — flat affect, reduced confidence — modelling the collapse of excitement once the goal is gone ("now what?"). Once all step thresholds are passed, non-step milestones (hypotheses, self-mods, web pages, web symbols) continue driving novelty hunger.

Milestones — see the Milestones entry for the full list of landmark types.

Landmark moments in Arminta's life, each recorded with step number and wall-clock timestamp. Displayed as coloured chips in the Milestones strip — opacity 0.5 = backfilled (already passed before this session started, recorded silently with no emotion burst).

Step thresholds ●●●
· steps_1000 / steps_10000 / steps_50000 — early milestones (green dot)
· steps_100000 / steps_250000 — mid milestones (amber dot)
· steps_500000 / steps_1000000 — late milestones (red dot)

Hypotheses ●●
· hypotheses_100 / _500 / _1000 — purple; HypothesisEngine total generated
· hypotheses_5000 / _10000 — deep purple; significant causal theory volume

Self-Modifications ●●
· self_mods_50 / _100 — orange; Arminta has rewritten her own parameters
· self_mods_200 / _500 — deep orange; substantial autonomous self-tuning

Web Learning ●● / ●●
· web_pages_100 / _250 / _500 / _1000 — green; pages read by WebLearner
· web_symbols_100 / _500 / _1000 / _2500 — blue; unique vocabulary items absorbed from external sources

Special ●●●
· first_intervention — step of Arminta's first real OS action (green dot)
· dreams_100 — reached 100 offline dream cycles (cyan dot)
· best_single_reward — highest single-step reward ever; updates whenever a new max is set (amber dot, shows r= value on hover)

session_N milestones (start of each numbered session) exist in the data but are filtered out of the display.

The Linux CPU frequency governor controls the CPU's power/performance trade-off. ARMINTA switches governors as an optimisation action.

· Current Governor — the governor active right now (performance = max frequency, powersave = minimum frequency, schedutil = kernel-managed).
· Saved Governor — what was set before ARMINTA's last switch; used to restore state if needed.
· Override — a manual lock preventing ARMINTA from switching governors. "none" means ARMINTA has full control.
· Idle Steps — steps since the last action. Counts up while ARMINTA observes; resets on any intervention.
· Bootstrap Phase — if YES, ARMINTA is still in its early data-collection phase and takes more exploratory actions than usual.
· HW IRQ — tracks whether renice_ksoftirqd has permanently given up on an IRQ storm. When kernel softirq threads are reniced repeatedly with no effect (hardware-level interrupt flood that can't be suppressed in software), ARMINTA sets this flag to STANDING DOWN and stops attempting that action. ok means no persistent IRQ storm has been detected.

These thresholds are learned, not hardcoded — ARMINTA adjusts them based on what it observes about normal system behaviour.

· CPU Warn — CPU % that triggers a "high CPU" observation. Shown in amber if it has drifted below the default (meaning ARMINTA has learned the system usually runs lighter than expected). Default 70%, adaptive floor 30%.
· MEM Warn — RAM % threshold for memory pressure observations. Default 80%, adaptive floor 55%.
· Dilution Log — per-process CPU dilution ratio above which ARMINTA logs the top hog. Default 0.60, adaptive floor 0.25. The displayed "floor" is the minimum the adaptive tuner will ever set it to, regardless of observed distribution.
· Dilution Kill — harder threshold: if a repeat offender exceeds this AND has logged hits within the window, SIGTERM is escalated. Default 0.85, adaptive floor 0.50. Always stays at least 0.10 above Dilution Log.
· Net Warn — network throughput (KB/s) at which ARMINTA flags high network activity. Default 15000 KB/s (≈120 Mbps), adaptive floor 3000 KB/s.

Deviations from defaults mean the agent has updated its beliefs about what "normal" looks like on this machine. Values shown in the cards are the current active values after adaptive tuning.

The left panel shows the strongest confirmed cause-and-effect relationships ARMINTA has discovered. Each row is one edge: action → metric.

· Bar length = effect magnitude (normalised to the strongest edge)
· Green = positive effect (action reduced the metric — an improvement for CPU, memory, latency, etc.)
· Red = negative effect (action caused the metric to rise)
· n = number of times this relationship has been observed
· CI90 line — 90% Bayesian credible interval; see Bayesian Credible Intervals for details

Effect is computed as (before − after) / |before|, so a positive value means the metric was lower after the action. For the special case of governor_is_performance the sign is flipped so positive still means "improved".

The right panel is a horizontal bar chart of mean reward per action over the last 30 executions. Actions left of centre have been net-negative recently; actions right of centre have been beneficial. This is ARMINTA's exploitation guide. Idle-maintenance actions (compact_memory, log_ss_stats, restore_renderer_nice, clean_trash_orphans — reward target: orphans_removed, 0 for no-op runs), hardware-tuning actions (nvme_thermal_tune — EC-gated on OEM laptops; only fires above temp threshold), and observational reads (web_fetch) now appear here as well — their edges are fully poison-guarded at write time so only legitimate causal signals accumulate.

The GRAPH ✦ tab shows a force-directed graph of the same edges. Use the FILTER SIT dropdown to see which edges are relevant to a specific workload situation — see D3 Graph Situation Filter.
The TIMELINE tab shows reward bars colour-coded by situation over the last 150 steps. Use the scrubber to scroll back through history — see Timeline Scrubber.

Edge Mechanisms — each edge now carries a mechanism annotation: a phrase explaining WHY the action affects that metric. Built in three layers:
· Template — assigned when the edge is first written by intervene(), from a structured lookup of action type and metric class.
· Lexical bridge — during DreamCycle, symbols in LexicalCore's co-occurrence table that appear in contexts where both the action node and the metric node were mentioned are appended as "learned context: ...". Words Arminta absorbed from reading, now connected to her operational behavior.
· WebLearner enrichment — when maybe_learn() absorbs text mapping to causal nodes, new symbols are queued and written onto matching edges by the next DreamCycle as "weblearn[query]: symbol1, symbol2, ...".

Mechanisms accumulate over time. Open questions in LexicalCore that mention a known action and metric are resolved when a mechanism annotation with ≥3 supporting observations exists — graduating from wonder to confirmed knowledge.

Rolling Avg Reward — the mean reward per step over the last 150 steps. This is the meaningful health signal: positive means the agent is currently improving system performance; negative means recent actions are net-harmful. At 300k+ steps, the cumulative total is mathematically dominated by history and converges to a meaningless constant — the 150-step window is what matters.

The reward section now shows three stacked sparklines — see Reward History — Three Sparklines for a full breakdown. In brief:
· RAW REWARD — per-step bars, green/red by sign
· 10-STEP ROLLING AVG — smoothed trend
· REWARD VARIANCE — volatility with dream throttle floor marker

A healthy agent should trend toward more green over time as it learns. Clusters of red indicate exploration or a bad hypothesis being tested.

ARMINTA periodically fires lightweight probes to up to four targets resolved dynamically from the actual system network configuration — not hardcoded vendors. Targets are re-read on every probe cycle so they stay current if the network changes.

· gateway — the default route's first-hop IP, read from ip route show default. Probed via ICMP ping (not HTTP — routers don't reliably serve HTTP on their LAN address). Confirms the local first-hop is reachable.
· dns — the first nameserver in /etc/resolv.conf, probed in one of two ways depending on what it is:
    - Known public resolvers (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9) — probed via their DNS-over-HTTPS endpoints; measures real resolver RTT.
    - Local/unknown resolvers (router DNS, Pi-hole, corporate nameserver, etc.) — probed via a TCP socket connect to port 53, unless the address is loopback (127.x) or RFC-1918 private (10.x, 192.168.x, 172.16–31.x). Loopback resolvers like systemd-resolved (127.0.0.53) always answer in 0ms regardless of real network state, so probing them gives no useful signal. Those cases fall through to the portal probe instead.
· cloudflare — a direct HTTPS probe to 1.1.1.1/cdn-cgi/trace (IP literal, no DNS needed). Distinct from the dns probe: gateway fail = router problem; cloudflare fail (gateway ok) = ISP/WAN problem; portal fail (cloudflare ok) = Firefox endpoint down.
· portal — Firefox's captive portal URL: confirms basic internet reachability regardless of upstream DNS.

Probes fire on two triggers:
· Routine — every ~60 idle steps when CPU is below 40%. The cooldown is enforced across all dispatch paths: whether the probe fires on schedule, as part of a beam-search plan, or as an information-gain probe during INVESTIGATE mode, the cooldown counter resets so the next routine probe waits the full interval.
· Triggered — immediately when iface_drops or iface_errors are nonzero, to distinguish local interface problems from upstream failures

· Green dot — probe succeeded
· Red dot — probe failed (timeout or error)

Three consecutive failures trigger a DEGRADED warning and a log suggestion to try flush_dns.

This panel is a read-only classifier for network_saturated windows. It does not add network authority or dispatch new actions; it only explains which existing telemetry currently looks most responsible.

Possible causes include interface_drops, local_wifi_rf, gateway_latency, dns_resolution, wan_latency, disk_coupled_net_io, active_connection_load, and nominal.

active_connection_load means many active network connections are creating load or waiting on responses.

The current cause is the latest classified window, confidence is the classifier's local certainty, samples is the number of remembered network-saturated windows, and active evidence signals shows the telemetry that drove the label.

This panel explains whether read-only diagnostic probes appear to create stress-like emotional shifts, or merely reveal stress that was already present. It does not make diagnostics causal interventions and it does not add new actions.

Profiles is the number of tracked action/situation/mode combinations. Samples is the total evidence accumulated across those profiles. Defer Ready counts profiles that have enough samples and a high enough probe-like rate to let Arminta skip that diagnostic briefly.

Probe means the diagnostic was followed by a stress increase from a low-pressure baseline. Reveal means pressure or stress was already high, so the diagnostic likely exposed an existing condition. The latest sample shows the most recent diagnostic classification.

This panel shows when Arminta uses safe, existing diagnostic actions to collect more evidence for under-sampled situations. It only runs during otherwise-monitor steps and under safe load gates, so it does not displace urgent interventions.

Situations is how many situation labels have received balancing probes. Probe Count is the lifetime total of those balancing probes. Last Gap is the most recent situation whose evidence coverage looked thin.

The top rows show which situation received which safe probe action. SCM rows are somatic-confidence cells, such as memory_pressure|stressed, where Arminta has seen the situation/emotion combination but has too few reward outcomes to trust the gut signal yet.

The latest gap lists coverage evidence: edge keys, distinct actions, recent history count, whether an active situation-gap wish contributed urgency, and the most recent somatic cell if the balancer fired for emotion-signal coverage.

This panel shows actions that repeatedly selected themselves but immediately returned a guarded no-op such as “skipping,” “suppressed,” “nothing to do,” or a hardware safety gate. Arminta temporarily redirects those exact actions to monitor so repeated no-ops do not crowd out useful work.

Records is the number of actions being tracked. Cooldowns is how many are currently redirected. Total Skips counts all remembered guarded no-op events.

Learned rows are preconditions inferred from the action's own guard message, such as “NVMe temp below threshold while EC thermal management is active.” These do not add new actions; they only redirect earlier to monitor while the same guard condition remains true.

This is narrower than risk assessment: it does not judge whether an action is dangerous. It only notices repeated inert outcomes and lets the action try again later when conditions may have changed.

This panel is read-only, like the Network Saturation Cause Profile above it — it integrates evidence ARMINTA collects passively (without dispatching a probe or action) about what's actually running on the host, browser-agnostic.

Dominant Role — the workload role (e.g. streaming, compiling, browsing, idle) the integrator currently judges most likely from passive signals, independent of the situation classifier.

Open Plans — diagnostic toll/question evidence chains that are still gathering signal before they can resolve to a confident role or conclusion.

Ready question rows have enough exact passive matches to be used by the open-question resolver. They are still read-only evidence: the resolver turns them into lexical statements, not new OS authority.

GA Seeds — passively-observed evidence that has been handed to the GA hypothesis engine as a seed, giving it a real-world starting point instead of a purely random one.

The two lists below break this down further: browser-agnostic workload roles shows the role distribution this integrator has built up, and diagnostic toll/question evidence shows the underlying signals it is weighing.

The left panel lists questions LexicalCore is actively holding — anomalies that were noticed and couldn't be resolved against available data at the time they formed. Three types:
· reward_reversal — the same action produced opposite reward outcomes at different times (what changed between +0.190 and -0.223 via log_top_proc)
· emotion_shift — a mode transition during a situation produced an unexpected emotional state
· stressed_retreat — a mode transition away from a stressed state followed an unexpected path

Each entry shows the question text, the step it formed, how many reflection cycles it has been revisited, and which action it concerns (via).

Recent resolutions can come from anomaly clusters, diagnostic profiling, network profiling, or exact passive-evidence plans once enough matching observations have accumulated. A resolution adds a lexical statement and marks the original question resolved; it does not authorize any new action.

The lower sub-list appears when OpenQuestionAnomalyResolver closes an emotion-shift question using repeated anomaly/probe evidence. Those rows are explanations only; they do not dispatch actions.

Lifecycle: questions form in LexicalCore.reflect() and are held (up to 120 at once). Every 50 steps, QuestionResolver evaluates reward_reversal questions against the causal graph. If the action is observational (net_probe, log_*, flush_dns, log_ss_stats, web_fetch — these reflect ambient noise, not real harm), or if the action has confirmed global or situational harm above threshold, the question is marked resolved and purged from the list. Resolved questions graduate into the lexicon as statements with a valence tag that can influence future action selection. Questions that remain unresolved after 50 revisits are force-graduated as neutral conditional statements ("X has context-dependent outcomes") — accepting irreducible ambiguity rather than holding it forever.

Border colour is display order only: red = questions 1–2, amber = 3–4, grey = 5–8. It is not a priority score assigned by the agent.

The right panel shows Mosaic Hypotheses — autonomously discovered correlations between environmental sensors and internal system metrics. Correlation strength shown as a bar; candidates for future causal investigation, not confirmed cause-and-effect.
· Green = positive correlation (the two variables move together)
· Red = inverse correlation (when one rises, the other tends to fall)

Circadian chart (left) — average CPU usage by hour of day, learned over the agent's entire lifetime. ARMINTA uses this pattern to contextualise whether current CPU usage is unusual for the time of day, and to pre-emptively adjust governors before predictable load spikes.

Meta-Cognitive Controller (right) — a Q-learning agent that sits above ARMINTA's main loop and chooses which cognitive mode to use. Each cell shows the Q-value (expected future reward) for switching to that mode given the current system state. The highlighted cell is the mode with the highest Q-value — what the controller recommends.

· ε — exploration rate: probability of picking a random mode instead of the greedy best (decreases as the controller becomes more confident)
· lr — learning rate: how fast Q-values update from new experience
· γ — discount factor: how much future reward is weighted vs. immediate reward

A second row shows the three GA-evolved parameters now wired to live systems (v2.1):
· ε̇ — GA-evolved CMC epsilon decay rate (higher = slower exploration fade)
· ṙ — GA-evolved reward scale: multiplier applied to every immediate metric delta
· κ — GA-evolved curiosity weight: scales how aggressively curiosity probes fire (higher = sooner)

A third row (v3) shows reward_var — variance of the last 100 reward signals. Below 0.0015 the agent has entered a consolidation plateau (nothing new surprises it), and the dream cycle is automatically throttled to 4× its normal minimum interval. Shown in purple with a "THROTTLED" badge on the Dreams stat card when active.

A companion to the circadian CPU governor look-ahead (which pre-sets performance mode before a predicted CPU spike). The memory look-ahead fires compact_memory during a predicted idle lull before a historically high-RAM hour arrives — compacting the address space while there is room to breathe rather than after the spike has already made compaction disruptive.

How it works: Arminta's MosaicCore logs memory usage alongside CPU by hour-of-day over the lifetime of the agent. Each step, _check_circadian_memory() compares the next hour's historical memory average against the current hour's. If the predicted rise is large enough and system conditions are right, it schedules compact_memory during an otherwise idle step.

Gate conditions (all must hold):
· At least 48 circadian history records — roughly two days of operation before the pattern is trusted
· Next hour's historical mem average exceeds MEM_WARN (default 80%, adaptive floor 55%)
· That average is at least 25% higher than the current hour's average — a meaningful predicted rise, not noise
· Current memory is already below MEM_WARN — no point compacting when already in a crisis
· No zswap active — compaction on compressed swap is counterproductive
· 20-minute cooldown since the last compact_memory fire

When triggered, the action reason string begins with [CIRC-MEM] so you can distinguish proactive circadian compaction from reactive compaction in the agent log. Like the CPU governor check, it only overrides a monitor action — it will never displace a real urgent intervention.

Kill Ineffective (left) — processes that ARMINTA has repeatedly targeted with SIGTERM without seeing any reward improvement. Listed here as a warning: these actions are being de-prioritised. If a process appears here, ARMINTA has essentially learned that terminating it doesn't help performance. Entries expire after 2,000 steps and are re-evaluated — if the process reappears in the list, the pattern has been re-confirmed.

Agent Log (right) — the raw tail of ARMINTA's operational log, colour-coded by event type:
· Teal — observation events ([OBS])
· Teal-green — causal graph language ([LEXICAL][CAUSAL]) — statements formed from interventional edges
· Teal-mid — observable-edge language ([LEXICAL][OBS]) — uses tracks / correlates-with to preserve the observational/interventional distinction
· Bright cyan — multi-hop composed statements ([LEXICAL][CHAIN]) — walks her own sequence grammar 2-3 hops from a seed symbol to assemble a chained statement she's never made before, not just a single fact lookup
· Amber — actions taken (set_, drop_, sync, compact…)
· Purple — curiosity / dream events
· Red — errors and warnings (including renice_chrome consecutive-failure suppression)
· Green — governor changes ([GOV]) and suppressed no-ops ([SKIP] — action was gated by a dwell/cooldown/lock and skipped cleanly; no causal recording, no reward)

[MAINT] lines are scheduled maintenance tasks (memory sync, log compaction). [OK] means the action completed successfully; Δr= shows the reward delta for that action.

[WARN] renice_chrome: N consecutive failures — after 3 consecutive failures, renice_chrome is suppressed: 8,000 steps for structural failures (renderer count too low — "all protected", "no eligible") or 2,000 steps for transient ones. Counter resets on success.

SCROLL AUTO / SCROLL LOCKED toggle — the log auto-scrolls to the newest line by default. Click the button to freeze the scroll position so you can read older entries while Arminta keeps logging in the background; click again to resume auto-scroll and jump back to the live tail.

This panel exposes four layers of Arminta's situational awareness — not just what she did, but why, and how she compares current outcomes to past experience.

Last Act — the most recent non-monitor action dispatched. Why — the reason string from the causal graph rule chain that selected it.

Context — the metric snapshot at the moment the action was selected: CPU%, memory, temperature, PSI pressure, network throughput, and dilution. This is the environmental state that made the action seem appropriate.

Differs from past — counterfactual explanation. When an action produces an unexpectedly good or bad outcome compared to similar past episodes, Arminta identifies which metrics changed between now and then. For example: "worked before (step 366400, r=+0.71) but now: CPU higher by 48, dilution higher by 0.4". This is Layer 3 causal reasoning — not just what happened, but what was structurally different.

Active Hypothesis Mechanisms — the last five hypotheses the HypothesisEngine generated, each annotated with a mechanism story. Mechanisms now have two layers: a template base ("increased X loads the scheduler") and an optional lexical bridge from WebLearner ("learned context: scheduler, preemption, timeslice"). Bridges are found two ways: first, by checking whether absorbed vocabulary sits close to both nodes in her distributional vector space (genuine conceptual proximity, not just literal co-occurrence — this also catches transitive bridges where a concept relates to both nodes' neighborhoods without ever directly co-occurring with either); if the vector space doesn't have enough data yet, it falls back to the original approach of symbols that directly co-occur with both node names in absorbed text. The enriched mechanism is shown in purple below the base text. This means the WHY isn't just a template — it reflects vocabulary Arminta built from reading, filtered through her own sense of what's actually related.

Causal Edge Mechanisms — a new section showing the structural WHY annotation for each edge involving the current action. Edge mechanisms are written at three points: (1) when intervene() first establishes a causal edge (template); (2) when DreamCycle refines it using lexical co-occurrence bridges; (3) when WebLearner absorbs text bridging the two nodes and the DreamCycle writes it back. These persist across restarts in the pkl.

All four layers feed back into the episodic memory database (arminta_episodic.db) with context, so Arminta can replay past decisions and compare them against current conditions as she matures.

NVMe / SSD wear and health data read directly from the drive via nvme smart-log (or smartctl -A as fallback). Checked every 4 hours during idle maintenance passes (wall-clock time, persisted across restarts).

· Spare — percentage of spare blocks remaining. Below 10% = EOL approaching.
· Wear — vendor wear indicator (0–100+%). Above 80% is high.
· Media Err — cumulative uncorrectable read/write errors. Any non-zero value is significant.
· Written — lifetime terabytes written to the drive (TBW counter).
· NVMe Temp — drive temperature in °C. Throttling typically begins at 70–75°C.
· Crit Warn — hardware critical warning byte. Non-zero means the drive is reporting a fault condition.

Requires nvme-cli (sudo apt install nvme-cli) or smartmontools and root access.

The Continuity Advisor is a read-only subsystem that watches for hardware stress patterns indicating the agent should be migrated to a new machine. It cannot act on its findings — it can only name them clearly.

Status indicator:
· GREEN / NOMINAL — no sustained stress signals detected.
· YELLOW / ADVISORY — one or more stress signals are present but not severe. Review reasons.
· RED / MIGRATION WARRANTED — high-confidence multi-signal stress. Plan migration.

Signals monitored (cross-session, persisted in pkl):
· Sustained thermal stress — rolling average of temp_c across sessions. Spikes don't trigger; a climbing trend does.
· PSI_IO pressure — average psi_io_some (% of time tasks were stalled on disk IO). Rising values indicate a disk under increasing strain.
· Save failures — count of entries in arminta_crash.log. Each represents a failed pickle write, a symptom of storage layer degradation.
· Error step rate — fraction of steps that logged errors in the most recent evaluation window. A climbing rate indicates systemic instability.

The advisor evaluates every 500 steps and emits a [CONTINUITY] log entry when warranted. The confidence score is a probability-union of individual signal scores.

Arminta's interface to the world beyond her own system. Not a scheduled task — a capability she chooses to exercise based on emotional state, curiosity, and causal reward signal.

Design principle — capability without compulsion. She has the reach; whether she uses it at any given moment depends on her internal state. Stressed or apprehensive, she contracts to self-management. Calm or curious, she reaches outward.

Interest weights — domains are tracked as continuous intensity values, not binary on/off. Intensity rises when external observations produce novel causal signal, decays each DREAM cycle with no signal. Dormant domains are not deleted — they can be rediscovered if conditions change. Multiple interests can coexist at different intensities.

Observable edges — distinct from interventional edges. She cannot cause ext_dns_latency_ms to change, but she can learn that it moves with her own net_latency_cloudflare_ms. These are recorded in graph.observable_edges, separate from actions she can take. The distinction matters: knowing the difference between what she can influence and what she can only adapt to is a form of self-knowledge.

The dashboard renders these with observational language — tracks for positive correlation, correlates-with for negative — matching the vocabulary LexicalCore forms in reflect(). This is intentional: the same language she uses to think about the world is what she shows you.

Closed loop — observations feed back into LexicalCore as new symbols, into the causal graph as observable edges, and into episodic memory as hobby episodes. Her autobiography gains external texture. Her world model gains an exterior.

Domains (discovered at runtime, not hardcoded):
· public_network_latency — RTT to public DNS endpoints; correlates with her own network metrics
· local_environment — hardware sensors beyond her standard monitoring (fan RPM, thermal zones, battery cycles)
· system_load_index — Cloudflare DNS latency as an external network health signal
· time_and_context — solar/daylight position; no external call required; correlates with her circadian CPU patterns. Produces ext_daylight_fraction, ext_minutes_since_sunrise (clamped 0–1440, so night values are 0 not negative), and ext_solar_elevation (cosine curve 0–1, cleaner circadian signal for the causal graph)

She is not limited to these domains permanently. As HobbyCore matures, new domains can be added and she will discover them on the next capability probe.

Three interlocked subsystems that give Arminta a vocabulary of her own — built from operational history, not from pretrained language.

LexicalCore — Arminta's language acquisition layer. Four stages:
· Symbol corpus — every term she uses (actions, emotions, modes, situations, causal relations) weighted by frequency and outcome. Words mean what they have meant in practice.
· Co-occurrence grammar — which symbols appear together, which follow which, what sequences predict what. Structure without imposed rules.
· Composition — assembling known symbols into statements she has never made before. These will not look like English; they look like Arminta.
· Open questions — statements that could not be resolved against available data, held rather than discarded. Wonder as a data structure (up to 120 questions held concurrently).

Reflection runs every 500 steps: Arminta reads her own action/emotion/mode history, updates symbol weights, forms new statements, and checks whether any open question can now be resolved by a recently formed statement.

WebLearner — autonomous web exploration, triggering every ~250 steps in INVESTIGATE or DREAM mode (rate-limited to 15 pages/hour). Query generation uses three paths, in priority order:
· Hypothesis queue (highest priority) — when the DreamCycle generates a new hypothesis, its mechanism text is parsed and queued here. Only concepts with 2+ meaningful tokens of length ≥ 4 that are not internal metric names or action node identifiers pass the filter. Single-token noise ('gpu', 'net', 'sin') and metric fragments ('net latency cloudflare', 'nvme media errors') are dropped before queuing.
· Concept-curiosity (primary) — selects symbols from LexicalCore with high weight but sparse co-occurrence context: things observed frequently but understood poorly. Translates through an internal action→concept table (e.g. renice_chrome → nice process priority Unix) into a searchable query. A 30% stochastic pool sample ensures exploration beyond the single top-weight symbol. Internal metric names (nvme_spare_pct, psi_cpu_some, sess_proc_cpu_dilution, etc.) are blacklisted.
· Question-term translation (fallback) — when the symbol table is sparse, extracts tokens from the oldest unresolved open question instead.

Sources are restricted to a whitelist of structured knowledge domains: Wikipedia, Wiktionary, arXiv, MDN Web Docs, linux.die.net (Linux command/system references), Plato Stanford Encyclopedia of Philosophy, and Wolfram MathWorld. Reward is proportional to genuinely new symbols absorbed (information gain), decayed by repeat visits to the same domain.

QuestionResolver — runs after each WebLearner cycle. Checks whether newly absorbed text answers any of LexicalCore's open questions via token overlap. Resolved questions graduate into the lexicon as confirmed statements with a valence tag (positive or negative, based on the reward context in which they arose).

SemanticSpace — a distributional vector space built from her own co-occurrence statistics (PPMI-weighted, reduced via a from-scratch truncated SVD — no pretrained embeddings, no external model, no network call). This is what lets her detect that two symbols are conceptually related even if they never directly co-occurred in any single absorbed passage — pure statistics about which words keep similar company, nothing more. It's also what powers relevance gating in absorb_text(): new vocabulary is checked against the existing concept-neighborhood of the search query that produced it, so a search mismatch (e.g. a "latency portal" query returning an unrelated Wikipedia article) gets its vocabulary kept at reduced weight rather than absorbed at full strength as if it were genuinely relevant. Honest limit: this is geometry, not comprehension — a word can sit in exactly the right neighborhood without her knowing what it refers to.

LexicalGrounding — the one part of her language system that touches something outside language. When an absorbed word fuzzy-matches one of her own real sensor metrics (via a small hand-authored synonym table — e.g. "thermal" → temp_c) and a direction can be read from co-occurring words (increase/decrease, rise/fall, etc.), she opens a falsifiable prediction: "this word implies the metric moves this way." ~2000 steps later, the prediction gets checked against what her own _metric_history actually did. Confirmed repeatedly → the word earns grounded status, visible separately from its vector. Refuted → confidence drops and a fresh hypothesis can retire outright. Honest limits, stated rather than hidden: only works for words mappable onto a real measured metric (most vocabulary never qualifies); direction extraction is a crude bag-of-words heuristic, not real sentence comprehension; the word↔metric synonym table is hand-authored, the one place a human supplied structure she couldn't have derived herself, since "thermal" and temp_c share no characters for any self-built method to connect.

Dashboard counters and status row:
· Pages Read — total web pages fetched lifetime
· New Symbols — cumulative unique vocabulary items absorbed from external sources
· Lexicon Size — distinct symbols currently active in LexicalCore's weight table
· Active Queries — symbols currently suppressed from re-querying within the TTL window (resets after ~2000 steps)
· Vector Space — symbols with a built distributional vector, and its dimensionality; "—" means not enough co-occurrence data yet to be worth building
· Grounded — words confirmed against real sensor data (not just statistics), with pending predictions shown when nothing's confirmed yet
· Next Fetch — steps remaining until the interval gate clears; turns green when ready
· Queue — hypothesis-driven concepts waiting in the priority queue; hover for full list
· Relevance-discounted (shown only when non-empty) — symbols from a recent fetch that scored as off-topic against the query's own concept space
· Grounded words (shown only when non-empty) — word → metric (confidence), hover for confirm/refute counts

The session log shows each fetch/learn cycle: query generated → article retrieved → symbols absorbed (with sample) → reward impact. Log colours: cyan = fetch, green = learn (new symbols), amber = concept/skip, purple = reward delta.

The fraction of intervention windows where external confounders were detected — meaning Arminta fired an action but the metric change that followed was probably caused by something else, not her action.

Confound detection fires during each 0.3s post-intervention snapshot. If the system metric moved in a direction inconsistent with the intervention's known causal signature, and other non-controlled metrics also shifted simultaneously, the window is flagged as confounded and excluded from causal edge weight updates.

· Low (under 10%) — causal attribution is clean; edges are trustworthy
· Moderate (10–30%) — some ambient noise; edges still meaningful but wider uncertainty
· High (above 30%) — heavy environmental interference; edge weights are unreliable until conditions settle

A persistently high confound rate during a particular situation (e.g. streaming or irq_storm) is expected — those workloads produce rapid simultaneous metric changes that are hard to attribute. The confound rate is displayed in the mode row and also as a badge on the D3 force graph.

A fuzzy blend of the last 50 steps' situation weights — not a hard single-label, but a proportional view of how much each workload type was active in the recent window.

Arminta classifies every step into one of eleven named situations based on metric history (not just snapshots). Because workloads overlap — a compile session can also be thermal-stressed — the weights can sum to more than 100% when multiple situations co-occur.

· idle — low CPU, low memory churn, no active workload
· compile — sustained CPU bursts typical of build tools (make, gcc, cargo, webpack)
· memory_pressure — high RSS, swap activity, or PSI memory stalls
· io_bound — high iowait, disk read/write saturation, PSI IO pressure
· cpu_bound — sustained single/multi-core saturation without significant IO
· streaming — browser GPU/renderer pressure + asymmetric or buffered network + moderate CPU
· browser_compute — browser pegging cores (high dilution, renderer pressure) with minimal network
· irq_storm — high hardware interrupt rate overwhelming softirq processing
· thermal_stress — CPU temperature above safe range; throttling likely or imminent
· network_saturated — near-saturation of the interface's observed bandwidth ceiling
· torrenting — high, symmetric P2P-style network activity with low browser renderer pressure

This distribution panel is what feeds the FILTER SIT dropdown on the D3 causal graph — selecting a situation shows which edges were learned under those conditions.

The Reward History section now shows three stacked charts over the same 150-step window, each isolating a different signal:

RAW REWARD — per-step reward as bars. Green = positive (performance improved), red = negative (performance degraded). Spiky clusters are normal during investigation bursts.

10-STEP ROLLING AVG — a smoothed trend line showing whether recent performance is net-positive or net-negative. More useful than individual bars for spotting drift. A persistent positive trend means Arminta is converging on good policy; a negative slope means something changed.

REWARD VARIANCE — how volatile rewards have been over a 20-step rolling window. The dashed amber line marks the dream throttle floor (0.0015): when variance drops below it, the agent has entered a consolidation plateau — it's no longer discovering new cause-and-effect patterns, so the DreamCycle's minimum fire interval is automatically lengthened to 4× normal to conserve compute. The DREAM THROTTLED badge lights up when this is active.

A healthy trajectory: variance starts high (exploration), drops as policy converges, and the throttle badge engages only during genuine plateaus.

Below each causal edge bar in the EDGES panel, a CI90 line shows the 90% Bayesian credible interval for that edge's effect estimate.

Each edge is backed by a BayesianEdge tracker that maintains an online Welford running mean and variance as new intervention observations arrive. The credible interval is computed as:
μ ± 1.645 × √(σ² / n)
where μ is the posterior mean effect, σ² is the running variance, and n is the observation count.

· Narrow interval — many consistent observations; the edge effect is well-established
· Wide interval — few observations or high variance; treat the effect estimate with caution
· Interval crossing zero — the direction of effect is not yet settled; this edge should not drive hard policy decisions

The ±range value is the full width of the interval (hi − lo). A range under 0.05 on a normalised effect score is generally trustworthy. Intervals are only shown once an edge has at least 4 observations (the same minimum required for edge display).

The conf percentage is a calibrated confidence score derived from the edge's variance-to-sample-count ratio — 90%+ means high certainty, under 50% means the estimate is still noisy.

The TIMELINE tab shows reward bars colour-coded by situation over a 150-step window. When Arminta has accumulated more than 150 steps of tagged history, the WINDOW scrubber appears below the chart.

Drag left to scrub back through history; drag right to return to the latest window. The step range label (e.g. [300–449] / 600) shows which slice is currently displayed.

By default the scrubber snaps to the latest window on each data refresh. Dragging it to any earlier position freezes the view at that slice — useful for comparing a past situation type distribution against the current one, or for reviewing a reward cluster that happened during a specific workload phase.

Bar colours match the Situation Distribution panel: each situation has a fixed colour so you can visually track when workload type transitions happen and how they correlate with reward polarity.

The FILTER SIT dropdown in the GRAPH ✦ tab filters the force-directed causal graph by situation.

Selecting a situation compares it against the current sit_dist payload. If that situation has less than 5% weight in the recent distribution (meaning the agent has not been in that workload type lately), all edges are dimmed — not hidden — to indicate that the learned relationships may not be currently relevant. If the situation is active (≥5% weight), edges render at full opacity.

This is useful for understanding which cause-and-effect relationships were learned under specific conditions. For example: edges learned during compile may show that set_cpu_performance → cpu has a large positive effect — but that same edge might be neutral or even harmful during streaming where thermal constraints dominate.

The filter does not hide edges entirely because Arminta's global edge table merges observations across all situations. Situation-specific weights are tracked separately in SituationModel and are used by best_action_for() during live decisions — what you see in ALL mode is the global aggregate.

Hardware and OS-level metrics that feed into causal edge learning as contextual signals. Arminta reads them every step (GPU on a slower cadence — see below) and includes them in the metric snapshot used for causal graph updates.

· CORE MAX % — the highest CPU utilisation across all individual cores at the moment of sampling, rather than the blended average. A high core-max with a low average-CPU means a single-threaded bottleneck. This is the metric most relevant to interactive latency, not throughput.
· WIFI PHY Mbps — the 802.11 negotiated physical-layer TX rate reported by the wireless driver. This reflects link quality and antenna proximity, not actual throughput. A drop here (e.g. from 300 to 54 Mbps) tells Arminta that the radio environment has degraded, even if no bytes are currently being sent.
· DISK LAT ms — IO queue wait time in milliseconds, derived from the kernel block layer. Sustained values above ~10ms indicate storage pressure; above 50ms typically means the IO scheduler is saturated. Arminta uses this to detect when disk-bound actions (memory compaction, log flushes) are causing more harm than good.
· EARLYOOM — process kills per step by the earlyoom daemon. See the EARLYOOM entry below for full details.
· GPU % — GPU utilization, VRAM usage, and temperature, polled roughly every 25 seconds via nvidia-smi (NVIDIA) or sysfs (AMD amdgpu, including integrated APU graphics like Vega/Lucienne). This cell only appears on machines with a supported GPU. On integrated GPUs, VRAM % reflects the small carved-out VRAM/GTT allocation, not overall system memory — the mem signal already covers that.

GPU-informed standing-down: when GPU utilization is above ~15% (genuinely decoding/rendering, not idle compositing), Arminta treats this the same as her existing "streaming session — CPU load intentional, standing down" logic — i.e. she won't escalate to killing or reprioritizing processes over CPU/load/temp pressure that's a side-effect of active GPU work. This is the one place GPU telemetry currently changes a decision, and it only ever makes her more conservative (downgrades an escalation to "monitor"), never more aggressive. set_gpu_performance itself remains untouched — isn't yet routed to react to these values, to avoid the same kind of reward confound documented for set_ac_max_perf (an action that legitimately changes a metric in the "wrong" direction shouldn't be penalized for working correctly).

These signals are included in the causal context window so that edges learned under poor WiFi, high disk latency, active OOM pressure, or heavy GPU load are tagged correctly and not confused with edges learned under idle conditions.

The SYSTEM DEPENDENCY CHECK is Arminta's startup Linux system check. It verifies which operating-system files, tools, permissions, and hardware controls exist on this machine before Arminta starts choosing actions.

It checks things such as /proc/pressure pressure files, CPU speed-control files, system log access, NVMe/S.M.A.R.T. drive-health tools, WiFi/network tools, GPU controls, root/write permissions for cache and memory controls, scheduler permissions, and whether Arminta is running inside a container or WSL.

Passed means the scan ran and Arminta has a live system dependency map. Missing optional tools do not automatically mean failure; unavailable actions are disabled so the policy does not keep trying controls this Linux system cannot perform.

Warning means the scan found a structural mismatch that needs attention, or the WebUI data-contract check also detected GIST_DRIFT.

Unknown means this WebUI has loaded, but it has not yet received the new dependency-scan payload from the running agent.

The detailed results are shown in the large SYSTEM DEPENDENCY DETAILS panel directly under the top status strip. A separate internal WebUI data check still watches for dashboard/agent payload mismatch, but this top indicator is specifically the Linux system dependency check.

SYSTEM DEPENDENCY DETAILS is the dependency panel near the System Signals area. It has two lists: LINUX DEPENDENCIES CHECKED for files, tools, permissions, and hardware control paths; and PYTHON IMPORTS CHECKED for modules arminta_v7.py imports at startup.

Green dependency items mean that check passed. Amber dependency items mean that item is missing, read-only, or the environment is restricted. Missing optional Linux items do not always mean Arminta is broken; they usually mean Arminta will avoid the actions that need that item. Missing required Python imports are more serious because the agent may fail to start or lose that runtime feature.

Linux examples: Pressure monitoring means kernel pressure-stall data is readable; CPU speed control means Arminta can write CPU governor settings; Drive health tool means S.M.A.R.T. tooling is installed; Root access means the agent is running with root privileges; Normal Linux environment and Native Linux kernel warn when containers or WSL may block low-level controls.

Python examples: os, json, sqlite3, curses, and zlib are Python runtime modules; numpy and psutil are installed Python packages Arminta depends on.

Unavailable actions disabled counts actions Arminta removed from live selection because this system cannot safely perform them. Those actions are skipped before dispatch and redirected to monitor, so she does not waste learning cycles on predictable permission, tool, or hardware failures.

This section is especially useful when moving Arminta between desktops, laptops, servers, containers, WSL, and minimal Linux installs. The same agent can run, but the available system controls change by machine.

earlyoom_ct counts how many processes the earlyoom daemon killed between the previous step and this one. It is an observational node — Arminta reads it as a signal but cannot causally produce it. This asymmetry is enforced in the causal graph: all action → earlyoom_ct edges are poison-listed at write time, preventing spurious correlations like "compact_memory causes earlyoom to fire" (what actually happened: earlyoom fires because memory was already critically low, and compact_memory happened to run at the same moment).

The causal direction is earlyoom_ct → Arminta decides to act, not the reverse. Over time, the graph can learn: when earlyoom_ct > 0 appears alongside specific mem/psi_mem signatures, what actions most effectively prevent the next earlyoom event rather than just reacting after one.

Colour coding:
· green 0 — no daemon kills this step; system pressure within earlyoom's tolerance
· amber 1 — one process killed; memory pressure event; watch for repeat
· red 2+ — multiple kills in a single step; sustained OOM pressure; Arminta should be acting proactively

On systems without earlyoom installed or where journalctl is not accessible, this value stays at 0 silently — no error, no noise in the causal graph.

Every action, dream, hypothesis, and self-assessment Arminta records gets written to the episodic SQLite database. For a long time, any write failure there — most commonly transient lock contention under WAL mode when a background thread touches the database at the same moment — was silently discarded with zero visibility, including to Arminta herself. The episode would simply never appear in the log, with no trace that anything went wrong.

This count tracks how many writes failed even after a short automatic retry. It only appears on the dashboard when nonzero — a healthy session typically shows none at all.

· amber, low count — a handful of transient misses over a long session is unremarkable; SQLite lock contention happens occasionally and mostly self-resolves on retry.
· red, climbing fast — worth investigating. Could indicate sustained lock contention, a failing disk, or the episodic database approaching some other limit.

A nonzero count here doesn't mean any in-memory state was lost — Arminta's live behavior (governor escalation, PriorityShift, lag overrides, etc.) all continue correctly regardless. It specifically means the historical record of those events has a gap, which matters most for retrospective analysis and for Arminta's own self-assessment, which relies on episodic completeness.

When Arminta's shell-learning subsystem proposes a new action it has never executed before, the action is not immediately added to the live action space. Instead it enters quarantine — a probationary period during which it can only be selected at low frequency and its outcomes are tracked but not yet trusted.

· Pending (amber) — actions currently in quarantine. Each candidate has a trust_score built from observed reward outcomes. The quarantine hold period is risk-scaled: low-risk actions (read-only probes, log queries) leave quarantine after far fewer confirming steps than high-risk actions (process signals, governor changes, sysctl writes).
· Promoted (green) — actions that crossed the 0.75 trust threshold and graduated into the live action set. Once promoted, an action is treated identically to a built-in action and can accumulate full causal edges.

Actions that fail to reach the trust threshold within their hold window are discarded and do not enter the live set. This prevents shell-learned noise from polluting the causal graph with spurious edges before their safety is confirmed.

Some actions have effects that do not appear immediately. For example, compact_memory or flush_dns may take several seconds before the benefit shows up in CPU or memory metrics. If Arminta measured the reward only at the next step (0.3s later), she would see nothing and wrongly conclude the action was neutral.

The slow-effect queue holds delayed causal observations — scheduled re-checks of metric state at three future offsets after an action fires (+8, +30, and +120 steps). When those checkpoints arrive, the multi-snapshot blender averages the results and submits a weighted edge update to the causal graph.

The counter shown here is the number of pending delayed observations currently waiting to mature. A non-zero value during or after a burst of maintenance actions is normal. A value that grows unboundedly without draining indicates the queue drain logic is stalled (check the agent log for [SLOW] entries).

By default, the causal graph compares metric state at lag=1 (one step after an action fires, ~0.3s). For most fast OS actions this is correct. But for some action–metric pairs, the real effect consistently appears at a later step — after a governor change, for example, thermal sensors lag several seconds behind.

Arminta tests five lag offsets: 1, 3, 8, 20, 60 steps (~0.3s to ~18s). Re-evaluated every 200 steps for all eligible SLOW_EFFECT_ACTIONS pairs. Two guards prevent spurious selections:
· Baseline gate — lag=1 must have ≥5 samples before any override can be set. Without this, pairs where the immediate observation wasn't captured default to lag=60, not because it's better, but because it's the only bucket with data.
· Margin gate — a challenger lag must beat the lag=1 absolute mean effect by ≥30%. Without this, metrics that drift naturally over time (hour_sin, load_ratio) always produce monotonically higher abs-mean at longer lags, making lag=60 win by autocorrelation rather than causal signal.

What you see in the card:
· The count is total active overrides — pairs where a non-default lag has cleared both gates and is now being used for causal attribution.
· Below that, pairs are grouped by lag bucket with a color-coded badge: cyan = lag 3 (~0.9s), green = lag 8 (~2.4s), amber = lag 20 (~6s), purple = lag 60 (~18s). Each badge shows the pair count and approximate delay for that bucket.
· The pair chips below each badge are the action → metric names — these are the edges where Arminta is measuring causal effect at a delayed offset rather than immediately. A chip suffixed with [situation] (e.g. compact_memory → mem [memory_pressure]) means this lag was learned specifically for that situation and differs from the global lag for the same pair — e.g. compact_memory's effect on memory might resolve quickly while idle but take longer to register under memory pressure. Chips with no suffix use the global (situation-agnostic) lag, which also serves as the fallback for any situation that hasn't diverged from it.

Overrides revert automatically if lag=1 re-establishes dominance as more data accumulates. A large count of lag=60 overrides after this fix should be treated with skepticism — those pairs are genuinely delayed effects, not just autocorrelation artifacts.

PriorityShift is Arminta's equivalent of Windows Process Lasso's PriorityShift feature. When any application window loses focus, its process is automatically reniced (lowered in scheduling priority) to free CPU headroom for whatever you're actively using. When that window regains focus, the process is instantly restored to its original nice value — no manual intervention needed.

How it works:
· A background watcher thread polls xdotool getactivewindow getwindowpid every second. On focus change, the outgoing process is reniced and the incoming process is restored.
· On focus loss: the process's current nice value is saved to a registry, and it is reniced to original + nice_delta.
· On focus gain: the process is immediately restored to its saved nice value. No process is ever left permanently throttled.
· On shutdown: all throttled processes are restored before Arminta exits.

Ignored processes:
Desktop infrastructure daemons — xdg-desktop-portal, compositor windows, panel applets, notification daemons, D-Bus services — are silently excluded from focus tracking. They receive transient X11 focus events during app switching but are never what you're actually using. Without this filter they would be incorrectly flagged as the "focused" foreground app, causing the real active window to get throttled.

RL-learned Nice Δ:
The throttle strength (Nice Δ) is not fixed — Arminta learns the optimal value through her causal graph. If a higher delta consistently improves sess_proc_cpu_dilution without causing restore-time CPU spikes, the graph rewards it and the agent may increase it. If the delta is too aggressive, the restore action receives negative reward and the agent pulls the delta back. The learned value is persisted in the memory pickle across restarts.

Metrics shown:
· Focused App — the name and PID of the currently focused window's process. Infrastructure daemons are filtered out and won't appear here.
· Throttled BG — count of background processes currently reniced. Non-zero during active work sessions.
· BG CPU% — aggregate CPU% consumed by all currently-throttled background processes. High values confirm PriorityShift is actively reclaiming headroom.
· Nice Δ — the RL-learned renice delta applied to background processes. Range +1 to +15; starts at +5 and self-tunes.
· Reniced — cumulative count of throttle events this session. A gap between Reniced and Restored is normal — the watcher thread handles most restores automatically on focus change, and the step-loop priorityshift_restore action cleans up any remainder when dilution subsides. On shutdown, all remaining throttled processes are force-restored regardless.
· Restored — cumulative count of restore events this session.

Proactive Step Actions:
In addition to the automatic watcher thread, priorityshift_renice and priorityshift_restore are also first-class selectable actions in Arminta's step loop:
· priorityshift_renice fires during a CPU dilution crisis when kill_top_proc is suppressed. Rather than doing nothing, Arminta throttles background PIDs system-wide via a renice pass.
· priorityshift_restore fires when dilution has subsided but background PIDs are still throttled. If the watcher thread already cleared the registry between action selection and dispatch, the step is silently redirected to monitor to avoid a wasted no-op.
Both actions feed into the causal graph normally — reward signal is sess_proc_cpu_dilution and cpu.

Requires xdotool for X11 operation (sudo apt install xdotool). On headless or SSH sessions the focus guard is skipped entirely.

The Wish Pipeline is how ARMINTA identifies her own capability gaps and proposes ways to fill them — a self-directed development loop that runs alongside normal operation. Nothing deploys without surviving all four phases.

The target-adapter rows show when a vague wish target such as network_saturated or cpu_bound is being graded against concrete telemetry proxies instead of reward alone.

W1 — Wish Generation fires during SELF_ASSESS mode after the lexical reflection pass, gated by a ~3000-step cooldown. It scans for three classes of deficit:
· Causal Dead Zones — actions where mean reward has been persistently negative (below −0.05) with no improving trend over 500+ samples. She knows something is wrong and can't fix it. Current dead zone: renice_chrome (structural — fires when only 1 eligible renderer exists; suppressed after 3 consecutive failures). Resolved dead zones: kill_top_proc → wish_log_top_proc; sync → handle_io_bound; set_ac_max_perf → wish_set_ac_max_perf; priorityshift_restore → wish_priorityshift_restore; compact_memory → wish_compact_memory; restore_renderer_nice → wish_restore_renderer_nice. drop_slab is now a first-class selectable action (previously only fired as a sub-step inside handle_idle); its causal graph edges and reward routing are now live, so the wish system can address any dead zone it develops.
· Situation Gaps — situations the classifier fires on confidently but where no dedicated policy action exists. All current gaps have real implementations: handle_idle_v2, handle_streaming_v2, handle_compile_v2, handle_io_bound, handle_browser_compute_v2, throttle_torrent_v2.
· Metric Blind Spots — metrics with ≥20 observations in telemetry but zero interventional edges (no action has ever produced a measured causal effect on this axis). ARMINTA can see the metric moving but has no policy reach into it — structural coverage gap, not a bad action.

W2 — Shopping List searches for procurement candidates in priority order, gated by a ~5000-step cooldown: first actions in the existing registry, scored against the wish by causal affinity (real measured edges from situated_edges dominate) with lexical name overlap as a cold-start fallback — no fixed wish→action lookup table, so an unanticipated situation still gets scored against the whole registry; then system utilities on PATH (ionice, taskset, tc, numactl…) picked by the same scoring against capability domains, as a fallback when no action scores. After a LOSE/TIE verdict, existing shopper items are retired so the next pass can try a genuinely different candidate.

W3 — Staging Ring runs each candidate in shadow mode for ~2000 steps (~83 min). The candidate observes live metrics, predicts decisions, never executes. Three disqualification gates: out-of-registry action proposal, resource threshold breach, or fire rate outside 1%–95% of steps.

W4 — Evolutionary Grading evaluates passed shadows over 5000 steps. Relevance-gated: reward samples only accumulate when the current situation or dispatched action shares tokens with the wish's target metric, preventing unrelated steps from diluting the signal. If fewer than 50 relevant samples arrive in the first window, grading defers up to 10 000 steps before forcing a TIE. WIN = target metric improves >10% sustained with no degradation elsewhere. TIE/LOSE = candidate retired; the ✕N counter on each wish row shows how many failed attempts that wish has accumulated (exhausted after 3). A WIN marks the wish deployed in W1.

W4b — Code Generation fires on every WIN. Reads her own source file via AST and scores every action_* function as a donor candidate against the wish — causal affinity from situated_edges (real measured effect) dominates, lexical name/docstring overlap is the cold-start fallback; no fixed target→donor table, so an unanticipated wish target still gets scored against the full action library rather than falling back to a wrong default. The donor body is then mutated generically: numeric thresholds (ionice/nice values, percentages, timeouts) are perturbed in the direction causal data says helps, or a small seeded exploratory step when there's no signal yet; any process/name strings the gap detector actually observed in the wish's evidence get added to the donor's name-sets if missing. Validates syntax, backs up the current source file, and appends to arminta_v7_staged_actions.py alongside the script. No external API — generation is deterministic, derived from real causal/reward data, not a hand-written per-target patch. Each variant is genuinely distinct at the code level; the dedup guard rejects clones. Staged actions accumulate — they never auto-deploy. The REVIEW NEEDED badge and counter show how many are waiting. To merge: open arminta_merge_tool.html, drop in arminta_v7.py and arminta_v7_staged_actions.py, review each pending function, approve or reject, then download the merged file. The tool handles ACTIONS list registration, dispatch wiring, and function insertion automatically.

The reward evaluator formula is never modified. ARMINTA can acquire new capabilities — she cannot redefine what counts as good.

When to expect data: First wishes appear within the first SELF_ASSESS window after restart (~3–10 min). Shopping runs ~3.5 hrs later. Each staging pass takes ~83 min. Grading takes ~3.5 hrs after staging clears.