System design overview

OOMU is a native macOS application. Not a website in a wrapper, not a thin client over an API. That single decision explains most of what follows.

---

The shape of it

The interface has no filesystem access, no network access, and no database access. Everything it does, it asks for. That constraint is what makes the rest of the design possible: there is exactly one place to enforce anything.

---

A turn, end to end

1. The decision

Before any language model writes a word, System 1 reads your request. It is Bosun v3.1, a 0.6-billion-parameter model running locally on Metal, and it does exactly one thing: score a short list of options (answer in this conversation, read a file, search the web, add a reminder, run a command, coordinate several steps, and so on) and hand back the most likely one, with the probability of each. It reads up to 8,192 tokens and writes nothing.

The decision is recorded with the model's SHA-256, the probabilities, and the time it took. An @ tag replaces this step: when you name the capability, OOMU does not second-guess you.

The router never writes your answer.

2. The route

What happens next depends on the decision and on the gates in Where policy is enforced:

• An answer goes straight to the assistant, locally on Gemma 4 or on your cloud model if the chat allows it, and streams as it is written. No planning pass.
• One clear action goes straight to that capability. The assistant fills in the details, which are validated against the capability's schema before anything runs.
• Anything larger is planned: the assistant is given the capabilities it may use and works through them.

Context that arrived from a web page, a document, or a tool result is kept apart from what you typed, all the way through the turn.

3. Execution

If the decision proposes capabilities, each one goes through the same sequence:

Resolve → describe the effect → execute → verify the postcondition → write a receipt.

Resolve turns model-supplied arguments into canonical, checked ones: a real path with its device, inode, and modification time; a real element from a real observation; a real bundle identifier.

Describe produces an effect descriptor (reversibility, externality, privilege level, blast radius, data classes, and an idempotency key) and digests it.

Execute runs the native executor. Nothing generic; each capability has its own.

Verify runs a postcondition verifier that looks at the world and reports what it observed.

Receipt records all of it, including whether the postcondition actually held.

An autonomous turn may take at most eight tool steps before it must produce an answer.

4. Synthesis

Only then does a language model write prose (locally on Gemma 4, or on your connected cloud model) with the verified results as its material.

5. Commit

The turn is written with its request digest, result, and result digest. The activity record is completed with a receipt count and an evidence digest, or failed with a category. The usage ledger records whether it ran locally or in the cloud, and the token counts.

---

Where policy is enforced

The gates are in the engine, and all of them are checked before anything leaves the machine.

Note which axis each one sits on. Access to your machine is macOS's decision. Data leaving your machine is OOMU's, and OOMU gates it in the engine.

---

Why device permissions belong to macOS

Beta 1 built a second permission system on top of the operating system: a file sandbox, a permission broker, trust policies with resource budgets, a capability gatekeeper. It was more machinery, and it was worse.

It was worse because it created a second, unfamiliar security surface. Users had to reason about OOMU's permissions and macOS's. Two systems can disagree, and when they do, the more permissive one wins. And an in-app dialog in front of every action produces exactly one behavior: people click through.

So for device access, OOMU defers to the operating system, and every native macOS permission is enforced: one prompt, in macOS's voice, at the moment the feature needs it, managed afterwards in System Settings alongside every other application, and revoked there the same way. Settings → Connections & Apps → Mac access reports what macOS has granted across ten categories; it does not grant anything itself.

That is a division of labour, not an absence of gating. OOMU governs the axis macOS does not cover, which is what leaves: Air-Gap Mode, each project's cloud access policy, and any organization policy are evaluated in the engine before a route is chosen. The one action that can do anything a shell can, running a command, is shown to you in full and runs only when you approve it.

And OOMU keeps the parts macOS does not do at all: identity binding on every resolved resource, postcondition verification on every action, and a receipt for each one.

---

The pieces

Storage

One database, encrypted with SQLCipher, keyed from the Keychain, verified as encrypted at open. Constraints in the schema make illegal states unrepresentable: a completed activity record without evidence is refused by the database itself.

Secrets are not in the database. They are in the Keychain, referenced opaquely.

Concurrency

Worker threads park in blocking receivers rather than polling, so an idle OOMU consumes no background CPU. Scheduled work sleeps until an exact deadline.

Work done on its own

Anything OOMU runs without you watching, a scheduled workflow today, runs inside a fence. Inside it, a step that only reads runs normally; a step that writes a text, Word, or Excel file is redirected into a private holding area, Ready for review; and any other change is refused before it reaches native code. The fence is enforced where actions execute, not in the interface, so no prompt or page content can talk its way around it.

A file leaves the holding area only when a person approves it, on the Mac or through a bound Slack or Discord channel. Both go through the same code: an atomic move that never replaces an existing file, then a hash check at the destination. Every decision is appended to an approval history that has no update or delete path.

Outside the window

Two processes can run besides the main app:

• Mochi is a second window of the same app, transparent and always on top. It has no powers the main window lacks; asking Mochi runs an ordinary turn.
• The background service, oomu-daemon, is a separate signed program inside the app bundle, installed as a per-user launch agent only after you agree to it. It runs Mochi's standing interests and the overnight memory update while the app is closed, checks power and temperature before heavy work, and talks to the app over a local socket that only your account can reach. It opens no network listener, and it does not run Slack or Discord.

Recovery

On startup, the engine reconciles. Expired routine leases are released. Reserved workflow steps are reset. Steps that were mid-execution are quarantined as Check required, because their outcome cannot be verified. All of it is logged.

Nothing unverifiable is reported as done or as failed.

Extension

Three narrow doors, each with a different trust model:

None of them can widen the capability manifest.

Identity

Beta 4 is fully namespaced: bundle ai.eldris.oomu.gpd.beta4, its own Keychain service, its own model cache, its own single-instance lock, its own update channel, its own Quick Launcher shortcut and Browser Bridge port, so it can sit beside a Beta 3 copy without either one touching the other. On first launch it imports a Beta 3 installation's data one way, reading and never writing the old database or Keychain, and verifying every table it copies against the original before it records the import as done. It does not read Beta 2 or Beta 1 data.

---

Design commitments

---

Related

• Evidence & receipts: the verification model in detail.
• Privacy & security: where your data lives.
• Application Bridge API: the boundary layer.
• How OOMU picks a model: the router in detail.