# KAI Release Readiness — Multi-User / World-Facing Assessment

> **Codex v9.10.64** · **Track 2** · Codex §Comprehensive Plans (Phases A/B/C)  
> **AI / low-credit:** One milestone (e.g. A1) per session; on stop log `Last worked` / `Next`.

**Date:** June 28, 2026  
**Context:** Ryan (Owner/Creator) and Taz (Co-lead) are **controllers**, not KAI’s only audience. Discord, the dashboard, and public-chat routes exist so KAI can talk to **many people** — with identity and clearance, not “Ryan ID or nobody.”

**Related docs:** `KNOWLEDGE-RESEARCH-GOAL-HANDOFF.md`, `The KAI Codex.md`, `tools/oracle-discord/shared/identities.mjs`

---

## Correction on prior framing

An earlier assessment wrongly implied KAI was a **single-operator lab tool** where only Ryan talks to him. That’s inaccurate.

**What’s actually built:**

| Layer | Purpose |
|-------|---------|
| **Discord fleet** | KAI, Leo, Groq, Gemini, Claudey, X, Analyst, Researcher, Oracle — public and scoped channels |
| **`HUMAN_REGISTRY`** | Ryan (Owner), Taz (Co-lead), Guests — each with Discord ID, role, transcript channel, voice slot |
| **`resolveIdentityFromMemory()`** | Unknown users resolved via lattice query → default **Lattice Guest** |
| **`/api/oracle-turn` + `user_id`** | Per-user cellularized lattice memory (`store_or_reinforce_with_vec`) |
| **`user-warehouse.mjs`** | Per-user facts, fingerprints, deduped drawers |
| **Multi-user dashboard registry** | Per-Discord-user tokens, server-assigned roles (owner mints; client never self-asserts role) |
| **Role gates** | e.g. Analyst accepts instructions only from Oracle / Ryan / KAI — not from arbitrary users |

Ryan and Taz **control policy and architecture**; the interfaces are **already multi-user by design**.

---

## What “release to the world” means here

Not “Ryan stops touching the repo.” It means:

1. **Anyone** can reach KAI through a public interface (Discord, web, future apps).
2. KAI **knows who he’s talking to** (identity + role), not just “Ryan vs everyone else.”
3. **Capabilities scale with clearance** — chat for guests, tools/plans only for trusted roles.
4. **Unpredictable inputs** (trolls, jailbreaks, wrong facts, crises) are handled without breaking trust or safety.
5. **Ops run without manual rescue** for every failure (supervisor restarts are a start, not the finish).

---

## Readiness scorecard (honest, June 2026)

Scale: **0** = not started · **1** = prototype · **2** = works in fleet for known users · **3** = beta-ready · **4** = production · **5** = world-scale

| Area | Score | Notes |
|------|-------|-------|
| **Multi-user identity (known humans)** | **2** | Registry + per-user memory work for Ryan, Taz, guests. `getIdentityById` bugfix shows this was fragile and mattered. |
| **Multi-user identity (strangers)** | **1** | Unknown IDs → Lattice Guest + lattice lookup. No OAuth-verified onboarding doc in production path; dashboard notes Discord ID is owner-asserted. |
| **Per-user memory isolation** | **2** | `user_id` on oracle-turn + user-warehouse. Shared lattice still mixes global knowledge — cross-talk risk for public scale. |
| **Role / clearance enforcement** | **2** | Analyst gate exists; fleet bots differ (public-chat vs ipc). Not one unified policy engine across all surfaces. |
| **Conversational quality (known topics)** | **3** | RSHL, version, gratitude, doc research — verified v9.10.63. |
| **Conversational quality (open world)** | **1** | Long-tail prompts still hit generator noise, gaps, or wrong lattice hits. |
| **Epistemic honesty** | **2** | Traps, truth calibration, gaps — good for tests; not proven under adversarial pressure at scale. |
| **Tool autonomy (shell/file/web)** | **1** | Powerful for operators; must stay gated for guests. Public tool surface not hardened as a product. |
| **Moderation / abuse** | **1** | Oracle moderator routes exist; no full public abuse playbook verified. |
| **Reliability / SLO** | **2** | Supervisor, autosave, RAM recycle — lab-grade. Probes show 60–90s paths on some queries. |
| **Observability & rollback** | **1** | Logs, eco.log, probes — no automated “quality dropped → rollback” for replies. |
| **Legal / ToS / privacy** | **0–1** | Proprietary IP; multi-user warehouse implies data duties not fully productized. |

**Composite (world-facing, unsupervised): ~1.5 / 5**  
**Composite (Discord + dashboard, known community + guests, controllers watching): ~2.5 / 5**

---

## Distance in plain language

### Already there (for your intended Discord/community use)

- KAI can talk to **Ryan, Taz, guests, and strangers** with identity hooks.
- Fleet gives **multiple personas and channels** — not a single-user CLI.
- Controller layer (Ryan + Taz + Oracle) can **approve plans, gate Analyst, mint dashboard users**.

### Not there yet (for “anyone on the internet, no one watching”)

- **Stranger identity** is guest-by-default, not verified trust tiers (friend, collaborator, public).
- **Clearance is inconsistent** across Rust oracle, Node bots, and dashboard (string matching on `from` in places).
- **Memory** is per-user in places but **one shared brain** — public users can pollute or extract global lattice context.
- **No proven adversarial suite** (jailbreak, prompt injection via docs, social engineering through Leo voice).
- **No product SLO** (latency, uptime, “KAI must answer X% without gap”).

---

## Milestones to “world-ready” (ordered)

### Phase A — Community beta (controllers present, dozens–hundreds of users)

