61 lines
1.5 KiB
Markdown
61 lines
1.5 KiB
Markdown
# 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.
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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.
|
|
|