How to read this page.

Most technical pages blur what ships into what's imagined. This one doesn't. Every claim below carries one of three labels, and I hold myself to them. If you find a claim on this page that the code doesn't support, tell me and I'll change the page.

• Documented documented It runs today, in the current build. You could read the code that does it.
• Built, not yet active not yet active The code exists and works, but something outside the code stops it from switching on. I say what.
• Vision vision The direction. Not written, not shipped, not promised on a date. Treat it as intent, not roadmap.

Inverted orchestration. documented

Most apps send your data to a server that does the thinking. Arkhelion inverts that. A Rust engine on your own machine holds the keys and does the work. The interface is a renderer: it displays JSON and issues prompts, and it never stores a key, never holds your record, and never attaches a key to a request. That all happens in Rust. The company is architected out of the loop, which is why I can say I can't read your data without asking you to take my word for it. There is no server of mine in the path.

This is the whole design. Everything below is a consequence of it.

The vault. documented

• A file you own Your vault is a single SQLite file on your Mac. There is no cloud database, no sync service, and no account. A separate local database holds diagnostics and logs. It is not encrypted, and it never leaves your machine.
• Encrypted at rest The vault file is SQLCipher-encrypted, keyed from your Keychain. The stock sqlite3 command on your own Mac cannot open it, which is the plainest demonstration that the encryption is real rather than declared.
• A second layer, same key Two internal columns, the memory store's values and its embeddings, carry a second AES-256-GCM envelope inside the already-encrypted file. Both layers derive from the same Keychain secret, so this is depth against a flaw in one cipher layer, not independent key material. Your health entries, biometrics, and conversation turns are protected by the file-level layer.
• Encrypted backups Full-file AES-256-GCM snapshots to a destination you choose at setup. Encrypted before they leave, so the destination never matters. A rolling thirty days are kept.
• Deleting it Delete the vault file and your backups folder and the product's memory of you is gone. Backups are encrypted snapshots kept for thirty days, so delete those too if you mean it. Nothing is held anywhere else.

The keys. documented

• Generated on your machine On first run your Mac generates a 256-bit key from the operating system's random source. It is never transmitted, and it never existed anywhere else. I have no copy and no way to make one.
• Held in your Keychain The key lives in the macOS Keychain, under your login, protected by the same system that protects your passwords. You hold it. I never do.
• Handled carefully in memory While in use the key is pinned in RAM on a best-effort basis, keeping it out of the swapfile where the OS permits. If that syscall is denied the app warns and continues, so treat it as a strong default rather than a guarantee. Firming it waits on the same certificate as Touch ID below. It is wiped from memory the moment it is dropped rather than left for the next process to find.
• Yours to lose Onboarding shows the key once, for you to write down on paper. That is the one moment the interface sees it. If you lose it, your vault is gone and I cannot recover it. That is not a gap in the design. That is the design, and it is the honest cost of the promise.

Touch ID unlock. not yet active

The reason is mundane. macOS only lets an app create a biometric-protected Keychain item if the app is signed with a real Apple Developer ID, and Arkhelion is currently signed ad-hoc because the certificate is deliberately the last thing I buy before shipping to strangers. Until then the biometric step cannot fire, so it is not part of what protects you today.

Two precisions worth having. When it does switch on, it gates the unlock screen, not the key itself: the vault key item is deliberately non-biometric so background work can run without prompting you every time. And what protects your vault today is the encryption at rest and your Keychain, which is a meaningful line but not the same claim. When the certificate lands, this switches on and this page changes to say so.

The Council. documented

When a question deserves more than one opinion, several models answer it independently and a chairman reads them all and writes the decision. It is slower and it costs more, which is exactly why it is reserved for questions that earn it.

• The deliberation Three Claude Sonnet members answer: an analyst, a synthesist, and an adversarial verifier. Each receives the same prompt and none sees another's work, so they cannot converge by copying. The first streams to your screen while the other two run behind it.
• The auditor A fourth member checks answers against live web context and defends your local data when the two disagree. It engages only when live web context is present, which needs a search key most installs won't have. Without one it abstains, so assume three.
• The chairman A Claude Opus chairman reads them all and writes the answer.
• The fast path Ordinary questions route to a single fast Claude model instead. Not everything is a board meeting.
• Where Google comes in Deciding which path a question takes is itself a model call, and today that classifier runs on Google if you add the optional Google key, which means it sees your prompt. With no Google key the classifier is skipped and everything escalates to the Council on Anthropic. The quick-answer box also runs on Google and needs that key. The Council itself never does.

Your keys, your account. documented

The AI runs through your own API key, held in your Keychain and attached to the request inside the Rust engine. You paste it once at setup and the interface drops it immediately; from then on it never sees it again. The request goes from your machine straight to the provider. It does not pass through anything of mine, because I do not run a server for it to pass through.

On providers, precisely: Anthropic and Google are what the engine speaks to today, because I picked the models. You choose the account and the key, not yet the vendor. Adding providers is a config change rather than an architectural one.

Telemetry. documented

None. No analytics, no usage tracking, no phone-home. The app does not report what you did, when you opened it, or that you exist.

