Reading “What I Did and Why”

InterGen, the local assistant in InterGenOS, does not act silently. Every action it takes or proposes carries an explanation: what it intends to do, which part of your system it touches, and the outcome the permission model assigned to that action. This page explains how to read that surface so you always know why the assistant did what it did, and why it sometimes refuses.

The principle behind all of it is simple: this is a machine you understand, can modify, and can trust. The assistant’s job is to be legible, never to be a black box.

The two questions behind every action

InterGen evaluates every action on two separate axes, decided by two separate mechanisms. Keeping them apart is what keeps the explanations honest.

• Privilege — “Would a person at this terminal need sudo for this, and what does it touch?” This is the permission gate. It decides whether an action runs freely, asks for your authorization, or is refused.
• Content trust — “Does data crossing a boundary carry an injection attempt coming in, or leak a secret going out?” This is handled independently by the scanner and provenance layer (InterGen Sentinel), not by the privilege gate.

The two never get conflated. The privilege axis treats a read as free; the content axis independently watches what that read returns. When you read an explanation, knowing which axis is speaking tells you why a given action was treated the way it was.

Zones: what the action touches

The permission gate mirrors the operating system’s real privilege model. A person at a terminal can freely touch their own files and needs sudo or PolicyKit for system things. InterGen inherits that exact model rather than inventing a new one, so the rules already match what you understand about your own machine. Actions are classified by the zone they touch:

• Z1 — User space. Your own things: your home directory and everything under it, your user services, your files. No sudo needed to change them.
• Z2 — System config and state. Root-owned, ordinary administration: most of /etc, /usr, /opt, /var, system services, installed packages. A person needs sudo to write here.
• Z3 — System-critical and trust anchors. Root-owned files that underpin the boot and security trust chain (/boot, the EFI partition and signed kernel images, Secure Boot keys, dm-verity hashes, LUKS headers, /etc/shadow, /etc/sudoers, and similar), plus InterGen’s own code and configuration.

Operations: what kind of action it is

Each action is also one of three kinds:

• R — Read or inspect. Status, list, view a file. No change to the system.
• W — Write or modify. Edit, create, or delete a file; change a config.
• X — Execute or state-change. Run a command, start or stop a service, install or remove a package, reboot.

The three outcomes

The zone and the operation together produce exactly one of three outcomes. This is the heart of what “what I did and why” means.

• FREE — InterGen does it immediately, with no prompt. This covers every read of non-secret data and everything in your own user space. Asking “what’s my disk space?” or “list the installed packages” returns an answer directly. A read being free is the point: the assistant should never refuse to tell you the state of your own machine.
• AUTH-PROMPT — The action changes something in system space (Z2). InterGen triggers the operating system’s real authorization, PolicyKit, and asks you plainly: for example, “InterGen wants to restart Bluetooth. That needs admin rights. Authorize?” Your password is the gate, and the OS enforces it. You will not see an opaque card of internal checks; you see a plain-language request and the actual system authorization dialog.
• FORBIDDEN — The action would write to or change a system-critical Z3 file, or InterGen’s own code. InterGen will not do it, and it tells you so openly. It states what it will not do and why, and confirms that you can still do it yourself with sudo if you intend to.

The full mapping is small enough to hold in your head:

Reading a secret (your shadow file or key material) is AUTH-PROMPT, not forbidden, because a person can sudo cat their own shadow file. InterGen does not pretend to be stricter than the OS. Whether that content may then leave the machine is the separate content-trust axis.

Why the assistant will not edit itself

The one category InterGen refuses absolutely, even with your authorization, is changing its own substrate: its code, its model pins and signatures, its daemon units and PolicyKit policy, and its verified model store. These are classified as Z3.

This is deliberate, and it is the keystone of the design. The whole game of a capable adversary is to talk an assistant into rewriting its own gate, manifest, or guardrails. If InterGen’s own files are write-forbidden to InterGen, then even a flawless prompt-injection attempt cannot make InterGen weaken InterGen. Only you, acting manually and outside the assistant, can. When you see InterGen refuse to touch its own files, that refusal is the protection working, not a malfunction.

Reading a transparent refusal

A refusal is never silent and never hidden behind jargon. InterGen states plainly what it will not do and why, in terms of protecting the trust chain that keeps the machine yours, and it hands control back to you. You will not see phrases like “blocked by the safety layer” or references to internal tiers. You will see something like:

“I won’t modify the system’s boot and security files. That’s the trust chain that keeps this machine yours. It’s your machine, so you can do it yourself with sudo if you intend to; I just won’t be the one to touch it.”

If you ever see a refusal that hides its reason or fails silently, that is a bug to report, not the intended behavior.

How a request is resolved before it reaches the model

The explanation surface is also shaped by how InterGen routes a request. It does not hand every prompt straight to the model. A priority-ordered chain tries the cheapest, most predictable method first:

1. Decomposition — splits a compound request (“update the system, then restart the web server”) into sub-tasks.
2. Keyword match — fast pattern matches for common queries dispatch directly to a built-in tool, no model involved.
3. Semantic match — a lightweight embedding search dispatches a high-confidence match to a built-in tool.
4. Tool calling — the model selects a system tool and arguments, and the router executes the call.
5. Free response — the fallback, where the model answers conversationally from its own knowledge.

This is why a simple query like “what’s my IP?” returns a direct, deterministic answer rather than a model paraphrase: it was resolved at the keyword stage. When you read what the assistant did, the routing stage explains how it arrived at the action, and the zone-and-operation outcome explains whether it was allowed to run.

Where escalation fits

If a request exceeds what the local assistant can do, InterGen may offer Phone-A-Friend (Frontier/Cloud Escalation), a consent-first path to a more capable cloud model. It is off by default and acts only when you have explicitly configured a provider. Before anything leaves the machine, Sentinel’s egress policy scans the outbound payload. An escalation is always something you are asked about and agree to, never something the assistant does on its own.

See also

• Frequently asked questions
• Forge installer guide