Glossary

The terms that recur across the Eldric docs, with one-liners so nobody has to guess. Engineers reading this in 2027 should find no surprises.

Worker a daemon that does the work

A long-running process that does a specific job under the Controller's orchestration — ingests sensor data, runs inference, stores vectors, delivers messages, runs training. "Worker" is the role; "daemon" is the process shape. Same thing, different angle.

In 4.x each Worker is its own systemd unit (eldric-workerd, eldric-datad, eldric-agentd, …). In 5.0 they're role modules hosted in the single eldric-aios binary. The filename convention -d suffix is the classic Unix "I'm a daemon" marker.

Daemon

A long-running background process under systemd. In Eldric all Workers are daemons; the Controller, the Router, and the Edge are also daemons. We prefer "Worker" when talking about the role the process plays, "daemon" when talking about its process lifecycle.

Module 5.0 only

A role host compiled into eldric-aios. Fifteen of them: controller, router, edge, cloud, inference, data, agent, swarm, media, comm, science, training, iot, nova, dream. Each owns a port range and an API surface. The module is what a 4.x Worker becomes when you collapse everything into one binary.

Controller

The orchestrator. Tracks which workers are online, what models they serve, what the cluster topology looks like. Every worker registers with the controller at start; every worker re-registers on heartbeat. The controller itself is a Worker (role: controller).

Router

The load balancer in front of the workers. Clients hit one router; the router picks which worker serves the request based on model availability, worker load, and the configured strategy (round-robin, least-connections, least-latency, AI-decided). Also a Worker (role: router).

Edge

The external-facing gateway. Terminates TLS, enforces API-key auth, applies rate limits, proxies to the router, hosts the chat UI at /chat, runs the plugin system. Edge is where chat.eldric.ai lands.

Extension Tier 2, loadable

The only runtime-loadable thing in Eldric. A specific named capability that plugs into a role host — an OPC-UA connector, a NASA API adapter, a CUDA backend, a vLLM wrapper. Ships as a signed .eldext bundle, runs as a subprocess (Model A) or external service (Model B) under the host's supervision. Extensions expose tools the Brain can invoke.

Plugin chat-shell concept

A toggle in the chat sidebar. Rendering add-ons (markdown, code, charts), data sources (one per knowledge base / API), project scopes, workgroup sharing, privacy opt-outs, tools. Every loaded Extension with category: data or category: tool auto-surfaces as a Plugin. When users enable multiple data Plugins, one chat query fans out to all of them in parallel.

Data-plugin fan-out

The retrieval pattern: when a chat request lands, Edge queries every enabled data.* Plugin in parallel via the retrieval.<plugin-id> contract. Returned snippets merge into a synthesised system message prepended to the conversation before the LLM sees it. The fan-out doesn't care whether each plugin answered via vector search, tree reasoning (PageIndex), live sensor query, or anything else — same plumbing, different epistemic strategies.

Matrix Memory

The data role's compressed associative memory — outer-product updates (M = decay·M + importance·(v⊗k)), matrix- vector recall. Captures patterns rather than exact documents. Complements vector storage (which handles exact retrieval). Hierarchical: Domain → Project → Run matrices cascade from general knowledge to specific context.

Dream

The background consolidation scheduler. During idle periods, walks the cycle ingest → extract → probe → distill → checkpoint → complete to reorganise what's been learned — sleep, but for AI memory. Per-user scope via the sharing.dream plugin opt-in.

Brain

The inference side of things — the LLM(s) that answer queries. Learns new tools at runtime from ETP tool manifests (no retraining). Talks to Extensions via the Eldric Tool Protocol over gRPC / HTTP.

ETP — Eldric Tool Protocol

The wire protocol between the Brain + role hosts and Extensions. gRPC over Unix domain socket (canonical), HTTP/JSON (Model B fallback). Semver-stable for ≥5 years from 5.0 GA. Not MCP — MCP is an optional Phase-4 bidirectional gateway for external clients.

Controller / Worker / Edge / Router — who talks to whom

External client → Edge → Router → Worker(s) → Extension(s). The Controller sits out-of-band, tracking who's online. In a single-node install all five are the same eldric-aios process on port 8880.

Miss a term? Tell juergenp@core.at.