# AI Augmentation — Exploration

> **Status:** Exploration, not a commitment. Captured 2026-06-27 from a strategy
> conversation. The conclusion is folded into [`SOUL.md`](../../SOUL.md) (_Local-Only by
> Default_ and _Not an AI tool_); this memo keeps the _reasoning_ — including the security
> analysis behind rejecting browser-stored keys — so a future "should we add AI?" session
> doesn't re-derive it.
>
> **Question:** Most tools shipping in 2026 carry some AI/LLM augmentation. Should
> Astrolabe?
>
> **Short answer:** No — and the user benefit, not purity, is the reason. With no server,
> no account, and no AI, nothing the user makes is handled by a third party, so Astrolabe
> is safe for confidential and work data from the first chart. "Everyone ships AI in 2026"
> is the weakest possible reason to add it: ubiquity makes AI table-stakes noise, not
> differentiation, and a tool that demonstrably keeps your data on your machine is
> differentiated _because_ it resists the trend.

---

## 1. Where AI would genuinely fit, if ever

Two spots where Vega-Lite is actually painful and rules can't help but a model could:
natural-language authoring (NL → spec) and explaining/decoding the editor's opaque
validation errors. The obvious third — "recommend a chart from my data" — is **already
solved deterministically** by the Chart Builder's rule-based inference, and the rule-based
version is better here because it's explainable and runs locally. So the genuine surface is
narrow.

## 2. Why browser-stored BYO keys were rejected

The only AI model consistent with "no server, no account" is bring-your-own-key, called
direct browser → provider (never proxied through a server we run, which would put us back in
the data-custody business). The blocker is key storage:

- A browser has **no secure vault for a secret you must read back**. localStorage,
  IndexedDB, cookies — all readable by any same-origin JS, devtools, and extensions. Client
  encryption only helps if the unlock secret isn't _also_ stored, i.e. a passphrase typed
  each session; a key kept beside its ciphertext is theater.
- The dominant threat is therefore **same-origin script execution (XSS)**, and Astrolabe is
  unusually exposed to it: it renders arbitrary user specs through vega-embed, whose
  expression evaluator and data loader are a real script-execution / exfiltration surface.
  Holding a secret in that origin upgrades any spec-driven bug from "annoying" to "steals
  the user's key." **Introducing a stored secret raises the threat level of the whole app,
  the chart renderer included** — the opposite of what the privacy posture exists to do.
- The one mitigant: LLM keys are revocable and spend-cappable, so the blast radius is "bill
  abuse until you rotate it," not data loss. That's why the industry tolerates browser BYOK
  at all — but it doesn't undo the origin-coupling above.

**If AI is ever revisited:** the only acceptable form is a **session-only** key (held in
memory, never persisted, re-entered each session) called browser → provider direct, with the
core staying fully functional and offline for anyone who never engages it. Persisting the
key is the specific part that compromises the posture.