← KADAI Deutsch
KADAI · Concept overview · As of 6 October 2026

A desktop compiled from a kernel

KADAI reverses the order: instead of installing a machine and then laboriously personalizing it, a small, encrypted, portable description of the person - the kernel - is compiled into a desktop on every machine. KDE Plasma is the first-class shell, Nextcloud the storage tier, git the memory.

compile(me.md, environment) → desktop

Three blocks, three degrees of maturity (October 2026). KADAI consists of three parts that belong together but are not equally far. The personal kernel with identity, register, keyring and vault runs on three machines and is far along. The flow-based interface, the rail at the screen edge with cards, log and review instead of windows and chat, is at the beginning and exists on the lab machine. Support by models, the subsidiary router with its judging instance, is at the beginning too; it hangs on the interface, because that is where the verdict falls. Sections 1 to 3 describe the first block, section 4 the third; the second appears in sections 4 and 6 and gets a page of its own once it is more than a prototype.

1 · The core idea

me.md - the kernel Markdown, stable IDs, provenance per entry, encrypted identitywho I am factsmy world (devices, network, role) valueswhat I stand for · decides trade-offs preferenceshow I want to work · soft ruleswhat must never happen · hard episodicwhat's going on right now · may be stale stores meaning, never configuration Environment device · network · place · time detected at startup compile Reconciler Desktop (KDE Plasma) Activities as compiled modes panels, widgets, default apps files lazily from the cloud current state is read, only the difference to the target is applied episodic write-back: what's new, with origin and date
The kernel contains statements about the person, never about the shell: "focused work in the mornings" instead of "panel at the bottom, widget X". A Plasma backend translates that into an Activity without notifications; another backend could translate the same thing into a focus mode. This separation is what makes the kernel platform-independent.

What the kernel minimally contains (as of 20 September 2026): what the person said - not who they are. The founding page already generates a valid kernel from five statements (name, form of address, verbosity, cloud posture, providers) and a detected environment (language, time zone, device); the first modes, the values and the rules ship as defaults and can be changed later. What the system observes - devices, accounts, what is being worked on - is data, not instruction: it can be collected again and does not have to live in the file; the kernel points to it via me:// resources. The kernel is thus compiled like the desktop: compile(interview, observations) → kernel, then compile(kernel, environment) → desktop. A “small kernel” - address, modes, rules, preferences - is an instance of the same format, not a different design.

2 · The layers - and which of them already run

validated (running, as of October 2026) design, not yet built
Shell - KDE Plasma 6 Activities, panels, widgets driven via DBus scripting · layout dump as current state platform-specific Module runtime - MCP capabilities as MCP servers, manifest + sandbox as trust boundary; kernel sections as me:// resources Suggestions - router and tiers by place rules are binding, what leaves is shown first · smallest sufficient rung first: without a model → on this device → on your network → with a provider Storage tiering - git and Nextcloud git: kernel, small, versioned (= audit log) · Nextcloud: large files, offload/restore logged and reversible Kernel + identity me.md encrypted to all of your own machines (age), keys in the security chip · keyring and vault next to it · three machines live portable runs on any Linux; Mac/Win as VM host
KADAI's own invention is small: the kernel format, identity, the compile step, the Plasma binding. The middle is integration of existing building blocks (MCP, Nextcloud, git), not new construction. In the suggestions layer the deterministic floor is already proven: sync, decryption, reconciler and storage run without any model - if every model fails, the system gets dumber, not inoperable.

3 · Getting onto my system - anywhere

The core scene: a generic seed image that anyone can fetch becomes Jan's system through a single passphrase. Proven on 16 August 2026 in a fresh VM: first boot, ceremony, decrypted kernel - at the next login "Welcome, Jan" with the date of the kernel state; since 29 August the desktop is additionally rebuilt at every login from the specification in the repo.

Kernel repo (git, private) kernel encrypted · register of authorized machines · master identity (passphrase-protected) Seed image or package image: Linux + Plasma, for empty machines package: assistant on a running Ubuntu the image for anyone, the package from your network start First-boot ceremony 1 · machine generates its own keys - in the security chip where it has one 2 · passphrase unlocks the master identity in memory only 3 · machine enters the register and gives its sync key write access the guardian is replaceable: passphrase today, a FIDO key next clone Person: passphrase in your head - all that travels without being a file native · Linux + Plasma full compiled desktop virtualized · macOS, Windows the seed as a VM - a legitimate form conversational · iOS, Android no desktop: the assistant knows the kernel same kernel - compile depth depends on the platform
There is no central identity provider. Identity is possession (repo access) plus knowledge (passphrase) plus a register in your own repo - sovereign in the literal sense. A lost device is revoked by deleting one line and re-encrypting.

4 · Where suggestions come from: a role, not a fixed model

