Back to corpus
proposalexperiment writeup candidatescore 30

KARL Integration — Evolution³ / Stage 1: PATH D

Abandon regex-based skill routing entirely. Embed every skill and every incoming prompt into a shared vector space. When a new prompt arrives, find the nearest skill by **trajectory-weighted similarity** — not raw text overlap. The "learning" is not RL on model weights (that is KARL's full treatment). It is RL on the **routing layer itself**. Skills stay as SKILL.md markdown. The only thing that changes is which skill gets injected, and that decision is made by a vector space whose distances are continuously update

Open full HTMLDownload HTMLCorpus JSONPaper schema

Full HTML reader

Read the full artifact

Open in new tab

Extracted abstract or opening context

# KARL Integration — Evolution³ / Stage 1: PATH D **Run:** karl-trajectory-intelligence **Path:** D — Skill Embeddings: Learned Vector Space for Routing **Generated:** 2026-03-10 **Status:** Stage 1 complete **Run Directory:** Desktop/evo-cube-output/karl-trajectory-intelligence/ Abandon regex-based skill routing entirely. Embed every skill and every incoming prompt into a shared vector space. When a new prompt arrives, find the nearest skill by **trajectory-weighted similarity** — not raw text overlap. The "learning" is not RL on model weights (that is KARL's full treatment). It is RL on the **routing layer itself**. Skills stay as SKILL.md markdown. The only thing that changes is which skill gets injected, and that decision is made by a vector space whose distances are continuously updated by observed trajectory success rates. This is "KARL for routing" rather than "KARL for reasoning." It replaces the regex `\b(error|bug|crash)\b` in `ops_trigger.py` with a learned function that has been shaped by 324 invocation records and counting. Before designing the replacement, establish exactly what we are replacing and why it fails. | Skill | Trigger Pattern | |-------|----------------| | ops:debug | `\b(error|bug|crash|fix|debug|broken|trace)\b` | | ops:deploy | `\b(deploy|restart|systemctl|cloud-vm)\b.*\b(flow|service|hub)\b` | | ops:ios | `\b(bootstrap|xcodebuild|archive|testflight|ipa|simulator)\b` | | ops:git | `\b(commit|push|merge|rebase|cherry-pick)\b` | | ops:supabase | `\b(migration|rls|supabase|table|schema)\b` | | ops:prefect | `\b(prefect|flow|deployment|schedule)\b` | | ops:monitoring | `\b(grafana|prometheus|metric|dashboard|alert)\b` | | ops:mesh | `\b(mac[1-5]|mesh|tailscale|sync)\b.*\b(status|check|health)\b` | | ops:docker | `\b(docker|compose|container|image)\b.*\b(build|restart|up|down)\b` | | ops:asc | `\b(app store|asc|screenshot|submission|review)\b` |

Promotion decision

What has to happen next

Attach run IDs, datasets, metrics, and reproduction commands.

Why this is not always a full paper yet

Corpus pages are public-safe readers for discovered workspace artifacts. They are not automatically final papers. A corpus item becomes a polished paper only after the editable source, evidence checkpoints, references, figures, render path, and release status are attached through the paper schema.