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:

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

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.

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)

Estimate: Several months after Phase A stable.

Phase C — “World without controllers in the loop”

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

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.*