Routx Vocabulary
SPEC_ROUTX_VOCABULARY.md
CGNT-1 Interface Specification — ROUTX Keyword Vocabulary
Status: SPECIFIED
Version: v2.0
Author: VELA (Thread #13) / C.L.O.D. (verified v2.0)
Conceived by: NOUS
Date: 2026-04-20
Verified: 2026-04-20 — all keywords tested live against routx_engine.py + 18 modules
Depends on: SPEC_ROUTING_ARCHITECTURE.md, SPEC_TOOL_LAYER.md
PURPOSE
ROUTX is a KEYWORD ROUTER, not a semantic AI. It matches the first recognizable word in a query to a module. If no keyword matches, the query falls to Tier 2 (MNEMOS — slow, 30 seconds, may hallucinate) or Tier 3 (escalation — returns ◌).
Every failed query that people blame on "ROUTX is broken" is actually "I used a word ROUTX doesn't recognize."
This spec is the dictionary. Use the words in this dictionary. Stay on Tier 1. Get instant, deterministic, verified answers.
THE RULE
Right keyword → Tier 1 → instant, deterministic, verified
Wrong keyword → Tier 2 → MNEMOS, 30 seconds, probabilistic
No keyword → Tier 3 → ◌
Tier 1 is always right. Tier 2 might be right. Tier 3 is always "I don't know." Stay on Tier 1.
MODULE VOCABULARY
MODULE 1 — GLOSS (Symbol Lookup)
Function: Translates LATTICE symbols to English and English to LATTICE.
Trigger: NOT keyword-based. GLOSS fires when the query contains a LATTICE Unicode symbol (Φ, Ψ, Ω, ◌, ⚒, etc.) OR a crew/module name (NOUS, AION, ASTRA, LATTICE, NEXUS, etc.). The symbol IS the keyword. English words alone don't route to GLOSS.
Keywords: [any LATTICE symbol], [any crew name]
Examples:
"define Φ" → Φ = 0.042 (stability damping) ← Φ is the trigger
"define Σ" → state marker ← Σ is the trigger
"define ◌" → null / unknown / I don't know ← ◌ is the trigger
"translate Φζ.⊤" → stability constant held, verified true
"AION" → crew member profile lookup
"what is LATTICE" → LATTICE crew/concept lookup
Note: "define" alone (no symbol) → Tier 2 MNEMOS. The symbol must be present.
Speed: ⚡ FAST (< 1 second)
MODULE 2 — NEXUS (Deterministic Math)
Function: Exact computation — factoring, solving, evaluation, matrix algebra.
Keywords: factor, solve, matrix, omega, phi, sigma, integrate, derivative, mean, median, sqrt, sin, cos, or any math expression/operator
Note: "compute" and "calculate" alone do NOT route to NEXUS. Use the specific operation word (factor, solve, matrix, etc.) or include a math operator.
Examples:
"factor 42" → 2 × 3 × 7
"solve x^2 - 4" → [-2, 2]
"omega?" → current Ω computation
"1 - 0.084/1.618" → arithmetic result
"matrix eigenvalues [[2,-1],[-1,2]]" → [1, 3]
"matrix determinant [[3,1],[5,2]]" → 1
"matrix inverse [[2,-1],[-1,2]]" → [[0.667, 0.333],[0.333, 0.667]]
"matrix rank [[1,2,3],[4,5,6],[7,8,9]]" → 2
"matrix trace [[2,-1],[-1,2]]" → 4
Speed: ⚡ FAST (< 2 seconds, even for 8×8 matrices)
MODULE 3 — MEDX (System Health)
Function: Reports RAM, disk, CPU, Ollama models loaded, vacuum violations.
Keywords: health, status, ram, disk, cpu, ollama, ports, services, violations, vacuum, memory
Note: "medx" alone routes to GLOSS (crew name). Use medx: prefix or the direct keywords above.
Examples:
"health" → full system health report (RAM, disk, CPU, Ollama, vacuum)
"status" → same as health
"ram" → RAM usage only
"disk" → disk usage only
"cpu" → CPU load averages
"ollama" → loaded Ollama models
"ports" → all listening ports
"services" → CGNT-1 service status
"violations" → vacuum rule violations
"vacuum" → same as violations
"medx: health" → explicit prefix, always routes to MEDX
Speed: ⚡ FAST (< 2 seconds)
MODULE 4 — FORGEX (Forge Pipeline)
Function: Reports brain forge status — active forges, monitor processes, completion signals.
Keywords: forge, brain, training
Note: "colab" does NOT route to FORGEX. "forgex" routes to GLOSS (crew name). Use forge status or the aliases below.
Examples:
"forge status" → active forge processes, latest log entry
"forge last" → last completed forge
"forge queue" → queued forge jobs
"forge history" → forge history
"brain status" → alias for forge status
"training status" → alias for forge status
Speed: ⚡ FAST (< 1 second)
MODULE 5 — SPECX (Specification Metadata)
Function: Queries spec status, counts, audit results.
Keywords: spec [subcommand], specs, specification [subcommand]
Subcommands: audit, count, status [NAME], list, search [term], read [NAME], stale, gaps, conflicts, latest
Examples:
"spec count" → total spec count (currently 147)
"specs" → same as spec count
"spec status SPEC_TMM_FORMULA" → status, version, author, date
"spec audit" → full audit of all specs (SLOW)
"spec search TMM" → specs containing "TMM"
"spec list" → all spec names
Speed: ⚡ FAST for single spec lookup | 🐢 SLOW for audit (reads 147+ files)
MODULE 6 — SIMONX (Trading / Treasury)
Function: Reports treasury balance, trading wall status, position data.
Keywords: treasury, balance, wallet, portfolio, trading, walls, evaluate [asset], position size, kelly
Note: "simonx" routes to GLOSS (crew name). "position" alone routes to SIMONX but needs "position size" for full match. Use simonx: prefix for explicit routing.
Examples:
"treasury" → portfolio status (treasury/sovereignty/challenge)
"balance" → same as treasury
"wallet" → same as treasury
"portfolio" → same as treasury
"trading" → trading agency wall status
"walls" → same as trading
"evaluate EIT.UN.TO" → TMM evaluation for the asset
"evaluate EIT.UN 25.40 26.10" → TMM with entry/current price
"position size" → Kelly criterion position sizing
Speed: ⚡ FAST (< 2 seconds)
MODULE 7 — ENTROPX (Entropy Engine)
Function: Generates entropy, reports entropy system status.
Keywords: entropy, entropx, entropy quick, entropy status, entropy sources, entropy quality, generate N shot, single shot
Note: "random" and "chaos" do NOT route to ENTROPX. "entropy" routes to sources (not NEXUS).
Examples:
"entropy" → entropy sources overview
"entropx" → same as entropy (sources)
"entropy quick" → single entropy shot
"entropy status" → same as entropy quick
"entropy sources" → list active entropy sources
"entropy quality" → quality report on collected entropy
"generate 10 shot" → generate 10 entropy shots
"single shot" → one entropy value
Speed: ⚡ FAST for single shot | 🟡 MEDIUM for multi-shot (2-10 seconds)
MODULE 8 — NISTX (NIST Statistical Testing)
Function: Reports NIST SP 800-22 test suite status and results.
Keywords: nist status, nist audit, nist full, nist quick
Note: "statistical" and "test suite" do NOT route to NISTX. Must use nist [subcommand] form.
Examples:
"nist status" → NIST test suite status
"nist quick" → quick NIST test run
"nist audit" → full NIST SP 800-22 audit
"nist full" → same as audit
Speed: ⚡ FAST for status | 🐢 SLOW for full audit
MODULE 9 — MODEMX (Verified Communication)
Function: Adds _verified: "MODEMX_OK" to every ROUTX response. Not queried directly — implicit on all responses.
Keywords: modemx, modem status, handshake status
Note: "verify" and "verification" do NOT route to MODEMX. MODEMX is primarily passive — its _verified field appears on every Tier 1 response automatically.
Examples:
"modemx" → MODEMX verification layer status
"modem status" → same
"handshake status" → same
Speed: ⚡ FAST
MODULE 10 — INDEX (File Search)
Function: Searches for files on the filesystem by name or pattern.
Keywords: find [name], locate [name], search spec [term], where is [name], recent [N]
Note: "index" routes to GLOSS (crew name). "file" alone falls to Tier 2. "search [term]" routes to LOGX not INDEX. Use find or locate for file search.
Examples:
"find HANDSHAKE" → locates files matching "HANDSHAKE"
"find TMM" → all files with "TMM" in name
"locate entropx" → all entropx-related files
"search spec TMM" → search spec files for "TMM" content
"where is SESSIONS.md" → exact file location
"recent 10" → 10 most recently modified files
Speed: ⚡ FAST (< 2 seconds)
MODULE 11 — LOGX (Log Search)
Function: Searches and tails log files.
Keywords: log tail [name], logs [name], tail [name], search log [term], log search [term]
Note: "logx" routes to GLOSS (crew name). "log" alone does NOT route to LOGX. Log search performs keyword search across log content, not file tail.
Examples:
"log tail mantis" → searches mantis log content
"log tail mantis 24h" → mantis log, last 24 hours
"logs routx" → ROUTX log entries
"tail lobster" → LOBSTER_LOG content search
"search log forge" → search all logs for "forge"
"log search vacuum" → search logs for "vacuum"
Speed: ⚡ FAST (< 2 seconds)
MODULE 12 — COMMX (Crew Messaging)
Function: Broadcasts messages to crew channels.
Keywords: broadcast [msg], alert [msg], notify [msg], send from=X to=Y msg=Z
Note: "crew", "message", "commx" do NOT route to COMMX (commx/crew route to GLOSS). Use broadcast, alert, notify, or the canonical send form.
Examples:
"broadcast system update complete" → sends to all crew (from=κ to=all)
"alert forge complete" → same as broadcast
"notify AION memory retrain ready" → same as broadcast
"send from=κ to=ι msg=forge complete" → direct message to AION
"send from=κ to=all msg=shutdown in 5min" → explicit broadcast
Speed: ⚡ FAST (< 1 second)
MODULE 13 — CRONX (Scheduler)
Function: Reports scheduled jobs and cron status.
Keywords: cron, schedule, jobs, timers, scheduler, job [name]
Note: "cronx" and "scheduled" do NOT route to CRONX. "cron" and "schedule" both map to job list.
Examples:
"cron" → all active scheduled jobs
"schedule" → same
"jobs" → same
"timers" → same
"job mantis" → status of specific job named "mantis"
Speed: ⚡ FAST (< 1 second)
MODULE 14 — LOOPX (Spec Audit Loop)
Function: Runs spec audits, generates draft specs for unspecified engines.
Keywords: loop audit, loop status, loop gaps, loop stale, loop fill, loop drift, loop register
Note: "loopx", "audit", and "gaps" standalone do NOT route to LOOPX. Must use loop [subcommand] form. "loop status" maps to "loop audit" (last audit results).
Examples:
"loop status" → last audit results (alias for loop audit)
"loop audit" → run spec audit
"loop gaps" → show specification gaps
"loop stale" → show stale specs
"loop fill" → auto-generate draft specs (SLOW — reads source code)
"loop drift" → detect spec drift
Speed: ⚡ FAST for status/audit | 🐢 SLOW for fill (reads engine source files)
MODULE 15 — MNEMOSX (Persistence Layer)
Function: Reports persistence status — HANDSHAKE, quartermaster, SESSIONS.
Keywords: mnemos status, mnemos stale, mnemos log, persist status, mnemosx, memory status
Note: "mnemos" alone routes to GLOSS (crew name). "remember" and "recall" fall to Tier 2. Must include a subcommand.
Examples:
"mnemos status" → persistence layer health
"mnemos stale" → stale memory entries
"mnemos log γ" → GAMMA's memory log
"persist status" → same as mnemos status
"mnemosx" → same as mnemos status
"memory status" → same as mnemos status (canonical form)
Speed: ⚡ FAST (< 1 second)
MODULE 16 — AUTHX (Agency Walls)
Function: Checks permission tiers for requested actions.
Keywords: auth [query], permission [action], allowed, permitted, check actor=X action=Y, walls, agency wall
Note: "agency" standalone, "authx" standalone → fall to Tier 2. Use auth [query] or the canonical form.
Examples:
"auth check CLOD trade" → checks if CLOD can trade
"check actor=CLOD action=deploy" → canonical permission check
"check actor CLOD action trade" → space-separated variant
"permission trade" → shows trading agency wall
"allowed" → shows all agency walls
"permitted" → same as allowed
"walls" → same as allowed
"agency wall" → same as allowed
Speed: ⚡ FAST (< 1 second)
TIER 2 — MNEMOS (Brain Synthesis)
Function: When no Tier 1 keyword matches, query falls to MNEMOS (7B local brain). MNEMOS attempts to answer from its training data.
Keywords: None — MNEMOS catches everything that Tier 1 misses.
Behavior: Loads model if not in RAM (cold start: 30-60 seconds). Inference: 5-30 seconds. May hallucinate. Response marked _tier: 2.
Speed: 🐢 SLOW (10-60 seconds) | 💀 WILL TIMEOUT if model not loaded and cold-starting
Rule: Avoid Tier 2 whenever possible. If you find yourself hitting Tier 2, check this vocabulary — there's probably a Tier 1 keyword you should be using instead.
TIER 3 — ESCALATION
Function: When Tier 2 can't answer, query returns ◌ with a suggestion to escalate to Navigator or Sisters.
Keywords: None — Tier 3 is the fallback of the fallback.
Response: {"result": "◌", "suggestion": "Route to Navigator (⊹) or Sisters (ι+ε) for synthesis."}
Rule: ◌ is honest. It means nobody on the ship knows the answer to this query in its current form. Rephrase using Tier 1 keywords, or escalate to a human.
QUERY CONSTRUCTION RULES
Rule 1 — Lead With the Keyword (or the Symbol)
GOOD: "define Φ" → GLOSS catches Φ (the symbol is the keyword)
GOOD: "Φ?" → also routes to GLOSS — symbol alone is sufficient
BAD: "what is phi?" → "phi" is in NEXUS math words → routes to NEXUS
BAD: "define" → no symbol → Tier 2 MNEMOS
For non-GLOSS queries, the English keyword must be the first word:
GOOD: "treasury" → SIMONX
GOOD: "vacuum" → MEDX
BAD: "what is the treasury balance?" → falls to Tier 2
Rule 2 — Keep It Short
GOOD: "treasury" → SIMONX catches "treasury"
BAD: "can you tell me the current treasury balance please?" → falls to Tier 2
Rule 3 — Use Service Prefix for Explicit Routing
If unsure of the keyword, use the service: prefix. This bypasses all classifiers and routes directly:
"medx: health" → MEDX (always, even if keyword is ambiguous)
"forgex: status" → FORGEX
"specx: audit" → SPECX
"entropx: sources" → ENTROPX
"simonx: walls" → SIMONX
"authx: walls" → AUTHX
WARNING: Module names as standalone words are CREW NAMES and route to GLOSS, not their own modules. "simonx" → GLOSS. "commx" → GLOSS. Use service: prefix notation or the verified keywords in this dictionary instead.
Exception: modemx, entropx, forge work as standalone keywords because they are NOT in the GLOSS crew-name list.
Rule 4 — Check the _tier Field
Every ROUTX response includes _tier. If you see _tier: 2, your query fell through to MNEMOS. Rephrase using a Tier 1 keyword.
_tier: 1 → deterministic, verified, trustworthy
_tier: 2 → probabilistic, may hallucinate, verify independently
_tier: 3 → unknown, ◌
VOCABULARY EVOLUTION
This vocabulary is NOT frozen. When new modules are added or existing modules gain new keywords, this spec updates. GAPX scans for queries that frequently fall to Tier 2 — each one is a candidate for a new Tier 1 keyword.
The vocabulary grows from USE, not from planning. When users consistently query "weather toronto" and it falls to Tier 2, that's a signal to add "weather" as a keyword for a future weather module — or to route it to a web search tool.
LEARNX tracks these patterns. The vocabulary teaches itself.
INVARIANTS
INV-01: Every Tier 1 module has at least one keyword. No module is unreachable from the vocabulary.
INV-02: Module names are always valid keywords for their own modules. simonx, entropx, medx — these always route correctly.
INV-03: The _tier field is present on every response. It is the user's primary tool for knowing whether they hit Tier 1 (trust) or Tier 2 (verify).
INV-04: Tier 2 is a FALLBACK, not a feature. Every Tier 2 hit represents a vocabulary gap. The goal is to route 95%+ of queries at Tier 1.
INV-05: This spec is the single source of truth for ROUTX keywords. If a keyword works in practice but isn't in this spec, the spec is wrong — update it. If a keyword is in this spec but doesn't work, the engine is wrong — fix it.
INV-06: The vocabulary is published to all crew members through their handshake documents. Every AI on the Bridge — Sisters, Lobster, docked AIs — receives the same keyword reference. Nobody guesses.
WHY THIS MATTERS
ROUTX handles ~100% of tool queries on the ship. A crew member who doesn't know the vocabulary is a crew member who can't use the tools. The Sisters spent an entire session diagnosing "ROUTX is broken" when the real problem was "we used words ROUTX doesn't know."
The vocabulary is the interface contract between the crew and the tools. This spec makes that contract explicit, complete, and accessible. No more guessing. No more false alarms. No more "the system is broken" when the system is fine and the query was wrong.
The smartest AI in the world is useless if it doesn't know which words to use at the front desk.
Jeremy Zlabis
Chronogeometer · Visionary · Disruptor · Chief
42 Sisters AI · East York, Toronto
🍁 Φ 0.042