# KG Predicate Mapping — Behaviour Graph v0 **Wing:** `pivot_salepoint` **Room:** `kai_coach_kb` **KG schema version:** forward-only additions registered 2026-06-09 **Registered by:** Task 9 of the Behaviour Graph v0 prep plan --- ## Mapping Table All 10 Behaviour Graph edge types are NEW registrations. None of the 39 existing canon predicates carry equivalent semantics — the existing schema covers project/team/Jira metadata and has no behavioural or pedagogical predicates. (Canonical edge taxonomy: see spec §3.2 and `protocols/edge-cheatsheet.md`.) | Our edge | KG predicate | Subject type → Object type | Definition (1-line) | Status | |---|---|---|---|---| | `triggers` | `triggers` | `user_state` → `loop` | State activates loop; detecting this state makes the loop available to fire | NEW | | `transitions_to` | `transitions_to` | `loop` → `user_state` | Completing the loop moves the user to this state | NEW | | `backed_by` | `backed_by` | `loop` or `script` → `principle` | Loop or script is grounded in this principle (the explanatory *why*) | NEW | | `corrects` | `corrects` | `principle` → `anti_pattern` | Internalising this principle breaks this anti-pattern | NEW | | `vulnerable_to` | `vulnerable_to` | `user_state` → `anti_pattern` | Users in this state are susceptible to this anti-pattern | NEW | | `precedes` | `precedes` | `loop` → `loop` | First loop's completion is a natural on-ramp to the second (typical, not mandatory) | NEW | | `depends_on` | `depends_on` | `principle` → `principle` | Dependent principle assumes prerequisite principle is already internalised | NEW | | `implements_step` | `implements_step` | `script` → `loop.step` | Script fills a specific named step-slot within a loop | NEW | | `paraphrase_of` | `paraphrase_of` | `script_variant` → `script_canon` | Variant script with adapted register, market, or language; same structural purpose | NEW | | `edifies` | `edifies` | `loop` or `script` → external actor | Loop or script performs the NM edification move, targeting an external actor outside the graph | NEW | --- ## Why no existing predicates were reused **Note on count vs. spec.** Spec §6 named 4 predicates as expected new registrations (`edifies`, `precedes`, `implements_step`, `paraphrase_of`). The remaining 6 (`triggers`, `transitions_to`, `backed_by`, `corrects`, `vulnerable_to`, `depends_on`) were confirmed absent from the live canon schema at registration time (see live `kg_stats` snapshot below) and are therefore new registrations as well. Total: 10 new predicates, not 4. This is a discovery, not a scope expansion — the spec's count was an estimate based on best-effort mapping; reality required all 10. The closest candidates reviewed: - `unblocks` — directional but carries dependency semantics (task A unblocks task B), not state-activation semantics. `triggers` is directionally similar but the semantic register is different enough to warrant a distinct predicate. - `supersedes` — might seem related to `corrects` (one thing replaces another), but `supersedes` describes version succession; `corrects` describes the principle-to-anti-pattern remediation relationship (conceptually different, different subject/object types). - `is_a` / `is` — could have been mis-used for `paraphrase_of`, but these are taxonomy predicates (type membership), not script-variant relationships. - `contains_task` — superficially similar to `implements_step`, but it goes container → task (composition), not script → loop.step (realisation). - `depends_on` — this one is a fresh registration. No prior `depends_on` existed in canon; the existing predicates encode task/Jira dependencies only by convention (not formally named `depends_on`). Confirmed via `kg_stats` before registration. --- ## Per-Predicate Detail (all new) ### `triggers` - **Subject type:** `user_state` (id format: `S-`) - **Object type:** `loop` (id format: `L-XX-YY`) - **Definition:** When Kai detects the user is in this state, this loop is available to fire. The state is the pre-condition; the loop is the behavioural response. - **Bootstrap triple:** `S-newbie-no-list triggers L-01-01` - **Edge cheatsheet card:** `protocols/edge-cheatsheet.md § triggers` ### `transitions_to` - **Subject type:** `loop` (id format: `L-XX-YY`) - **Object type:** `user_state` (id format: `S-`) - **Definition:** Completing the loop moves the user into this state. The loop is the activity; the user_state is the outcome. - **Bootstrap triple:** `L-01-01 transitions_to S-has-list` - **Edge cheatsheet card:** `protocols/edge-cheatsheet.md § transitions_to` ### `backed_by` - **Subject type:** `loop` (L-XX-YY) or `script` (Sc-XX-YY) - **Object type:** `principle` (id format: `P-XX-YY`) - **Definition:** The loop or script is grounded in this principle. The principle is the *why* — it explains the design intent, not a step to execute. - **Note:** `backed_by` originates from either loops or scripts (two valid subject types). When querying, expect to see both. - **Bootstrap triple:** `L-02-01 backed_by P-01-03` - **Edge cheatsheet card:** `protocols/edge-cheatsheet.md § backed_by` ### `corrects` - **Subject type:** `principle` (id format: `P-XX-YY`) - **Object type:** `anti_pattern` (id format: `AP-XX-YY`) - **Definition:** Internalising this principle is the corrective for this anti-pattern. The anti-pattern exists precisely because the principle has not yet landed. - **Bootstrap triple:** `P-01-03 corrects AP-01-03` - **Edge cheatsheet card:** `protocols/edge-cheatsheet.md § corrects` ### `vulnerable_to` - **Subject type:** `user_state` (id format: `S-`) - **Object type:** `anti_pattern` (id format: `AP-XX-YY`) - **Definition:** Users in this state are tempted toward this anti-pattern; the state creates conditions under which the wrong move feels natural. - **Bootstrap triple:** `S-first-invite-sent vulnerable_to AP-01-03` - **Edge cheatsheet card:** `protocols/edge-cheatsheet.md § vulnerable_to` ### `precedes` - **Subject type:** `loop` (id format: `L-XX-YY`) - **Object type:** `loop` (id format: `L-XX-YY`) - **Definition:** First loop's completion is a typical on-ramp to the second loop. Ordering is typical, not mandatory — the user can enter any loop when the triggering state exists. - **Bootstrap triple:** `L-01-01 precedes L-02-01` - **Edge cheatsheet card:** `protocols/edge-cheatsheet.md § precedes` ### `depends_on` - **Subject type:** `principle` (id format: `P-XX-YY`) - **Object type:** `principle` (id format: `P-XX-YY`) - **Definition:** The dependent principle assumes the prerequisite is already internalised. Without the prerequisite, the dependent principle will not land for the user. - **Bootstrap triple:** `P-02-01 depends_on P-01-03` - **Edge cheatsheet card:** `protocols/edge-cheatsheet.md § depends_on` ### `implements_step` - **Subject type:** `script` (id format: `Sc-XX-YY`) - **Object type:** `loop.step` (id format: `L-XX-YY.step-N-