Precisely, because this page is for people who check: a crash reporter is compiled into the binary, and it is inert. It only ever transmits if it is handed a reporting address at launch, and the distributed build does not carry one, so there is nothing for it to send anything to. I use it against my own development builds, where the address comes from my own secret store and never ships. There is no auto-updater and no analytics SDK. If that ever changes, it will be opt-in and it will be stated here first.

The on-device model. vision

The endpoint of the argument is a model that runs entirely on your machine, so that no prompt leaves at all and no key is needed to use the product. Here is exactly how far that is, because this is the claim it would be easiest to fudge.

An on-device inference engine is written, and it does one job: it runs a small local model over your own text to pull structure out of it. What is not written is the path that would route your questions to it instead of to a cloud provider. Every answer today goes to a cloud model through your key. The model weights don't ship, the local path is off unless explicitly enabled, and it wants more memory than my own development machine has.

So: real code, not a shipped feature, and not the thing that would make your questions stay home. I am not going to call it live because a file exists. When it answers an ordinary question on an ordinary machine, it moves up this page.

What's actually in it.

Arkhelion is one core with separate pillars on top of it. Health and Agenda are modules over the same engine and the same vault, which is what lets the intelligence read your recovery data against your calendar. That join is the whole point, and it is what a second app can never do. Here is the full list and the truth about each.

• Health documented Your body and your calendar, read together. Connect an Oura ring to populate it. This is the wedge and the most finished thing here.
• Council documented The multi-model deliberation described above, as a place you can go and ask.
• Command Hub documented The home base. The screen that knows your day.
• Omnibar documented Type anywhere to jump to any pillar or run any command. Its free-text quick answer runs on Google and needs the optional Google key; navigation and commands don't.
• Agenda in progress Calendar and tasks as context for everything else. Reachable and wired to a real backend, and empty until you connect a calendar.

Today you get those five. Finances, Academics, and Faith have code written but are deferred as off-thesis for this version: they are hidden and not reachable in the current build, and I would rather list them here as deferred than let a sidebar screenshot contradict this page. Choosing which pillars you run, and building your own, is vision and not a setting that exists.

The threat model.

A security claim is only worth what it names as out of scope. Here is both halves.

• Holds against A stolen or lost Mac: the vault is encrypted at rest and the key is in the Keychain. A breach of my infrastructure: there is no server of mine holding your record, so there is nothing to take. A subpoena served on me: I cannot produce what I never had. Me changing my mind, or being acquired: the architecture, not my good intentions, is what stops it.
• Does not hold against Your own Mac, compromised while you are logged in: at that point the attacker is you, and no local app survives that. Losing your key with no paper backup: your vault is unrecoverable, by design. The cloud provider you chose: they see the prompts you send them, and the vault slice sent with them. A determined attacker with physical access, your password, and time.
• The one server I do run A waitlist endpoint, which is how you probably got here. It holds the email you gave me and nothing else. The app never talks to it: no part of the product calls home to me. I would rather enumerate it than let you find it.
• Not yet true Biometric unlock is not active, for the certificate reason above. The swap guarantee is best-effort for the same reason. Nothing here has been through a third-party security audit. It is built by one person, and one person is a real limit on assurance, whatever the architecture says.

Where this goes. vision

None of this section ships. No code for it exists yet. It is the direction, and it is why the parts above are built the hard way. Every sentence here is conditional on purpose.

It would propose, you would approve, and only then would it act.

The long-term shape is an intelligence that does real work: drafting the message, booking the trip, preparing the appointment. The line that would never move is who authorises it. There would be no autonomous mode and no "it learned your preferences, so it went ahead." Propose-you-approve is the entire contract, and it would have to hold precisely when approving is inconvenient, or it is not a contract.

Every action would carry a record.

Each approval would be recorded cryptographically on your device: what was proposed, what you authorised, when, and what was then done. The record would be local, yours, and verifiable. You could prove what you consented to, and you could prove what you did not.

Accountability rules for AI are coming, and they converge on one question: can you show the human authorised this? Most architectures cannot answer, because consent was a checkbox at signup and the action happened on someone else's server. This one would answer structurally, because consent would be per-action, provable, and held by you. That is not a compliance cost paid later. It is the reason the thing would survive the rules.

The context would already know you.

Every assistant today starts each task as a stranger. It asks your dates, your budget, your size, your constraints, because it has never met you and won't remember you after. Arkhelion would hold the context already, so the task would start knowing you: travel that knows you won't take the 6am and who is coming with you. Meals that know what you are avoiding this month. Health that knows your own timeline better than any intake form you will ever fill in.

That value would belong to you. It would live in your vault, under your key, and it would leave with you if you go. The advantage is that nobody can offer the same thing without the same architecture. It is not that anyone is trapped.

How this gets built.

The order is deliberate: win the wedge with people whose health is complex and unresolved, then widen. The architecture above is already the general thing. It is pointed at one problem first on purpose, because breadth is what kills a solo build. That is also why three pillars are sitting deferred rather than half-shipped.

If this reads as underclaiming, that is the intent. I would rather you find this page conservative and be surprised later than find it impressive and be disappointed.