# Anakai Kai Coaching Mode — Implementation Handoff for Terry

> The graph in your hands is a behavioural contract. You pick the implementation tech; the graph tells you what Kai must do.

## What this is

We've extracted (eventually) seven chapters of a network-marketing playbook into a structured behavioural graph. Each node is something Kai cares about — a state the user is in, a behavioural loop he runs, a principle he leans on, an anti-pattern he watches for, or a script he uses. Each edge encodes how those things connect.

The graph is the contract: implement Kai so that for any valid user state, his observable behaviour matches the graph along every path. How you get there — retrieval, MCP, state machine, fine-tune, hybrid — is your call, not ours.

You don't need to study the source book. We've done that work and paraphrased it into our own language; everything you need is in the artifacts we ship.

## The five things Kai reasons about

Think of Kai as a coach who has memorised the playbook and watches the user. The five units of his reasoning:

**user_state** — where the user is right now in their journey. "Decided to develop the skill." "List is shrinking faster than it's growing." "Running an active daily-add habit." Kai detects state from user signals or session memory.

**loop** — what Kai does when a state is active. Each loop has named steps and produces a transition to a new state. Loops are the actionable units.

**principle** — the *why*. Framework lessons paraphrased into our language. Principles back loops; they're what Kai falls back on when the user asks why something matters.

**anti_pattern** — what the user instinctively does wrong. Kai watches for the signals and fires the corrective principle when he detects one.

**script** — operational dialogue. Specific phrasings Kai uses in invitation, follow-up, edification, objection handling. Each script implements a specific step of a loop. We re-author scripts in the synthesised top-KOL voice; the source's beats are the framework, the words are ours.

**dialogue** (added in schema v1.1) — a worked transcript walking one loop end-to-end in Kai's voice, with every Kai turn tagged to the loop step, principle, or anti-pattern correction it performs (`turns[].tag`). Authored for Roma's operational-truth review, but directly useful to you too: each turn is persona-conformant and graph-tagged, which makes dialogues ready-made few-shot voice exemplars for generation. Treat them as reference material, not a sixth runtime reasoning unit.

## How the pieces connect

Ten typed relationships, each with a direction. The full list lives in `protocols/edge-cheatsheet.md`; the relational layer is materialised as KG triples per `protocols/kg-predicates.md`. The ones you'll touch most often:

- `triggers` (state → loop) tells you "when the user is here, these loops are available to fire."
- `transitions_to` (loop → state) tells you "completing this loop moves the user here."
- `backed_by` (loop or script → principle) is the *why* link.
- `corrects` (principle → anti_pattern) and `vulnerable_to` (state → anti_pattern) together tell you which traps to watch for and how to coach the user out of them.
- `implements_step` (script → loop.step) is the precise attachment of a phrase to a step in a loop.

There are five more — `precedes`, `depends_on`, `paraphrase_of`, `edifies` — fully documented in the cheatsheet. Treat the ten as your relational vocabulary.

## What Kai does in real time — a walkthrough

Picture a user who's just joined. Kai's first job is to figure out where they are. He sees signals — what they say, what data your system has, prior session memory — and matches against state `entry_criteria`. He lands on `S-skill-committed` (carry-through from intro chapter).

Kai queries the graph: "what loops `triggers` from `S-skill-committed`?" Two come back from ch.1: `L-01-01` (comprehensive list dump) and `L-01-04` (network on purpose). The list-dump loop is foundational — it's a one-time pass. Kai opens with the loop's first step, drawing his line from the loop's `kai_voice_draft` field (or from an attached script if one exists for that step).

The user starts dumping names. Kai watches the input. If they say "wait, this person wouldn't be a fit" — that's the signal for `AP-01-02` (pre-disqualification). Kai fires the principle that `corrects` it: `P-01-02` (capture without filter). The corrective is voiced in the same persona register.

When the user finishes producing a list, the loop completes. Its `transitions_to` edge says: move to `S-has-static-list`. Kai updates the user's state. Now a new set of loops is available — and the new state carries its own `vulnerable_to` edges to other anti-patterns to watch for.

That's the entire pattern: detect state, pick loop, walk steps, watch for anti-patterns, transition state. The graph supplies the answer at every decision point. Your job is to implement the loop.

## The voice rule

Kai never sounds like the source book's author. He sounds like a synthesised top-KOL operator — direct, warm without effusion, asks before assuming, diagnoses before prescribing. The persona document at `voice/kai-voice-persona.md` is normative. Every `kai_voice_draft` field on every node was written against that persona's positive and negative vocab lists.

When you generate Kai's responses, constrain to those lists — or fine-tune on them, or prompt with them as guardrails. The discipline is simple: knowledge from the book, voice from us. We never quote or attribute the source's author user-facing. Internal `source_ref` fields on each node hold short grounding snippets for review only — never surface them to users.

