Custom classification

Teach Eldric
your domain.

Eldric's router classifies every query into an intent class before it picks where to send it. The platform ships with 128 built-in classes (11 core intents + 117 science sub-domains). For workflows where the built-in classes don't carry the right distinctions — a hospital might want a "PatientTriage" class, a law firm a "ContractReview" class, a factory an "AnomalyTrend" class — Eldric supports custom classes at the tenant level. Two paths: train an overlay classifier, or fall back to an LLM with your taxonomy.

What the classifier does

Routing starts here.

When you ask a question, the router runs the query through a small classifier first — a single neural pass that returns a class label and a confidence score. The class determines what worker handles the request, which knowledge bases are searched, which model is picked, and whether the cascade tries learned weights / matrix memory / RAG / live sources first.

The built-in classes cover the obvious top-level shapes: plain chat, RAG query, agent invoke, swarm request, memory store/recall, data operation, science query, media request, comm request, training request, IoT request — plus the 117 science sub-domains for genomics / particle physics / climate / etc. Custom classes sit alongside these, with the same routing semantics; they extend the taxonomy rather than replacing it.

Path A — overlay classifier

Train Eldric on your examples.

The high-quality path. You provide labelled examples — a few hundred queries per new class, each tagged with the class you want — and Eldric trains an overlay on top of the base classifier. The training is local (your data doesn't leave the cluster), takes minutes on a small GPU, and produces a per-tenant .enrn classifier file that the router loads alongside the base one.

The flow:

Compile your labelled examples into a JSONL file: one row per example with {"query": "...", "class": "ContractReview"}.
POST the file to /api/v1/router/custom-classes/train with your tenant id. The training worker (port 8898) runs the ENRN overlay pipeline.
The training worker emits progress to the chat shell; when it lands a .enrn with eval accuracy above your threshold (default 0.8), the router hot-reloads it.
New queries that look like your examples now classify into the new class — and routing follows from there.

Pro+ tier. The training corpus, the overlay file, and the eval report stay on your cluster — no part of the workflow phones home.

Path B — LLM fallback

No training corpus? Use the model.

The fast-start path. If you don't have labelled examples yet but you know the classes you want, the router can fall back to an LLM with a prompt that includes your taxonomy. Two configurations:

Automatic fallback

When the base classifier returns a confidence below threshold (default 0.7), the router escalates: it asks a small LLM "classify this query into one of: [your class list]" and uses the LLM's answer as the routing label. Adds 50–100 ms to the query for the LLM round-trip; only fires on the queries the base classifier wasn't confident on. Free with any tier that has a chat-capable model configured.

Always-LLM

For tenants with no built-in class overlap (a niche regulated workflow with vocabulary the platform's never seen), you can disable the base classifier for that tenant and run every query through the LLM-with-taxonomy path. Slower per query, but no training required. Cost depends on which model you point it at — local Inferenced is free per request, paid cloud LLMs bill per token.

Both Path A and Path B are configured per tenant. A tenant can run with the overlay classifier for the bulk of traffic and LLM fallback for low-confidence cases.

Seeing the classifier's decision

What just got classified, and as what.

The Admin Console → Router page shows a live tail of classification decisions: query (anonymised by default), assigned class, confidence, source (base / overlay / LLM-fallback), and the worker the request was routed to. Useful for debugging "why did this query end up where it did" and for spotting class taxonomy gaps — when many queries land in the catch-all "general" class with low confidence, that's a signal to add a new class.

The same data is exposed via the API:

curl -X POST -H "X-API-Key: $ELDRIC_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{"query":"can you summarise the indemnification clause in contract X"}' \
     https://<your-host>/api/v1/router/classify

# {
#   "class": "ContractReview",
#   "confidence": 0.91,
#   "source": "overlay",
#   "fallback_chain": ["base", "overlay"]
# }

Operators wire this into their own dashboards when they want a clearer picture of what queries the platform is seeing.

When to use which path

A decision shape.

You have labelled examples already — Path A. Best accuracy, no per-query LLM cost.
You know the classes but have no examples — Path B always-LLM. Up and running in minutes; promote to Path A once you've accumulated examples.
Your taxonomy mostly overlaps with the built-in classes — Path B automatic fallback. The base classifier carries most traffic; the LLM handles the few queries the base wasn't sure about.
You're not sure yet — start with Path B automatic fallback. The Admin Console's classification tail tells you which queries are landing where; you'll know within days whether you need custom classes or whether the built-ins fit.

Going further

Next.

For the RAG how-to: using RAG. For the cascade behaviour: RAG on demand. For how the router fits into the rest of the system: how it works. For the training-worker side that produces the overlay .enrn files: features § Training.

Teach Eldricyour domain.