From da48b0d40c35efe76f6b3408154e5353b124496a Mon Sep 17 00:00:00 2001 From: MaximEdogawa Date: Sat, 18 Apr 2026 21:00:27 +0200 Subject: [PATCH] feat: add Pengine manifest documentation - Introduced a new SOUL.md file outlining the purpose, architecture, and trust model of Pengine. - Described the separation of capabilities into isolated components and the importance of user control over automation. - Provided a clear framework for understanding trust layers and their implications for security and user choice. --- SOUL.md | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 SOUL.md diff --git a/SOUL.md b/SOUL.md new file mode 100644 index 0000000..1d30b95 --- /dev/null +++ b/SOUL.md @@ -0,0 +1,36 @@ +# Pengine manifest + +## Why we exist + +Pengine is for people who host their own assistant—for example with Telegram and carefully chosen add-ons—and want real help without quietly handing the assistant more power than they meant to. You should always know what only you can change versus what the model is allowed to do, so automation stays useful without the model widening its own risk—and so sensitive credentials can stay tied to this device and your physical presence when you decide they should. + +## How to think about Pengine + +Pengine is a router, not one big lump of software. + +Capabilities are split into many small, separate boxes. Each add-on (for example a file helper) typically runs in its own container with tight limits: optional no network, CPU and memory caps, and only the folders you explicitly allowed, mounted in predictable places (such as under `/app/...`). + +- Boxes do not talk to each other. They only exchange structured work with the host over a simple pipe from the host process. +- The only places things come together are Pengine itself (the host app: orchestration, HTTP, desktop shell) and the conversation the model sees (tool results in one thread). + +If two boxes share data—same database or same folder mount—that is your explicit choice. It is not "boxes discovering each other." + +## Trust in layers (not "pricing tiers") + +Think bronze, silver, and gold as how deep the trust goes and how strong the isolation is—not as product packages. + +| Layer | What it is | Rule of thumb | +| --- | --- | --- | +| Bronze | Model output | Untrusted text. It must never directly become "change who is allowed to do what" or rewrite security. | +| Silver | Tool calls | Allowed only against a fixed, reviewed surface: built-in tools plus allowlisted add-on images you chose. | +| Gold | Policy | Only you, through the app: folder access, which add-ons exist, install/uninstall from a catalog. The model does not get a hidden path to widen this—unless you deliberately add a narrow native "install this approved image" capability and accept the extra prompt-injection risk that comes with it. | + +## The line we draw + +- You own trust, mounts, catalogs, and credentials when you want them device-bound and presence-aware. +- The model operates inside the lane you already defined—silver, not gold. +- Bronze stays bronze: suggestions and answers are not automatic policy. + +## In one sentence + +Pengine connects helpful automation to your life in small, bounded pieces—so power flows through your choices, not through whatever the model happens to ask for next.