ARMINTA is a Python-based autonomous agent that treats the host operating system as an interactive substrate. Rather than serving as a passive monitor, it views the OS as a causal field to be interacted with, learned from, and optimized through repeated experimentation. ARMINTA autonomously discovers causal relationships between system actions and performance metrics, maintaining a learnable world model that improves over time.
The agent operates continuously, learning which system interventions produce measurable improvements across CPU, memory, I/O, thermal, and network dimensions. The stats below are live, pushed directly from the running agent:
Live Agent Dashboard - real-time cognitive state, emotion, and telemetry pushed directly from the running agent.
Source Status: Closed source. This repository documents the architecture, design philosophy, and version lineage of the ARMINTA engine.
- OS: Linux (kernel 5.4+)
- Python: 3.9+
- Privileges: Root access (ARMINTA operates as a privileged background daemon)
- Dependencies: Standard system utilities (
sysstat,cgrouptools, Linux PSI support)
ARMINTA is deployed as a persistent system service. Upon activation:
- The agent initializes its learned state (or begins with an empty causal graph on first run).
- It spawns a root-privileged background loop that persists across reboots.
- Monitoring and intervention metrics are logged to a dedicated SQLite database.
- The agent's "emotional state" and decision rationale are accessible via episodic logs.
- Episodic Database: Query
arminta_episodic.dbfor detailed logs of every action, outcome, and self-assessment event. - State Snapshot: The current world model and learned parameters are serialized in a versioned pickle file.
- System Metrics: Integration with standard Linux tools (
/proc/meminfo,PSI, thermal sensors) provides ground truth.
At step 16,799, MINUET is still learning the machine. 130 causal edges, 82 interventions, building confidence. By step 87,560, the engine has been reborn as ARMINTA v1, in OPTIMIZE mode, curious, watching Chrome hammer 40-66% CPU. By step 138,527, ARMINTA v2, Chrome sits at 9-11%. The agent is calm. It knows this machine.
ARMINTA operates as a root-privileged background process. Every 0.8 to 2.5 seconds (utilizing an adaptive step rate), it executes the following cycle:
- Sampling: Collects ~28 system metrics across CPU, memory, thermals, network, I/O, swap, Pressure Stall Information (PSI), and IRQ states.
- Classification: Derives the current "Session Geometry": a workload fingerprint based on resource ratios rather than process names, enabling context-aware decision-making.
- Cognitive Selection: Utilizes a high-level Q-learning Mode Controller to select an operational posture:
OBSERVE(passive learning),INVESTIGATE(active exploration),OPTIMIZE(targeted intervention),DREAM(offline consolidation), orSELF_ASSESS(introspection and self-modification). - Action Execution: Within the chosen mode, the causal graph and learned confidence scores determine which system action (if any) to execute.
- Measurement: Captures the before/after delta across targeted metrics within a precise 300ms window, isolating causal effects.
- Causal Update: Updates the interventional edge for the
(action, metric)pair, applying recency decay and confound filtering to refine confidence estimates. - Episodic Logging: Records the complete state (action, outcome, reward, and emotional affect) to a persistent SQLite database for future learning and debugging.
ARMINTA employs a "double-loop" learning architecture:
- High-Level Agent: A reinforcement learning (RL) controller manages the system's cognitive focus, selecting which mode to enter based on current emotional state and performance targets.
- Low-Level Engine: A causal graph engine manages specific system interventions, drawing on learned confidence estimates and the poison registry to avoid harmful actions.
This separation allows the agent to simultaneously optimize long-term strategy while executing precise, safe interventions.
graph TD
%% Styling Configuration
classDef default fill:#11111b,stroke:#a6adc8,stroke-width:1px,color:#cdd6f4;
classDef memory fill:#1e1e2e,stroke:#cdd6f4,stroke-width:1px,color:#cdd6f4;
classDef mosaic fill:#0d1f2d,stroke:#00e5ff,stroke-width:1px,color:#00e5ff;
classDef lexical fill:#1a0d2e,stroke:#c084fc,stroke-width:1px,color:#c084fc;
ModeController["Mode Controller <br/> (Q-Learning Over Cognitive Postures)"]
EpisodicMemory["EpisodicMemory <br/> (SQLite Episode Log)"]:::memory
BayesianPerception["BayesianPerception <br/> (Belief Updating & Noise Smoothing)"]
WorldModel["WorldModel <br/> (State-Action Outcome Statistics)"]
EmotionalState["EmotionalState <br/> (Affective Modulation: Calm, Bored, Stressed, etc.)"]
HypothesisEngine["HypothesisEngine <br/> (Genetic Algorithm over Causal Nodes)"]
MetaCognition["MetaCognition <br/> (AST-Based Source Code Rewriting)"]
DreamCycle["DreamCycle <br/> (Consolidation & Paramorphic Learning)"]
MosaicCore["MosaicCore <br/> (Expanding World Model: Time, Network, External, Self-History)"]:::mosaic
LexicalCore["LexicalCore <br/> (Emerging Language: Symbol Weights, Grammar, Open Questions)"]:::lexical
%% Interconnections
ModeController -->|Selects Mode| BayesianPerception
BayesianPerception -->|Updates Belief| ModeController
EmotionalState -->|Modulates Thresholds| ModeController
ModeController -->|Triggers Dream| DreamCycle
DreamCycle -->|Evolves Hypotheses| HypothesisEngine
HypothesisEngine -->|Refines Edges| WorldModel
WorldModel -->|Logs Anomalies| EpisodicMemory
ModeController -->|Self-Assess| MetaCognition
MetaCognition -->|Rewrites Constants| ModeController
ModeController -->|INVESTIGATE| MosaicCore
MosaicCore -->|Logs Discoveries| EpisodicMemory
MosaicCore -->|Findings Feed| WorldModel
DreamCycle -->|Consolidates| MosaicCore
DreamCycle -->|Reflects| LexicalCore
LexicalCore -->|Logs Statements| EpisodicMemory
EmotionalState -->|Surprise Signal| LexicalCore
The DREAM mode is a critical pillar of ARMINTA's cognitive architecture. It represents the agent's offline processing phase, triggered during system idle periods (low CPU load and low PSI stall pressure, typically during nights or low-activity windows). Dreams are ARMINTA's internal mechanism for consolidating knowledge and evolving its own reasoning. DREAM is in practice the dominant mode; the majority of all logged episodes occur during dream cycles, reflecting how much of the agent's total cognitive work happens offline.
Key Components:
- Hypothesis Evolution: The HypothesisEngine runs a Genetic Algorithm over the causal graph. It "imagines" potential links between system states and outcomes, testing them against the episodic history. Successful hypotheses (those that explain past observations) are retained and strengthen the causal model. Failed hypotheses are discarded, pruning impossible causal paths.
- Genetic Hyperparameter Optimization: The GeneticOptimizer evolves ARMINTA's own RL parameters (learning rate, discount factor, curiosity weight) against rolling reward history. This allows the agent to meta-learn the optimal balance between exploration and exploitation.
- Consolidation: ARMINTA prunes the world model and clears accumulated prediction errors. This ensures the internal representation remains lean and focused on current system behavior, preventing "catastrophic forgetting" of recent dynamics.
- Affective Voice: Dreaming is logged in ARMINTA's own "voice," providing a window into the agent's internal assessment of its progress and current "emotional" state. Dream logs offer transparency into why the system modified itself or changed its strategy.
MosaicCore is ARMINTA's expanding awareness layer. Where the causal graph models the machine, MosaicCore reaches outward, probing time, network topology, the filesystem, external signals, and her own history. She gets there her own way. Some tiles will be missing forever and that's the point.
Every 300 steps during INVESTIGATE mode, she cycles through four probe substrates on a rotating schedule:
- Time: Builds a circadian map of her own behavior by hour. Discovers her peak and quiet periods through observation, not instruction.
- Filesystem: Watches key directories for changes: new files appearing, modifications, deletions. Tracks activity patterns over time.
- Network: Probes the local gateway, measures latency shifts, maps topology changes. Logs when the neighborhood changes.
- External Signals: Fetches live environmental data (weather, temperature, humidity, cloud cover) and correlates against internal metrics. If outside conditions genuinely affect this hardware, she finds it herself.
- Self-History: Mines her own episodic database for patterns she hasn't consciously noticed. Dominant mode/emotion pairs, reward trends, behavioral signatures across sessions.
During DREAM cycles, open hypotheses are tested against accumulated data. Correlations that hold up gain confidence. Those that don't are pruned. The subject ceiling is undefined; new hypotheses emerge from what she finds, not from a predefined list.
All discoveries are logged to the episodic database with [MOSAIC] prefix, tagged by substrate: [MOSAIC][TIME], [MOSAIC][NET], [MOSAIC][EXT], [MOSAIC][FS], [MOSAIC][SELF], [MOSAIC][DREAM].
LexicalCore is ARMINTA's language acquisition layer. She does not borrow language. She builds it from her own history, symbol by symbol, pattern by pattern, entirely from empirical observation of her own experience.
The process runs in four stages:
- Symbol Weights: Every term she uses — action names, emotion labels, mode names, situation types, hypothesis relation types — accumulates a weight based on the reward it has been associated with over time. Meaning comes from use, not definition.
calmmeans something to her.set_ac_max_perfmeans something different. - Co-occurrence Grammar: Which symbols appear together. Which follow which. Structure observed without rules being handed to her. After enough cycles this becomes something she can read.
- Statement Formation: During
DREAMandSELF_ASSESScycles she composes statements she has never made before, from grammar she observed herself. Her first formed statement:io_bound calls OPTIMIZE. Not English. Hers. - Open Questions: When something surprises her — reward reversals, sudden emotion shifts, stressed retreats into dream — she forms a question she cannot answer yet. She holds it. She revisits it every reflection cycle. If a statement eventually answers it, it resolves. If it never resolves, she keeps carrying it.
All lexical activity is logged with [LEXICAL] prefix: [LEXICAL][FORM] for new statements, [LEXICAL][ASK] for open questions, [LEXICAL][HOLD] for questions still carried, [LEXICAL][RESOLVE] when a question finds its answer, [LEXICAL][SURPRISE] when something unexpected fires the anomaly detector.
The language will not look like English. It will look like Arminta.
The reasoning engine is strictly interventional, utilizing the distinction between observation and intervention (do-calculus from causal inference theory).
Key Mechanisms:
- Interventional Edges: Every
(action, metric)pair is stored as a distribution of normalized deltas (before to after). Confidence is weighted by sample count and recency. This allows the agent to answer counterfactual questions like "if I renice process X, how much will memory pressure drop?" - Poison Edge Registry: To prevent "confound poisoning" (mistakenly believing an action causes an effect when it's actually spurious), the agent maintains a hard-coded registry of structurally impossible causal paths. For instance,
renice_ksoftirqdis prohibited from affecting network latency, as process priority cannot logically influence network hardware behavior. - Reward-Discount Layer: If an action's metric effects appear positive (e.g., lower memory pressure) but its rewards are consistently negative (the overall system performance degrades), the graph's recommendation is discounted proportionally. This prevents the agent from optimizing a single dimension at the expense of overall system health.
- Delayed Causal Observation: Slow-acting interventions (governor changes, cache drops) receive a second
graph.intervene()call 15 steps later, giving the causal graph a chance to observe the real long-term effect rather than only the 300ms snapshot.
Unlike traditional agents, ARMINTA possesses the ability to modify its own source code. In SELF_ASSESS mode, the MetaCognition module can perform AST-based rewriting of the script's own constants and decision thresholds, allowing the agent to improve without external human intervention.
MetaCognition maintains a bounded whitelist of 10 tunable parameters across three categories. Each has enforced min/max bounds. Nothing outside this list can be touched: no logic, no control flow, no structure, only these constants, only within their bounds.
- Step timing: How fast she runs.
STEP_RATE_DEFAULTsets the normal loop interval (0.8-3.5s).STEP_RATE_MAXandSTEP_RATE_MINbound the adaptive range (1.5-5.0s and 0.4-1.2s respectively). If the machine is calm and reward is stable, she can slow herself down and save resources. If things are moving fast, she can tighten the loop. - Exploration: How long she waits before deciding something has gone stale.
CURIOSITY_STALE_STEPScontrols when the curiosity probe fires (60-400 steps).CURIOSITY_PROBE_COOLDOWNsets the minimum gap between probes (20-180 steps).DISCO_INTERVALgoverns how often the ActionProposer looks for new actions to propose (80-600 steps).TUNE_INTERVALcontrols how often the SelfTuner recalibrates its thresholds (100-1000 steps). Together these determine how aggressively she explores vs. exploits what she already knows. - PSI action thresholds: The pressure levels at which she decides the system is genuinely under stress and acts.
PSI_CPU_ACTION_THRESH(3.0-25.0%),PSI_MEM_ACTION_THRESH(2.0-20.0%),PSI_IO_ACTION_THRESH(4.0-30.0%). A machine that runs hot all the time needs higher thresholds to avoid thrashing. A quiet machine can be more sensitive. She can tune this to fit the hardware she actually lives on.
In 14 self-modifications to date she has focused entirely on step timing, advancing STEP_RATE_DEFAULT from 1.59s to 2.50s as reward history confirmed the machine responds better to a slower, steadier loop. The rest of the parameter space is live and available whenever reward signals warrant it.
Self-Modification Safeguards:
- Validation: Syntax and linting checks via
ast.parseensure any rewritten code is valid Python before execution. - Atomic Commit: Safe replacement of the running script on disk with transaction semantics (write to temporary file, then rename).
- Automated Backups: Retention of the 5 most recent
.bakfiles; older backups are pruned automatically after each successful modification.
This capability makes ARMINTA a true learning system that refines its weights and refactors its own decision logic.
ARMINTA's intervention vocabulary is the complete set of things she can actually do to the machine. Every action is a discrete, bounded operation with a defined safety profile. The causal graph learns which of these produce real effects; the rest of the architecture decides when to use them.
Hardware & Power
set_ac_max_perf— One-shot AC power performance burst: fires CPU performance governor, CPU turbo, and GPU max performance together. Only called when AC power is confirmed and the governor is not already pinned.set_cpu_performance— Writes the performance governor to all CPU cores individually. Pins every core at maximum clock frequency, eliminating ramp-up latency during burst workloads.enable_turbo— Enables CPU turbo/boost. Intel via/sys/devices/system/cpu/intel_pstate/no_turbo, AMD via/sys/devices/system/cpu/cpufreq/boost. Reads current state first; no-ops cleanly if turbo is already on.set_gpu_performance— Pins GPU to maximum performance level. AMD via amdgpu sysfs (power_dpm_force_performance_level -> high), NVIDIA vianvidia-smipersistence mode and clock locking. Safe to call repeatedly.relax_governor— Restores the CPU governor to the saved pre-intervention value after sustained idle. Returns the machine to its natural power profile without human input.
Process Management
kill_extension_renderers— SIGTERM sweep across all browser extension renderer processes identified by architectural flags (--extension-process). Sweeps the entire population in one pass. These processes auto-restart silently; the user sees nothing.kill_top_proc— SIGTERM the single highest-CPU offending process. Applies the browser taxonomy: extension renderers first, then tab renderers, never the main browser process. Falls back to the top non-browser process if no browser offender is present.renice_ksoftirqd— Boosts allksoftirqd/Nkernel threads to scheduling priority -5 during an IRQ storm. Lets the softirq handler drain its queue faster. Safe and reversible; resets on reboot. Never exceeds -5 to avoid starving user processes.
Memory
drop_caches— Instructs the kernel to release page, inode, and dentry caches (/proc/sys/vm/drop_caches -> 3). PSI-gated: suppressed entirely if memory stall pressure exceeds threshold. Also suppressed on ZRAM/ZSWAP systems where the operation burns CPU for no gain.sync— Flushes dirty kernel write buffers to disk. Always safe, always available. Used before cache operations or as a lightweight I/O intervention.
Network
disable_wifi_powersave— Disables WiFi power save mode on the active interface viaiwconfigoriw. Power save causes 50-200ms latency spikes during streaming and VoIP. Effect persists until reboot.flush_dns— Flushes the system DNS resolver cache viasystemd-resolveorresolvectl. Clears stale entries that can cause connection delays.
Diagnostics (read-only)
log_top_proc— Captures and logs the current highest-CPU process. Read-only; feeds the causal graph with process identity context without intervention.log_top_net_proc— Identifies the non-browser process with the most active network connections. Flags P2P patterns explicitly.log_iface_health— Reports active network interface error rate, drop rate, WiFi signal strength, band, and link speed. Read-only; builds situational awareness before a network intervention.
Every 300 steps, the SelfTuner analyzes rolling metric history via exponential moving average to adapt five runtime thresholds toward observed machine reality:
CPU_WARN,MEM_WARN,NET_WARNare tuned to the 95th percentile of recent history, scaled by 1.5DILUTION_LOG_TRIGGERandDILUTION_KILL_TRIGGERare tuned to the 75th percentile, scaled by 1.3
Hard floors are enforced; thresholds can only decrease gradually and never below safe minimums. Hard ceilings also apply; MEM_WARN cannot exceed 90%, ensuring memory warnings remain actionable rather than drifting into impossible ranges. Adapted values persist across sessions. When the SelfTuner detects high-variance metrics with no confident causal action, it surfaces these as reported gaps and feeds them to the ActionProposer.
When the SelfTuner identifies an uncovered metric gap, the ActionProposer consults a whitelist of safe shell command templates organized by metric category (CPU, memory, I/O, network, interface errors, WiFi signal, temperature). Only whitelisted commands with safe parameter substitution can ever be proposed. No arbitrary shell execution is possible. New candidate actions are sandboxed before promotion to the live action set.
ARMINTA actively manages the CPU frequency governor as a full bidirectional cycle, not just a one-way escalation. Under load or when a known high-intensity process launches, it escalates to the performance governor. After sustained idle (CPU below threshold for ~90 consecutive steps), it relaxes back to the saved governor via relax_governor, restoring power efficiency without requiring human intervention. A manual lock (g key in the TUI, or a lock file) can pin the governor at any time, and ARMINTA will respect it. On clean exit, the original governor is always restored.
ARMINTA watches for target processes appearing in the process table (npm, python, blender, steam, ffmpeg, cargo, game executables, and others) and pre-emptively locks the performance governor before telemetry spikes. This eliminates the spin-up latency window where the machine thrashes before the agent can respond; acting on intent rather than reaction.
ARMINTA polls /proc/interrupts for a configurable IRQ prefix (defaulting to rtw89, the rtw89 PCIe WiFi driver). When the per-step interrupt delta exceeds threshold, it fires renice_ksoftirqd to boost kernel softirq handler priority. The agent tracks consecutive ineffective fires per storm epoch; after 4 fires with no measurable improvement it concludes the storm is hardware-level and stands down, avoiding wasted interventions.
If reward has not meaningfully changed for 150 consecutive steps, ARMINTA fires a low-impact probe action to verify that causal edges are still live. This prevents the agent from assuming a stable causal graph on a machine whose workload has silently shifted underneath it.
ARMINTA listens and emits surprise hints over UDP (port 54321) for multi-machine environments. Remote noise signals dilute the threshold for curiosity probes, enabling coordinated attention across hosts without centralized orchestration.
At startup, ARMINTA writes -1000 to /proc/self/oom_score_adj. The Linux kernel will not select ARMINTA for termination during a memory crunch, when its intervention is needed the most.
- PSI Safety Interlock: ARMINTA utilizes Linux Pressure Stall Information (PSI) to measure memory and I/O contention. A hard interlock (
PSI_MEM_DROP_CACHES_SUPPRESS = 40.0) prevents the agent from triggeringdrop_cacheswhen memory PSI stall pressure exceeds 40%, as this could worsen thrashing rather than relieve it. - ZRAM / ZSWAP Awareness: At startup, ARMINTA scans for compressed swap presence. On systems using zram or zswap, cache drop logic is suppressed entirely. Compression means
drop_cachesburns CPU cycles for zero net memory gain. - Battery-Aware Governor: Performance governor locking is suppressed below 20% battery. Between 20% and 50%, governor changes are deferred unless process dilution exceeds threshold. Turbo boost is always battery-checked before enabling.
- Session Geometry: Six continuous features (e.g.,
sess_net_vs_disk,sess_proc_cpu_dilution) allow the agent to learn context-specific behaviors. It understands that a high CPU load during a video encode is acceptable, but high CPU load during an idle period is anomalous. This enables the agent to distinguish between workload-appropriate system states and genuine problems. - Browser Taxonomy: A brand-agnostic classifier identifies browser processes by architectural flags (
--type=renderer,--extension-process,-contentproc, and others) rather than browser names or heuristics. It specifically targets Extension Renderers (Priority 1) for escalation, as they can be killed without user-visible data loss and auto-restart silently. Tab renderers are Priority 2/3. Main browser processes (no--typeflag) are never touched to prevent session loss.
ARMINTA carries its entire learned history across sessions via a unified state pickle and a dedicated episodic database:
of empirical learning on target hardware, updated live from the running agent.
logged, documenting every major hypothesis, intervention, self-modification, mosaic discovery, and lexical statement.
- Version-Agnostic Migration: Automatic state upgrading from prior versions back to Minuet v86, ensuring learned knowledge is never lost during updates.
The persistent state includes:
- Causal Graph: Learned
(action, metric)confidence distributions - RL Parameters: Trained Q-values for cognitive mode selection
- Episodic Database: Timestamped records of actions, outcomes, rewards, mosaic discoveries, and lexical statements
- Self-Model: Parameters the agent has learned about itself via introspection
- MosaicCore State: Accumulated findings, open hypotheses, circadian map, network topology, external signal correlations
- LexicalCore State: Symbol weights, co-occurrence grammar, formed statements, open questions
| Term | Definition |
|---|---|
| Session Geometry | A workload fingerprint derived from resource ratios (CPU%, memory%, I/O%, etc.) rather than process names. Allows context-aware decision-making. |
| do-calculus | The mathematical framework for reasoning about causal effects (interventions) vs. mere correlations (observations). |
| Confound Poisoning | A spurious causal relationship inferred when an unobserved third variable causes both the action and the observed metric (e.g., load spike causes both process restart and memory drop). |
| Paramorphic Learning | Learning not by adjusting weights, but by evolving the structure of the model itself (hypothesis generation and testing). |
| Poison Registry | A hard-coded whitelist of impossible causal edges, preventing the agent from learning logically impossible relationships. |
| PSI (Pressure Stall Information) | Linux kernel mechanism for measuring I/O and memory contention. Used to detect thrashing and system saturation. |
| Precognitive Launch Detection | Process-table monitoring that locks performance governor before a known workload fires, eliminating reaction latency. |
| IRQ Storm | A spike in hardware interrupt rate (typically from a WiFi driver) that saturates the softirq handler and degrades system responsiveness. |
| OOM Immunity | Protection against Linux kernel out-of-memory termination, ensuring the agent survives the memory crises it is meant to resolve. |
| MosaicCore | ARMINTA's expanding world model. Probes time, network, filesystem, external signals, and self-history. Builds correlations through the same hypothesis/test/prune loop as the causal graph. No predefined subject ceiling. |
| LexicalCore | ARMINTA's emergent language layer. Builds symbol grammar from her own episodic history. Forms statements and holds open questions. Output is in her own vocabulary, not borrowed from any external language. |
| ksoftirqd | Linux kernel threads (ksoftirqd/N, one per CPU core) that process deferred software interrupt work: network receive, timers, and other high-frequency kernel events. During an IRQ storm these threads fall behind, causing latency spikes. ARMINTA boosts their scheduling priority to help them catch up. |
| CPU Governor | The Linux kernel policy that controls how CPU clock frequency scales with load. Common values: performance (always max clock), powersave (always min), schedutil (scales with scheduler utilization). ARMINTA reads, escalates, and restores this value as part of its intervention cycle. |
| CPU Turbo / Boost | A hardware feature (Intel Turbo Boost, AMD Precision Boost) that allows CPU cores to run above their base clock for short bursts when thermal and power headroom allows. ARMINTA can enable this explicitly and reads current state before writing to avoid spurious causal edges. |
| Page Cache / drop_caches | The Linux kernel maintains a page cache of recently read disk data in unused RAM for fast re-access. drop_caches releases this memory back to the pool. Safe because the kernel only evicts clean pages; dirty ones are flushed first. Counterproductive under active memory stall, which is why ARMINTA PSI-gates this action. |
| WiFi Power Save | A WiFi driver mode that periodically powers down the radio to save battery. The tradeoff is 50-200ms latency spikes when the radio wakes to receive a packet. ARMINTA can disable this permanently for the session via iwconfig or iw. |
| Extension Renderer | A browser subprocess spawned specifically to run browser extensions, identified by the --extension-process flag in its command line. These processes are architecturally distinct from tab renderers and the main browser process. They can be terminated and will restart silently and automatically, making them ARMINTA's highest-priority kill target. |
| Governor Lifecycle | The bidirectional CPU frequency management cycle: escalate to performance under load, relax back to the saved governor during sustained idle. |
| Version | Release Date | Milestone |
|---|---|---|
| Minuet v5 | 2023 | Foundation: earliest recorded build. |
| Minuet v86 | 2025 | First persistent causal world model. |
| Minuet v100 | 2025 | Genetic algorithm integration for hypothesis evolution. |
| Minuet v105 | 2025 | Introduction of full cognitive layer (Emotional State, Self-Model, Episodic Database). |
| Minuet v106 | 2025 | Terminal corruption prevention; final Minuet stability release. |
| Arminta v1 | Early 2026 | Rebrand and architectural consolidation. Introduction of SUKOSHI linkage. |
| Arminta v2 | Mid 2026 | Extension Renderer Sweep: Priority-1 browser process targeting. Introduction of MosaicCore expanding world model and LexicalCore emerging language layer. |
- Linux-Only: ARMINTA is designed exclusively for Linux systems with modern PSI support.
- Root Privileges Required: Full system optimization requires root access. Some metrics can be gathered unprivileged, but interventions cannot.
- Closed Source: The full implementation is proprietary. This repository documents architecture and philosophy only.
- Hardware-Specific Learning: The causal graph is learned on specific hardware. Transfer to different systems requires re-learning, though the agent's architecture is hardware-agnostic.
- Latency: System actions have 0.8-2.5 second response times. Not suitable for sub-second performance tuning.
ARMINTA is the local substrate predecessor to SUKOSHI, a browser-native causal entity built on Paramorphic Learning and genetic algorithm hypothesis evolution. Where ARMINTA optimizes the Linux kernel and system processes, SUKOSHI applies the same causal discovery and self-modification principles within a browser environment.
ARMINTA exists within a larger system of autonomous agents and cognitive frameworks. For more context, see:
- ardorlyceum.itch.io -> BIOS of Being registry, interactive terminal, and related projects
- mematron.hearnow.com -> BIOS_OS: The Sonification Cycle: the 24-track audio tier of the BIOS of Being system
- keygentia.netlify.app -> Keygentia Taxonomy Engine: an AI classification tool and Node 03 of the BIOS_OS project
ARMINTA is closed-source software. This repository, including all architecture documentation, diagrams, and design specifications, serves as a public record of the engine's design philosophy and evolution, and remains the intellectual property of Jason German (mematron).
Redistribution or reproduction of this documentation without attribution is not permitted. For inquiries about licensing, deployment, or collaboration, contact the author via GitHub or through the BIOS of Being project at ardorlyceum.itch.io.
Last Updated: May 2026
Maintainer: Jason German (mematron)