0 · without a model scripts: sync, reconciler, storage system stays operational - guaranteed 1 · on this device small model, offline the normal case: nothing leaves the device 2 · on your network mid-size model on your own machine never leaves your infrastructure 3 · with a provider strongest model, external cloud per action, with a preview and a yes → one rung up only when the previous one measurably falls short, and only as far as the rules allow · to the right: more capable, less private
Subsidiarity: the router starts at the smallest rung that has been sufficient for this kind of task so far and ascends only when the result measurably falls short. What the person accepts or discards sets the starting rung for the next time. Before any step to a provider it shows what would leave the machine and waits for a yes that covers one action, not the session. Prototype in the lab since September 2026: a 0.8-billion model on the device, a 2-billion model on the network, a provider behind consent; concept in kadai-subsidiarity.md.

The judging instance (since 4 October 2026). Nobody knows beforehand which rung a task needs; whatever judges that in advance is guessing. The instance measures afterwards and remembers, in four parts. Classification: the kind of task plus measurable features of the input without a model, length, language, whether outside knowledge is asked for; statistics run per kind and length class. Ceiling: the lowest of the model register, the input's data class (account numbers, health, money, third parties' contact data, content of the person's own kernel), limit blocks in the kernel's rules and the person's pins; the reason is shown on the card. Check: formal checks per kind, then the person; "better" on the card counts as a verdict against the rung shown. Review: in the rail, per kind of task, where the rung settled, with seconds and an energy estimate, and there the pins "never below", "never above". That is bookkeeping with a measuring stick, not an oracle.

5 · What this means for KDE

What Plasma 6 can already do today - validated

  • evaluateScript via DBus works from outside the session, reading and writing (wallpaper, widgets, panels) - under Wayland too
  • dumpCurrentLayoutJS() returns the complete desktop state as an executable script - a built-in serialization round trip
  • Activities are fully scriptable (create, name, switch, each with its own desktop configuration) - the "compiled mode" already exists as a container
  • Finding: loadSerializedLayout is additive, not idempotent - so reconciliation lives in KADAI (diff-and-apply), not in the layout load

What KADAI would ask of Plasma

  • a declarative reconcile API: "here is the target state, reconcile to it" - instead of imperative scripts
  • a kernel-aware widget base class that reads me:// resources under rule control
  • an Activity metadata schema (purpose, kernel slice, modules, devices) so that Activities become portable
  • capabilities per widget: a widget may read preferences but not identity - and nothing goes to the network without approval

The asks are deliberately kept small: everything essential has been proven with today's Plasma. The points on the right would turn KADAI from an add-on into a citizen of the platform - and they are exactly the questions anyone asks who thinks of Plasma as the target shell for automated, personalized workplaces.

6 · Where things stand - honestly

Proven, running

  • Seed → ceremony → encrypted kernel → greeted, reconciled desktop (16 and 29 August 2026)
  • Joining on a running Ubuntu: download a package, assistant, passphrase, desktop (2 October 2026, an old notebook, first real run)
  • Three machines at once: changes are merged per entry, what cannot be decided becomes a proposal instead of an overwrite (since 26 September 2026)
  • Keys in the security chip: Secure Enclave on the Mac, TPM in the VM; a separate sync key without presence; file keys only where there is no chip, and said so
  • Keyring and vault as KeePass files next to the kernel: system accesses for the machines, the person's own passwords for the person alone (2 and 3 October 2026)
  • Kernel sync: local save every ten minutes, push at login, logout and hourly; git history as audit log; repository on an own server (Forgejo)
  • Reconciler (idempotent) and storage tier against Nextcloud (offload, restore, pin, logged)
  • Declarative desktop: specification in the repo, every machine compiles itself at login; today the specification knows activities, colour and panel widgets, nothing more
  • Subsidiary router with two models and a provider behind consent, KRunner as the entrance, the rail at the right edge (lab machine, September 2026)
  • Judging instance in the router: features of the input, ceiling from data class, kernel rule and pins, "better" as a verdict, review with pins in the rail (4 and 5 October 2026, lab machine)
  • Provider access in the keyring instead of a file per machine: all three machines reach the same top rung (5 October 2026)
  • Kernel and code on an own server (Forgejo), all three machines moved there (2 to 5 October 2026)

Design, still open

  • Module runtime via MCP with manifest and sandbox
  • Model and rail on every machine, not only in the lab; automatic episodic entries at session end, deletable at any time
  • The person identity on hardware: a FIDO key instead of the passphrase, then the phone; disk encryption in the seed
  • Deriving the desktop specification directly from the kernel (still handwritten and very short today)
  • Windows formats via a build pipeline; iOS client for the conversational tier; the vault on the phone
  • Observed data as a synced layer of its own: today append-only logs per machine, not synced; derived state is recomputed per machine
  • Observed data outside the kernel, in a store of its own that me:// points to - the file holds instructions only
  • A small local checker that judges whether the task was met in substance; today only form and the person check
  • One entrance for every distribution: a start script that recognises Debian, openSUSE, Fedora or Arch and pulls in what fits; today a package for Ubuntu
  • The "script" class with an agent engine in the sandbox that writes and tests workflow scripts for Activities
KADAI is a project by Jan Mühlig. The architecture is documented in kadai-architecture.md (layers, decisions, open questions), the seed handbook in kadai-seed.md; the kernel prototype me.example.md shows the format. Kernel, keyring and scripts live in a private git repository on an own server (Forgejo), the seed images on Nextcloud.