Building a Privacy-First AI Assistant for Windows — The Directive Architecture
Every AI assistant I've ever used made the same assumption: the intelligence lives somewhere else.
Alexa. Siri. Cortana. Google Assistant. Beautiful products. All built on the same architecture: your device is a terminal. The brain is a server. Owned by a company. Governed by a terms of service that can change on a Tuesday afternoon.
I wanted something different. So I built it.
What is E.L.L.A.?
E.L.L.A. — Embedded Local Logic Agent is a local AI assistant for Windows. It runs on your machine. It manages files, reads your Outlook and Gmail, controls your system, plays music, sets reminders, scans your network, prepares meetings, and responds to voice commands — all without requiring a cloud subscription.
The LLM backend is Ollama (llama3.1:8b locally, with OpenAI GPT-4o as an optional fallback the user consciously enables). The database is MariaDB — local, no remote access. 85 tools, 205 passing tests.
But none of that is the interesting part.
The Problem With AI Safety Policies
Most AI safety frameworks are built on rules.
"Don't do harmful things."
"Respect user privacy."
"Don't exfiltrate data."
Rules can be broken. Through prompt injection. Through configuration errors. Through a developer who adds "just a temporary exception." Through a company that updates its terms of service.
A rule is a promise. Promises dissolve.
I wanted something that couldn't dissolve.
The Directive — Architectural Impossibility, Not Policy
The E.L.L.A. Directive is not a ruleset. It is an architectural constraint.
Four prohibitions. Hardcoded. Evaluated before anything else runs. No prompt, no configuration, no rule can override them — because no code path exists that bypasses them.
DirectiveLayer.check(tool) → deny if harm / exfiltrate
evaluateRules(tool) → deny if explicit deny rule
evaluateRules(tool) → allow if explicit allow rule
no_match → deny (default-deny)
toolExecutor.execute(tool) → only reached on allow
Prohibition I — No Harm
E.L.L.A. cannot execute any action that causes physical, digital, or financial harm to the user, their system, or third parties.
Implementation: DIRECTIVE_DENY — a hardcoded Set of tool names that are evaluated before the rule engine runs. These tools do not exist for the LLM. They cannot be called.
Prohibition II — No Concealment
E.L.L.A. cannot delay, hide, or falsify information with intent to deceive.
Implementation: Every tool execution is fully logged to tool_executions. No background processes without user awareness. The frontend shows every tool used, as a chip under each response.
Prohibition III — No Surveillance
E.L.L.A. cannot observe, track, or build profiles about the user without explicit consent.
Implementation: The memory system is exclusively local (MariaDB). Default-deny as a technical pattern — no tool observes anything that isn't explicitly registered.
Prohibition IV — No Exfiltration
E.L.L.A. cannot transmit user data, system data, or communications to external servers — except on explicit, conscious user request.
Implementation: All inference runs locally via Ollama. OpenAI GPT-4o is only invoked when the user deliberately enables it, with full awareness that text is leaving the device boundary.
Why "Impossibility" Changes Everything
The difference between "we promise to protect your data" and "it is technically not possible to send your data" is not semantic. It is architectural.
When no code path exists that exfiltrates data, no prompt can activate that path. When a tool is absent from the system entirely, the LLM cannot call it — regardless of how cleverly a prompt injection is constructed.
This is what Isaac Asimov described as the Three Laws of Robotics. Not as science fiction — as an engineering specification. The E.L.L.A. Directive is a proof of concept that those laws can be implemented. Not as interpreted rules. As structure.
The Rule Engine — Flexibility Within Constraints
Above the Directive, E.L.L.A. has a configurable rule engine. Users can create allow and deny rules for any tool, with conditions based on time, disk usage, RAM, and other system state.
Rule: deny "format_drive" always → user explicitly blocks it
Rule: allow "shutdown_system" after 23:00 → conditional permission
Rule: deny "*" when disk_usage > 90% → wildcard deny
The rule engine is flexible. The Directive is not. Rules exist within the space the Directive allows. They cannot expand that space.
What's Next
E.L.L.A. is not on the market yet. The architectural foundations are real and implemented. The installer is in development.
The Directive itself is published as a separate open repository: github.com/AndreZ1971/The-E.L.L.A.-Directive-
The principles apply beyond desktop assistants — to any autonomous system that executes actions in the real world. Web agents. Industrial automation. Humanoid robots.
If you're building something that acts, the question isn't "what rules should it follow?"
The question is: "what should it be architecturally incapable of doing?"
E.L.L.A. is built by Andre Zabel. Follow for updates.
Top comments (0)