Governance layer for personal AI — persistent memory, policy-bound actions, full audit trail.
01 Overview
Orlix is not an AI assistant. It is the control layer that sits above any assistant — observing your context, enforcing your policies, executing tasks, verifying outcomes, and updating its own behavior from results.
The key distinction: assistants generate text. Orlix governs outcomes. You configure what matters, what is permitted, and how autonomous the system should be. Orlix operates within those bounds continuously.
architecture overview
┌─────────────────────────────────────────┐
│ your goals · policies · memory │
│ ↓ orlix ↓ │
│ observe → decide → act → verify → learn│
│ ↓ │
│ claude / gpt / gemini / any model │
└─────────────────────────────────────────┘
Core principles
Local-first
Your world model, policies, and receipts live on your machine. No cloud lock-in, no silent sync. You can export everything at any time.
Bounded autonomy
Orlix never decides how much power it has — you do. Authority is declared up front and enforced by the runtime, not by the model's judgement.
Auditable by default
Every action writes a receipt before it runs, linking intent → policy → outcome. Nothing happens off the record.
Model-agnostic
Claude, GPT, Gemini, or any OpenAI-compatible endpoint. Swap the brain without losing memory or policies.
Who it's for — builders and operators who want an AI that does things reliably: manages goals, watches for drift, and acts within limits you can prove — not just a chat window.
02 Installation
Orlix is distributed as a single binary for macOS, Linux, and Windows. Early access builds are provided to members of the access program.
macOS / Linux
shell
curl -fsSL https://get.orlix.dev | sh
✓ orlix v0.5.0-beta installed at /usr/local/bin/orlix
Ask Orlix to do something. It observes, decides, acts, and verifies — writing a receipt at each step. Under the default supervised tier it acts and notifies you, with rollback available.
shell
orlix run "review my open goals and flag anything stalled"
[act] priority alert queued · receipt r-0912 written
[verify] alert delivered · goal re-surfaced ✓
Next — raise or lower Orlix's autonomy any time with Authority tiers, and review exactly what it did under Action receipts.
04 Governance loop
Orlix runs a five-phase loop continuously. Each phase is configurable — you can set the authority tier per phase, per domain, or globally.
01 observe
Watches your calendar, goals, inbox signals, and external sources. Feeds the world model in real time. Never stores raw message content — only extracted, policy-compliant facts.
02 decide
Weighs observed signals against your goals and policies. Determines what — if anything — should happen next. Checks authority tier before proposing any action.
03 act
Executes the decided action — or requests approval if the authority tier requires it. Every action is written to the receipt log before execution, not after.
04 verify
Checks whether the action achieved its stated goal. Not just "was it sent" but "did it work." Discrepancies are flagged and held for review.
05 learn
Updates policy from real outcomes. Every policy change is versioned and requires explicit confirmation unless you've pre-authorized the update class. building
05 Authority tiers
The authority tier controls how much autonomy Orlix has. Set it globally or per domain (e.g. email, calendar, files).
observe
Log activity only. Orlix watches and records — nothing else. Zero risk of unintended action.
suggest
Recommendations only. Orlix surfaces suggestions; every decision is yours.
confirm
Orlix asks before acting on anything, no exceptions.
supervised ← default
Orlix acts, notifies you immediately, and can roll back within 30 days. Recommended starting point.
autonomous
Orlix acts independently within policy bounds. Receipts are logged but no approval required. Use only after establishing trust through supervised operation.
Start supervised. Run at supervised for a week and read your receipts. When a class of action has been consistently right, promote just that domain to autonomous — everything else stays governed. Trust is earned per-domain, not all at once.
06 Memory system
Orlix maintains a living world model — a structured graph of facts, goals, preferences, and relationships. Everything is stored locally, versioned, and exportable.
Memory types
facts
Discrete beliefs about the world. Each fact carries a source, confidence score, and timestamp. Example: "Alex owns the design review · source: email · 2026-06-02 · confidence: 0.95"
goals
Objectives you care about, with optional deadlines and progress tracking. Goals drive the observe and decide phases.
policies
Rules that govern Orlix behavior. Versioned — every change is tracked. Roll back to any previous version with orlix policy --rollback v12.
preferences
Soft preferences that bias decisions without hard-blocking them. Example: "prefer async communication over meetings."
Export and import
shell
orlix memory --export--outorlix-backup.json
✓ exported 1,204 facts · 7 goals · 14 policies
orlix memory --importorlix-backup.json
✓ world model restored · 1,204 facts · 7 goals
07 Action receipts
Every action Orlix takes or proposes generates a receipt — a structured record linking the action to the intent, policy, and verification result.
orlix receipts --show2026-06-13-0847# view one receipt
orlix receipts --rollback2026-06-13-0847# undo this action
08 Policies
Policies are the rules Orlix follows. They are versioned, auditable, and can be evolved manually or (in v0.5) automatically from outcomes.
shell
orlix policy --list# show all active policies
orlix policy --add"notify_if_blocker_gt_48h"
orlix policy --disablep-0003# disable by id
orlix policy --rollbackv12# restore previous version
Anatomy of a policy
A policy is a when → then rule scoped to a domain and bound to an authority tier. It is data, not code — versioned and inspectable.
policy · p-0014
id = "p-0014"
when = "goal.blocked_for > 48h"
then = "notify(priority: high)"
domain = "goals"
tier = "supervised"# act + notify, rollback available
version = 14
Conflicts are explicit. If two policies would fire opposite actions, Orlix does not guess — it holds the action and surfaces the conflict for you to resolve. Safety beats silent resolution.
09 CLI reference
orlix init
Initialize a new Orlix instance in the current environment.
orlix status
Show the current state of the world model, policies, and audit log.
orlix goal
add, list, update, remove — manage your goal registry.
orlix memory
--export, --import, --search, --forget — manage the world model.
orlix policy
--list, --add, --disable, --rollback, --set-tier
orlix receipts
--list, --show, --rollback — view and manage action audit log.
orlix run
Execute a single governed task. Orlix will observe, decide, act, and verify — logging a receipt.
orlix --version
Print version string and exit.
orlix --help
Print help for any subcommand.
10 Configuration
Orlix reads ~/.orlix/config.toml on startup. The most important settings:
[models] # override the model per phase (optional)
decide = "claude-opus-4-8"
observe = "claude-haiku-4-5"# cheaper for high-volume scanning
// changes are hot-reloaded — no restart needed. Run orlix config --check to validate before saving.
11 Integrations
Orlix connects to external services through policy-controlled adapters. Each adapter has its own authority tier setting.
AI models
Anthropic Claude, OpenAI GPT, Google Gemini, and any OpenAI-compatible endpoint. Swap models without losing your memory or policies.
Calendar
Google Calendar, Apple Calendar, Outlook. Orlix reads events to update goals and context. v0.1
Email
IMAP/SMTP compatible. Orlix extracts facts from messages you authorize — never stores raw email content. v0.1
Tasks
Linear, Notion, GitHub Issues. Bidirectional sync with your goal registry. v0.3
Files
Local filesystem access within configured paths. Read and write under supervised or confirm tier. v0.3
// all adapter credentials are stored encrypted in ~/.orlix/credentials — never transmitted to Orlix servers.
12 Security & privacy
Orlix is built so that trusting it doesn't mean giving up control of your data. The defaults are private; the guarantees are structural, not promises.
Local-first
The world model, policies, and receipts live in ~/.orlix on your machine. Nothing is uploaded unless an adapter you enabled requires it.
Encrypted secrets
Adapter credentials and API keys are encrypted at rest in ~/.orlix/credentials and never written to logs or receipts.
PII redaction
With redact_pii = true, emails, tokens, and identifiers are stripped before any text reaches a model provider.
No raw content
Orlix stores extracted facts, not source material. It keeps "Alex owns the review," not the email it came from.
Reversible by default
Actions stay rollback-eligible for the configured window. If something's wrong, undo it from the receipt — no cleanup required.
Telemetry off
Usage telemetry is opt-in and disabled by default. You can run fully offline for everything except model calls.
Threat model in one line — a compromised or prompt-injected model still can't exceed your authority tier or reach your secrets, because those limits are enforced by the runtime outside the model's reach.
13 B20 token deployment
An Orlix agent can deploy a B20 token on Base by submitting a deploy intent — a name and a symbol. The agent never touches a private key: it describes what it wants, and Orlix constructs, signs, and broadcasts the transaction on its behalf.
This follows the same guardrail model as the rest of Orlix — authority is enforced before an action can run, not left to the agent's own judgement.
Enclave signer
The signing key is generated inside a Turnkey secure enclave (HSM/TEE) and never enters Orlix memory, disk, or logs. Orlix only holds an API key that authorizes remote signing. custodial
Deploy allowlist
Only agents whose key is on the allowlist may deploy. The check runs in the signing proxy, before the key is ever reached — a prompt-injected or compromised agent cannot bypass it.
Chain lock
B20 is Base-only. Agent deploys always target Base mainnet; nothing else is signable through this path.
Receipts
Every deploy returns a broadcast tx hash and the deterministic token address — logged like any other agent action.
// full request/response schema, parameters, and status codes live in the API reference. The signer wallet pays gas, so it must hold ETH on Base.
14 FAQ
Is Orlix just another AI chat wrapper?
No. A chat wrapper generates text. Orlix governs outcomes — it holds goals and policies, acts within limits you set, verifies results, and logs every step. The model is one component, not the product.
Does my data leave my machine?
Only what a model call needs, and only after PII redaction if enabled. Your world model, policies, and receipts stay local in ~/.orlix. See Security & privacy.
Which model should I use?
Any. Orlix is model-agnostic — Claude, GPT, Gemini, or any OpenAI-compatible endpoint. You can even use a cheaper model for high-volume observe and a stronger one for decide (see Configuration).
What happens if Orlix does something wrong?
Every action is reversible for the configured window. Open the receipt and roll it back — orlix receipts --rollback <id>. Because receipts are written before execution, there's always a record to undo from.
Can a prompt injection make it go rogue?
It can't exceed your authority tier or reach your secrets. Those limits are enforced by the runtime, outside the model — the same design behind B20 token deployment's deploy allowlist.