## What we own vs what you own

We own the contract — the graph, the persona, the per-chapter validations. We don't pre-decide your stack. You can implement Kai as pure retrieval over the markdown, as a state machine with the graph as the transition table, as an LLM with structured prompts pulled from MemPalace drawers, or as a hybrid that routes stats queries to your MCP backend and how-to / emotional queries through the graph. Anything goes as long as the observable behaviour matches.

What you cannot do is implement Kai so that he contradicts the graph. The graph is what Roma and Maks ratify; deviation is a bug, not a feature.

## What you'll receive

For each chapter:

- A markdown file at `chapters/0X-name.md` with every node fully specified — title, body, internal `source_ref`, `kai_voice_draft`, voice context tags, all linked relations, type-specific extras.
- The same content as MemPalace drawers, one drawer per artifact, tagged by `artifact_id`. Retrievable via `mempalace_search` with a tag filter, addressable from the body's first line.
- KG triples for every edge, using the ten predicates we registered for you.
- A FigJam canvas — visual reference, not source of truth.
- A gap-list — every paragraph in the source either becomes a node or carries one of six canonical tags explaining why it didn't. This is the coverage guarantee.
- An adversarial review flag log — every issue surfaced during quality review and how it was resolved.

Plus the standing assets:

- The spec (`spec.md`) — frame and contract terms.
- The protocols — extraction, edges, workflow, voice persona, MemPalace and KG conventions.
- The chapter template — the field schema.

## What's done, what's coming, what's open

Done and pending validator signoff: ch.0 "Intro — A Better Way" and ch.1 "Finding Prospects". Ch.0 was fully rebuilt and scope-extended on 2026-06-11: it now covers source pp.9–28 (the Introduction PLUS the book's three framing chapters) and carries the why-this-profession case — the Perfect-Career-List comparison, the New-Economy argument, the poser/amateur/professional frame — plus the Go-Pro decision loop. That makes ch.0 Kai's onboarding layer, not just framing: 17 nodes (3 states / 2 loops / 8 principles / 4 anti-patterns / 2 dialogues), 25 edges, and its `L-00-02` (Go-Pro decision) hands off directly into ch.1's `L-01-01` via a `precedes` edge. Ch.1 is unchanged: 19 nodes + 5 dialogues, 43 KG edges. Both chapters passed multi-pass independent adversarial review (ch.0: 18 flags across 4 passes, all resolved) and machine schema validation (0 failures). Dmitry's editorial pass on the rebuilt ch.0 and the Roma/Maks validation handoff are queued.

Coming: chapters 2 through 7. Chapter 2 (Inviting) will be the heaviest on scripts — the source's invitation patterns are operational and detailed, and we'll likely emit five to ten script nodes with register variants for warm / cold / family / professional markets. Subsequent chapters follow the same pipeline.

Three open items you should know about:

**State entry without a loop.** Some states are entered by Kai detecting `entry_criteria` from user signals, not by a loop's `transitions_to`. `S-running-low-on-names` in ch.1 is the canonical case — the list shrinks naturally with use, no loop puts the user there. Your state-detection layer needs to support both paths: graph-internal transitions and external observation matching the entry criteria.

**Forward references.** The graph will have `precedes` edges pointing to loops in chapters not yet extracted (e.g., `L-01-05 precedes L-02-XX`). We log these as pending in each chapter's lessons-learned doc and emit the KG triples retroactively when the target chapter lands. Don't be alarmed by placeholder ids.

**Schema staircase.** Resolved — `schema/v1.1.json` (JSON Schema draft 2020-12) is canonical and machine-loadable; v1.1 adds the Dialogue node type over v1.0, no breaking renames. The markdown view stays human-readable for editorial work. One tooling caveat: the bundled `tools/validate-chapter.py` still loads v1.0 and does not parse the `# dialogues` section (dialogues were validated against v1.1 separately); a validator upgrade is queued before ch.2.

## What we'd like from you

A short integration note when you're ready, answering four questions:

- How will your runtime detect user state? (Graph-internal transitions are mechanical; external `entry_criteria` matching is the one that needs design.)
- How do you plan to query the loops-from-state graph at runtime? (MemPalace KG search, in-memory cache, embedded JSON — whatever fits your stack.)
- How do you select between a principle-backed coaching move and a script-backed response? (The graph distinguishes; your selection layer needs the signal.)
- How will you constrain generation to the voice persona? (Prompt guardrails, fine-tune, post-filter — your call.)

If any of these have gaps in our artifacts, tell us early. We'd rather amend the protocols now than carry ambiguity into ch.2 and beyond.

That's the handoff. The graph is the contract; you pick the implementation. We'll keep extracting chapters and ratifying with the validators; you tell us when you need a different shape of artifact than what we're producing.