Copy: state the AI-free stance as a confidentiality benefit; record the exploration

docs/exploration/README.md

@@ -15,3 +15,4 @@ snapshots, not live numbers.
 - `chart-builder-enhancement-scope.md` — consolidated Tier-B → Tier-C forward plan for the Chart Builder.
 - `chart-theming-scope.md` — chart theming plan and slice breakdown.
 - `monetization-and-sync-exploration.md` — monetization + BYO-cloud-sync direction memo.
+- `ai-augmentation-exploration.md` — why Astrolabe stays AI-free, and the key-storage security analysis behind it.

docs/exploration/ai-augmentation-exploration.md

@@ -0,0 +1,53 @@
+# 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.