The Engine Underneath It All.
Every analysis Ishvana runs flows through Etherforce. Consistency checks, scene scans, lore graph walks, research queries — all of it dispatches into bundled local handlers and comes back with a typed result. Same input, same result, every time. Nothing leaves your machine. Nothing costs a token.
Typed Handler Invocations
Every agent in Ishvana speaks the same envelope. A typed HandlerInvocation
goes in — a model id, structured handler args, scope reference, strictness setting.
A typed HandlerResult comes out — findings, items, applied parameters,
timing data, success or failure. The shape doesn't change whether you're running
a four-second scene scan or a four-minute manuscript scan.
Local Handlers
Forty-plus handlers ship in the install: scene contradictions, ProseGuard, Worldspell, Hawken's three scan tiers, the Lore ML pipeline, GameMaster's stat forge and ability workshop, the intent and project classifiers, Markov name generation, Wikipedia search. All of it runs inside the Python backend Electron spawns at launch.
No External Calls
Every handler is local. No request leaves your machine for an analysis. The Divinity Engine ships its embedding model and NLI model bundled, plus an optional Deep Analysis Pack that downloads on first use of features that need spaCy or coreference.
Reproducible Output
Same scene plus same lore plus same parameters always produces the same findings. Run a consistency check today and again tomorrow without changing the source, and the result is identical.
No Token Budget
No per-token billing because no tokens are billed. Run as many checks as you want, on as many manuscripts as you want, as often as you want. The cost is the price you paid for Ishvana.
Progress Chunks for Long Scans
A 90,000-word manuscript scan is a long-running operation. Etherforce surfaces progress as the work happens — scene by scene, chapter by chapter — instead of going dark for two minutes and then dumping the report all at once.
- Per-Phase Events
- Manuscript scans, chapter scans, full-project consistency checks, and Lore ML training all emit phase-progress chunks the UI subscribes to. You see "scene 14 of 87 scanned" instead of a spinner.
- Cancellable in Flight
- Long scans can be cancelled mid-flight from the panel that started them. The cancellation is honored at the next handler boundary so partial work isn't lost on resume.
- Terminal Result Envelope
- Every streaming run ends with the same
HandlerResultshape a non-streaming run would produce. The UI doesn't need to branch on streaming-vs-not. - Concurrent Sub-Reports
- Composition handlers (Hawken's scene scan, Lorekeeper's consistency pass) fan their sub-handlers out via
asyncio.gatherand surface each sub-report's completion event as it lands.
Content-Hash Caching
Re-running the same handler against the same content with the same parameters is free. Etherforce keys every result by content hash, returns the cached value when it's still good, and invalidates when the underlying scene, chapter, or lore graph changes.
- Per-Scene Caching
- Scene-scoped handlers cache by scene id plus content hash. Editing one scene invalidates that scene's cache without disturbing the rest of the chapter.
- Per-Manuscript Caching
- Manuscript-scoped handlers (theme detection, full-project consistency, Lore ML training) cache by project id plus aggregate content hash. The cache persists across the same backend session.
- Automatic Invalidation
- The cache flushes when the underlying content changes — no manual cache-clear button you need to remember. Strictness and parameter changes also fold into the cache key so a scan re-runs when you tighten the threshold.
- Stats Surface
- Hit rate, miss count, and per-handler cache stats are visible in the Etherforce Observability panel. Useful when a scan feels slow and you want to know whether the cache is actually doing its job.
Every Dispatch, Logged
The Etherforce Observability panel in the Analysis workspace shows every handler dispatch in real time. Handler id, scope reference, applied parameters, duration, finding counts, error if any. The "see what's actually happening" surface for the engine.
Dispatch Log
An in-memory ring buffer of recent handler invocations. Every entry shows which agent triggered the dispatch, which handler answered, the strictness applied, the timing breakdown, and the resulting finding count.
Handler Catalog
The full registry of every handler the Divinity Engine ships with — model id, owning agent, engine version, documented input contract. The same registry that drives the source-handler badges on findings throughout the app.
Latency Percentiles
Per-handler p50 / p90 / p99 distributions over the recent dispatch history. When a scan feels slow, the percentiles tell you whether it's an outlier or a regression.
Source-Handler Attribution
Every finding in every panel carries a source-handler badge that maps back to the registry. You always know which deterministic query produced any given finding.
Agent Tool Registry
Beyond the analysis handlers, agents have access to a smaller set of tools — Legendry lookup, document load, scene metadata read, project context. The tool registry catalogs them, scopes them per agent, and tracks invocation counts so you can see which tools each agent reaches for during a session.
- Per-Agent Tool Sets
- Different agents have different tools. Hawken reads scenes and lore. Lagan reads bookmarks, monitored feeds, Wikipedia. Lorekeeper reads the lore graph. The split is documented and exposed in the Etherforce Observability tool catalog.
- Invocation Tracking
- Every tool call is logged. The dispatch log surface shows which agent invoked which tool, when, and with what arguments.
- No External Surface
- Tools call into the same local backend that hosts the handlers. No API key, no remote call, no rate limit. Lookup latencies are SQLite-fast.
- Stable Identifiers
- Tool ids are stable across releases. The Authored Library bindings, the source-handler badge map, and any third-party packs that reference handler ids stay valid as the engine evolves.