Small models, grounded actions: inside Herizon Linux
A useful computer assistant should show where an answer came from and what an action actually did. Herizon Linux is developing that relationship between local models, your files, and an ordinary Linux desktop.
October 6 status: The latest built candidate is 1.2.0-rc1, R11. It has measured BIOS installed-system results and remains under qualification. It is not an accepted stable release. The next integrated assistance architecture is approved and being implemented; R11 does not contain it.
Then: establish the local path
The earlier development images brought together a Debian desktop, a floating chat interface, trained advisory models, and a separate small controller. The immediate engineering question was concrete: could this combination start in a real guest, retrieve local evidence, and complete a registered read through the same controls used by the command interface?
The 1.1.9-dev image recorded BIOS and UEFI live boots, desktop rendering, and in-guest controller checks. Those results belong to that image. A live boot does not establish disk installation, durable state, or the behavior of a later candidate. R11 advances the work into an installed BIOS guest, where the assistant can be checked alongside account setup and the desktop people actually use.
Now: a local assistant with inspectable evidence
R11 combines Debian 13, Xfce, LightDM, and a Calamares installer with a Herizon chat bubble. The controller is Qwen3-0.6B in Q8_0 format, running on the CPU. Shipped inference does not require a cloud model call or an NVIDIA GPU. In this candidate, AI starts off and model processes load on demand after assistance is enabled.
The installed CPU acceptance recorded a live advisory-head worker, controller operation, typed reads, and teardown of owned inference processes. These are functional results within an owned BIOS virtual machine. They do not establish performance on every computer, voice operation, GPU training, or unrestricted production model quality. See the local AI release evidence for the current boundary.
Read the source before answering
Local retrieval searches selected document roots and returns excerpts with paths, line ranges, a SHA-256 digest, and an observation time. Before accepting a citation, the runtime reads the current file again. A result from an earlier read cannot silently become evidence for changed bytes.
The current built-in collection is deliberately bounded: up to 512 regular UTF-8 text documents, 16 MiB total, and 256 KiB per file. Symlinks, hidden paths, and specified credential-like filenames are excluded. These limits make the scope understandable; they also mean this candidate should not be described as understanding every file on a drive. A larger collection requires a narrower selected root.
For a question about the bundled recovery guide, the interface can show the relevant source passage. A generated answer is presented as a grounded candidate only when it matches supplied source text. Unsupported answers can abstain while the excerpts remain available. The reader can check the passage instead of accepting the model's confidence as proof.
Keep a proposal separate from an effect
The models offer advice. Code validates targets, arguments, and authority. A document-read request becomes a typed plan referencing an exact selected file; a preview does not dispatch it. On execution, the adapter checks current identity and preconditions, performs the registered read, and records an observed result.
This matters when files change between the question and the action. A stale target can be refused rather than substituted with another document. The current intent surface supports system inspection and exact document reads; arbitrary model-generated shell commands are outside that capability set. App-pack installation follows its separate explicit confirmation path.
The installed acceptance passed eleven scoped self-tests, including grounded retrieval, preview without dispatch, broker receipts, changed-target refusal, stale-evidence exclusion, root-traversal refusal, and symlink exclusion. These negative cases test the boundary as well as the successful path. They are not a percentage score for general intelligence.
Vision: assistance beyond the chat window
The approved next design moves assistance into an unprivileged service owned by the signed-in user. Desktop, terminal, and search become clients of that service. Hiding the bubble should leave assistance available; a separate privacy and resource pause should cancel work and prevent inference from restarting. This distinction still needs implementation and installed-image acceptance.
Interactive Bash assistance is planned around Shift+Tab, while ordinary Tab completion remains intact. Suggestions should identify the executable, installed documentation, targets, effects, and privilege requirements. Selection inserts a suggestion for review; it does not execute it. Unknown commands and uncertain expansions must be explained as uncertain. These are planned behaviors, not R11 features.
The same roadmap adds native per-user manifests and Q-RAG integration with selected roots, permission checks, and current-byte validation. It extends the evidence discipline into wider file discovery without claiming that a search index proves a file is still readable. It also requires measured resource budgets; small models alone do not prove faster whole-OS performance.
What to watch next
The useful next proof is an installed desktop where terminal and search assistance work with chat hidden, survive graceful reboots, and retain state through a verified signed update. Final BIOS and UEFI tests, graphical acceptance, and physical hardware checks must establish that behavior before stable promotion. Follow the release gates alongside the product overview.
Continue with the offline toolkit and the checks behind a release.