Weksa/docs/runtime-authoring-split.md

Runtime and Authoring Split

Weksa must be able to run in time-sensitive contexts such as games. The hot path should be fast, deterministic, local, and free of required LLM calls.

Runtime

Runtime consumes structured meaning and compiled language-project data.

structured intent
  -> ontology projection
  -> grammar plan
  -> morphology
  -> phonology
  -> diachrony
  -> surface render

Runtime invariants:

• no network dependency
• no required LLM call
• no arbitrary English interpretation in the hot path
• compiled data is immutable during a render pass
• renderer does not invent meaning
• traces can explain which stage made each decision

The game, tool, or host application should send structured intent, not prose that Weksa must guess at under pressure.

Authoring

Authoring tools may use neural models for slow, inspectable work:

• semantic decomposition from example English
• candidate ontology entries
• typological inspiration
• register and lexicon proposals
• consistency critique
• test case generation

Model output becomes durable only when normalized into explicit project state. The model is a workshop tool, not a runtime authority.

Parallel Renderers

One structured intent may render into multiple surfaces:

structured intent
  -> projected meaning
  -> alien-language renderer
  -> subtitle or gloss renderer
  -> debug/plain renderer

For flavor-first settings, subtitles may render from projected meaning instead of neutral facts. The neutral facts still exist underneath for correctness and debugging.