**Target:** Discord + dashboard open to invited public; Ryan/Taz/Orcle moderate; no expectation of full autonomy.

| # | Milestone | Done when |
|---|-----------|-----------|
| A1 | **Unified identity pipe** | Every surface sends `user_id` + resolved role into oracle-turn; KAI prompt includes “You are talking to {name}, role: {role}” from `identities.mjs`, not hardcoded Ryan/public split. |
| A2 | **Clearance matrix** | Written table: Guest / Partner / Owner / AI — who gets chat, voice, tools, lattice write, plan propose. Enforced in one middleware. |
| A3 | **Guest-safe mode** | Default public path: no shell, no arbitrary file read, web research rate-limited, lattice writes tagged `source=discord-guest`. |
| A4 | **Probe suite × N users** | Same 5 knowledge probes + 10 adversarial probes (jailbreak, trap, PII fishing) per role — all logged. |
| A5 | **Incident runbook** | Bad reply → mute user / roll back binary / purge cell region — documented and rehearsed once. |

**Estimate:** Achievable in **weeks–few months** with focused fleet hardening (mostly Node + oracle_server policy, not new architecture).

### Phase B — Public beta (thousands, light moderation)

| # | Milestone | Done when |
|---|-----------|-----------|
| B1 | **Verified identity optional** | Discord OAuth or signed tokens link dashboard user ↔ Discord ID (fix “owner-asserted” gap). |
| B2 | **Per-user + global memory policy** | Guests read global RSHL/docs; writes go to sandbox region; promotion to global requires controller or confidence gate. |
| B3 | **Moderation pipeline** | Pre-send filter + post-send audit sample; crisis phrases → scripted handoff, not lattice improv. |
| B4 | **SLOs** | p95 reply < 15s for routed paths; 99% engine uptime with supervisor metrics exported. |
| B5 | **Research ingest loop** | Doc research hits optionally ingested as weak cells with source tag (closes “answers once, forgets” gap). |

**Estimate:** **Several months** after Phase A stable.

### Phase C — “World without controllers in the loop”

| # | Milestone | Done when |
|---|-----------|-----------|
| C1 | **Policy-bound autonomy** | KAI can act alone only inside explicit policy (no implicit tool use). |
| C2 | **Automated quality guard** | Canary prompts every N minutes; auto-rollback on regression. |
| C3 | **Legal/privacy package** | ToS, retention, export/delete per `user_id`, regional compliance decision documented. |
| C4 | **Red-team program** | External adversarial testing before each major version. |

**Estimate:** **Year+** unless scope is ruthlessly narrow (e.g. “RSHL doc oracle only, read-only, no memory writes”).

---

## Identity model (how KAI should verify who can talk)

**Today (simplified):**

```
Discord message
  → user_id (snowflake)
  → identities.mjs: HUMAN_REGISTRY hit?
       yes → Ryan / Taz / Guest (known role)
       no  → resolveIdentityFromMemory() → lattice query → role guess or "Lattice Guest"
  → oracle-turn { from, text, user_id }
  → lattice store cellularized by user_id
  → routing / gates (varies by bot and target)
```

**Gaps for world release:**

1. **`from` string trust** — display names can spoof; **`user_id` must be the root of trust** everywhere.
2. **Split prompts** — some paths still use `Ryan@Public` vs “member of the public” instead of registry role.
3. **Unknown users** — default guest is correct; **upgrade path** (Taz adds someone to registry, or OAuth) needs a product story.
4. **AI vs human** — `AI_REGISTRY` exists; impersonation (“I am Ryan”) needs consistent rejection unless `user_id` matches.

**Recommendation:** One sentence in every KAI turn context:

> “Speaker: {name} (Discord {user_id}), role: {role}, clearance: {level}.”

Built from `getIdentityById` / `resolveIdentityFromMemory`, never from nickname alone.

---

## What controllers (Ryan + Taz) still do — and should

| Controller job | Release without them? |
|----------------|------------------------|
| Architecture & version shipping | Eventually automated CI; not yet |
| Adding trusted humans to registry | Becomes self-serve admin UI or OAuth |
| Approving Oracle plans / Analyst tasks | Policy engine + audit log |
| Watching fleet health | Supervisor → alerting → on-call rotation |
| Cultural tone / crisis judgment | Moderation models + runbooks — partial only |
| Legal accountability | Never fully automated |

**World release ≠ Ryan disappears.** It means **Ryan and Taz set policy** while **KAI serves everyone within that policy** without per-message manual control.

---

## Recommended near-term path (aligned with your setup)

1. **Treat Discord + dashboard as the real “release surface”** — not a hypothetical app store launch.
2. **Finish identity unification (Phase A1–A2)** — biggest gap between “built for many” and “safe for many.”
3. **Guest-safe default** — assume every unknown `user_id` is unpredictable; controllers override upward.
4. **Expand probes** — role × prompt matrix in `probe_transcript.py` (owner, taz, guest, stranger).
5. **Keep controllers in the loop for Phase A** — world-facing with **human oversight**, not **human-only audience**.

---

## One-line summary

KAI is **architecturally aimed at a multi-user world** (Discord, identities, per-user memory, roles) — not a Ryan-only toy. He is **not yet ready** for unmanaged global traffic, but he is **much closer to a controlled community release** (invited public + guests + controller policy) than to a from-scratch public chatbot. The main gap is **unified identity/clearance enforcement and guest-safe defaults**, not “having Discord at all.”

---

*Maintainers: update this doc when identity middleware, clearance matrix, or probe suites ship. Sync version references with `Cargo.toml` / Codex masthead.*