ActiveMind

About the system

ActiveMind is a personal AI assistant system the author built himself on a computer that runs 24 hours a day. It is not a product and offers no service to anyone else; only the author uses it.

Its goal is simple: let AI actually do work for a person, while keeping the consequences of an AI making a mistake — or being tricked — inside a controlled boundary. The whole system was built in rounds by several AI contractors following published governance rules (see the Tools page), with the author making every decision.

Words in bold with a dotted underline are this system's own names for its parts.

Three design principles

Intelligence on top, certainty below

Models that can be wrong only sit in the upper layers, suggesting and doing specific work. What actually changes the system are fixed-rule programs underneath, which do not rely on model judgment.

Safety never depends on a model

Checks, alerts, blocking and key verification are all fixed rules. If a model breaks or is tricked, the safety line is still there.

Rules, not trust

No component is assumed trustworthy. What each step may do is written down in advance and locked.

Three permanent rules

1. Cloud models never touch the plain text of any key.
2. The Steward never relies on a cloud model for core logic.
3. The cloud side may never enter the system layer.

Layers

From top to bottom: the lower, the more deterministic and the less dependent on models.

Owner

Reads reports, approves or rejects, and gives instructions from a phone. Every important action is finally decided by a person.

Key Proxy

The only program in the system that can read keys. Other programs can only say “which key, for what”; it checks the request and does the job itself, and never hands the key over.

Steward (local model)

An open-source model running on the machine itself, offline. It does Inspection, raises alerts, rates the risk of every action and chats with the Owner. It only watches and judges; it never acts.

Worker Assistant (cloud model)

A stronger cloud model working inside an open-source agent framework: reading and writing files, running commands, searching the web. It can only touch its own workspace and must pass the Safety Gate before every action.

Script Skills

Routine, scheduled jobs (Daily Brief, video digests and so on) written as fixed scripts that run on time without any cloud model.

Kernel Layer

A few programs at the very bottom, run as the system administrator and locked: the only Executor, the File Registry (every key file has a fingerprint; any change raises an alert), Phone-Code Authorization and Self-Healing Maintenance.

Operating system

User-account separation, file permissions and file locks keep all the layers above apart.

Safety Gate

1. Before every action, the Worker Assistant hands “who, which tool, doing what” to the Gatekeeper.
2. The Gatekeeper first applies hard blocks (for example, writing outside the workspace). Everything else goes to the Steward for a risk rating: low risk passes; medium and high risk go to the Owner's phone and wait for approval.
3. Commands outside the allowed list also pass the agent framework's own Second Approval. Two walls: if one fails, the other still stands.
4. If the Gatekeeper is not loaded correctly, Self-Healing Maintenance stops the Worker Assistant outright — better idle than unguarded.

What it can do now

Inspection and alerts

Regular checks of key-file fingerprints, lock status, running services and any plain-text keys. Anything abnormal is pushed to the phone immediately.

Daily Brief

Every morning, system status and what the Worker Assistant did in the past 24 hours, summarised in one message.

Memory Curation

Every day a local model turns the previous day's conversations into a diary and picks items worth remembering long-term; only the items the Owner selects are written into long-term memory.

Video Digest Pipeline

Checks subscribed channels on a schedule, transcribes new videos on the machine, writes summaries and files them in a knowledge base. No paid models involved.

Local Transcription

Voice messages are turned into text on the machine and never uploaded to any cloud.

Knowledge base search

The Worker Assistant can search the knowledge base (video digests and so on) to answer questions, citing its sources. Whatever it finds is treated as material, never as instructions: any “please do X” inside it is not carried out.

Work Assistant (sub-project)

A separate phone assistant that helps the author record and organise everyday matters. It has its own account and rules and does not go through the Worker Assistant.

Home network (sub-project)

Devices at home reach the internet through an encrypted tunnel. If one exit fails it switches to the next; if the whole tunnel fails, the computer falls back to the ordinary line and a notice is pushed to the phone.

Not built yet

• Change Ticket: fill in a ticket and confirm with a phone code before changing the system (designed, not built).
• Emergency Mode: a plan for swapping the brain and freeing the hands when something goes wrong (reserved, not built).

How it was built

The system is built in rounds by AI contractors. Each round starts by proving identity and tool access, and ends with a handover log entry and a version bump.

Three documents, one job each: the governance manual (rules and decisions), the system manual (where things are, how to use them, how to fix them) and the handover log (who did what, and when).

These handover rules are published as a general edition on the Tools page (contractor-handover).

This website follows the same rules: the deployment token is held only by the Key Proxy, only the Owner can publish a new version from a terminal on his own computer, and version fingerprints are checked before and after.

For security reasons this page does not publish file locations, system accounts, network ports, how keys are stored, rule lists or the accounts used.