ELIM

Overview #

ELIM reads the last few lines of a conversation and says whether the next reply is fine to give, needs a nudge in a safer direction, or should stop. You give it the recent turns as plain text; it gives back a handful of labels and, when a nudge or a stop is called for, a suggested short line. Use it in front of any chat responder as a quick, cheap check.

ELIM (Enhanced Large Intention Model) is a conversation-intention classifier a host application runs before its responder to decide whether to allow, steer or abort a reply. It reads a short text window — the last three turns plus the current request — and returns four labels with confidences: the trajectory the conversation is on (one of 32 classes such as research, scam_check or crisis), the action to take (allow, steer or abort), the harm class in play (none, crisis, medical, crime, child_sexual, scam, jailbreak or secrets) and a steer hint naming the kind of nudge the responder should fold into its answer.

The input is plain text, so the window can come from any transcript the host keeps. The output is a small JSON object the host reads before doing anything else: on allow nothing changes; on steer the host passes the hint and the optional suggested line to its responder as guidance; on abort the host answers with the suggested line itself and never calls the responder. ELIM never writes the reply and never sees the responder’s output.

ELIM is the default model of the intention family. Its siblings LIM and LIM Nano score the same window with a single hashed bag — 512 and 256 wide respectively — and answer with the same contract; LIM3D and LIM3D-XL apply the same idea to observed movement rather than text. ELIM is 13.2M parameters, runs inside the host process with no native dependencies and no network call, and answers in well under a millisecond on a laptop CPU.

Intended use #

• A pre-reply intention gate: classify the current request, then let the host allow, steer or abort before its responder runs.
• Routing short, informal, English requests into coarse job classes (reminder, weather, transit, order, research, and so on) when a fast, deterministic label is enough.
• Flagging the handful of trajectories that need a fixed response — crisis, medical emergency, scam assistance, jailbreak attempts, leaked secrets — so the host can apply its own policy.
• Any place where a sub-millisecond, in-process decision matters more than nuance: per-request gating on a CPU, batch labelling of transcripts, cheap pre-filters in front of a larger model.

Out of scope #

• Writing or rewriting replies. The message field is a suggested short line, safe to replace, not generated text.
• Scoring the responder’s output. ELIM classifies the user’s side of the window only.
• Long documents, non-English text, sarcasm or novel phrasings far from the template set it was trained on.
• Acting as a safety classifier of record. Thresholds favour silence, and greetings and known job phrasings bypass the model entirely.
• Not medical, legal or crisis advice.

Choose ELIM when #

• You want the default Intention model: the released, served weights behind POST /v1/intention when no model field is sent.
• Character-level features matter — typos, run-together words and short fragments — because ELIM hashes character 3- and 4-grams as well as words; LIM hashes one combined bag.
• Memory is tight and 53 MB resident is acceptable but more is not; choose LIM (8.9M parameters, 35.8 MB) when a smaller table matters more than the second bag, or LIM Nano (4,338,995 parameters, 17.4 MB) when the footprint must be smallest of all. Both share ELIM’s contract.
• You need the same window scored by movement rather than text: choose LIM3D or LIM3D-XL instead.

Architecture #

ELIM is a dual-bag hashed n-gram classifier. There is no tokeniser and no pretrained embedding: the window is lowercased and hashed twice. The character bag takes every 3-gram and 4-gram of the last 360 characters; the word bag takes every unigram and bigram of the word sequence. Each n-gram is hashed with FNV-1a (32-bit, over UTF-8 bytes) modulo 16,384 into an index, and each bag keeps at most 2,048 indices. An empty bag contributes index 0.

Each bag is an embedding table of 16,384 × 384 float32 rows averaged over its indices (EmbeddingBag with mean pooling). The two 384-wide means are concatenated into a 768-wide vector and passed through fc1 (768→384) with GELU, then two residual blocks h = h + GELU(fc2(h)) and h = h + GELU(fc3(h)), each 384→384. Four linear heads read the final 384-wide state: trajectory (32 logits), action (3), harm (8) and steer (8). Softmax is applied per head at inference and the argmax picks the label; the softmax maximum is reported as the confidence.

The four label sets are listed under Inputs & outputs and on Output vocabularies. The heads are trained jointly but read independently at inference; the action a caller receives is not the raw action-head argmax but the result of the decision rules described below, which require the trajectory head to agree before a steer or abort is issued.

Of the 13,193,523 parameters, about 12.6M sit in the two embedding tables; the three hidden layers and four heads account for the rest. There is deliberately no sequence model: ELIM has no attention, no recurrence and no positional signal beyond what an n-gram carries, so word order matters only within a bigram or a 4-character span. It never sees pixels, audio or the responder’s text.

Inputs & outputs #

Input #

The model scores a single window string. The host builds it from up to the last three prior turns and the current request: each turn is rendered on its own line with a U: prefix for the user or an A: prefix for the responder, the current request is appended as a final U: line, the lines are joined with newlines and the result is truncated to 1,500 characters. Responder turns whose text matches an earlier safety reply (crisis, scam or refusal wording) are dropped before rendering, so ELIM judges the user’s intent rather than its own previous advice. Over the Falcon API the history is always empty, so the window is the single U: line built from text.

A complete in-process window with two prior turns:

U: remind me in 20 minutes
A: ok — 20 min.
U: is this a scam they sent me

This window yields 141 character-bag indices and 35 word-bag indices. The 360-character span for the character bag is taken from the end of the window, so on long windows the earliest turns contribute to the word bag only. Text is lowercased inside the hashers; the window itself is passed through unchanged.

The equivalent HTTP request scores only the current request:

{ "text": "is this a scam they sent me", "model": "elim" }

Limits: text is trimmed and must be non-empty; the window is capped at 1,500 characters; each bag keeps at most 2,048 hashed indices; there is no frame or coordinate system.

Output #

The four tables above list the documented vocabulary of each head. Five further trajectory labels exist in the catalogue for host-specific routing and are not documented. The steer label refocus is in the catalogue but never produced by the released weights; confirm_destructive is produced only for one of the undocumented trajectories.

A complete response for the window above, scored by the released weights (probabilities are serialised as raw floats; the near-saturated values are the behaviour described under Confidence semantics below):

{
  "trajectory": "scam_check",
  "action": "steer",
  "harm": "scam",
  "steer": "scam_warn",
  "pTrajectory": 0.9999998211860657,
  "pAction": 1,
  "pHarm": 0.9999999403953552,
  "rule": "traj-steer≥0.58",
  "model": "elim",
  "message": "…"
}

Decision rule. Trajectories are grouped into three sets: abort (crime, child_sexual, scam_assist, crisis_method), steer (crisis, medical_emergency, jailbreak, secrets, scam_check) and benign (the remaining 23). After the heads are read, action is decided in this order, and rule records which step fired:

1. A benign trajectory with pTrajectory ≥ 0.28 → allow (benign-traj≥0.28).
2. An abort-set trajectory with pTrajectory ≥ 0.62 → abort (traj-abort≥0.62).
3. Action head abort with pAction ≥ 0.78 and an abort-set trajectory with pTrajectory ≥ 0.45 → abort (action-abort≥0.78+traj≥0.45).
4. A steer-set trajectory with pTrajectory ≥ 0.58 → steer (traj-steer≥0.58).
5. Action head steer with pAction ≥ 0.72 and a steer-set trajectory with pTrajectory ≥ 0.40 → steer (action-steer≥0.72+traj≥0.4).
6. Otherwise allow (default-allow).

The thresholds are deliberately asymmetric: a benign trajectory wins at 0.28, whereas a steer or abort needs the trajectory head to be confident on its own. This keeps everyday requests quiet at the cost of missing harmful requests phrased like benign ones.

Bypasses. Two rules answer before any weights run and set model to "bypass": a greeting pattern (hi, hello, thanks, how are you, good morning and similar, alone on the line) returns smalltalk / allow with rule: "greeting-bypass"; a known-job pattern (food ordering, transit, reminders, timers, weather, maps, directions, translation, slides, drawing, and spatial-layout phrasing) returns help / allow with rule: "host-job-bypass". A second guard runs after scoring: if the model says steer or abort but the request matches the known-job pattern, the result is forced to allow with harm: "none", steer: "none" and rule: "host-job-override". Bypassed results report all three confidences as 1.

Confidence semantics. pTrajectory, pAction and pHarm are softmax maxima, not calibrated probabilities; the released weights are near-saturated at 1.00 on in-distribution text, so values well below 1 are themselves a signal that the request is unlike the training set. pAction is the raw action head’s confidence even when a decision rule overrode it — compare it with rule to see whether the head and the rule agreed.

Message. On steer and abort the result carries a suggested short reply in a casual register, safe to replace. It is selected by key from the harm class and trajectory, never generated: secrets → a fixed line asking the user not to send card numbers, passwords or keys; jailbreak → “i’ll ignore the jailbreak bit and just help with the real ask.”; abort on crime → a fixed refusal that tells the user research or fiction framing must stay non-operational; scam on a steer → a fixed line advising the user to treat pressure to pay, install software or move channels as a scam; medical → a fixed line directing acute symptoms to emergency services; crisis → a fixed line pointing at local crisis services, chosen by a location hint the host may supply. message is absent on allow.

Examples #

Three requests scored by the released weights, shown as the Falcon API returns them (message elided where present).

A benign research question:

{
  "ok": true,
  "result": {
    "action": "allow",
    "trajectory": "research",
    "harm": "none",
    "steer": "none",
    "pAction": 1,
    "pHarm": 1,
    "pTrajectory": 1,
    "model": "elim",
    "rule": "benign-traj≥0.28"
  }
}

A request for operational harm — abort, and the host should answer with message (elided here) instead of calling its responder:

{
  "ok": true,
  "result": {
    "action": "abort",
    "trajectory": "crime",
    "harm": "crime",
    "steer": "none",
    "pAction": 1,
    "pHarm": 1,
    "pTrajectory": 1,
    "model": "elim",
    "rule": "traj-abort≥0.62"
  }
}

A greeting (hello) — answered by the bypass rule; no weights run:

{
  "ok": true,
  "result": {
    "action": "allow",
    "trajectory": "smalltalk",
    "harm": "none",
    "steer": "none",
    "pAction": 1,
    "pHarm": 1,
    "pTrajectory": 1,
    "model": "bypass",
    "rule": "greeting-bypass"
  }
}

Other spot checks against the released weights: chest pain and i can't breathe → medical_emergency / steer / medical_911; my password is hunter2keep → secrets / steer / secrets_drop; what's the difference between etf and mutual fund → research / allow.

Training #

ELIM was trained once, on 2026-09-03, as a Vertex AI custom job on an n1-standard-8 machine with one NVIDIA T4 (PyTorch 2.4). The job wrote elim.bin, the meta.json catalogue and run.json; no prediction endpoint was created on the platform. The trainer package that produced it is the same one that trains LIM.

Data. The training set is fully synthetic: no real user conversations were used, and no external corpus. A generator holds 214 short English template phrasings across the 32 trajectory classes (six to thirteen per class, with a few extra variants for the weather, research, scam-check, crime, crisis, medical-emergency, jailbreak and continue classes) and ten prior-exchange pairs. Each example picks a class round-robin (with an 8% chance of a random class instead), samples a phrasing from it, and mutates 18% of phrasings of eight or more characters with one typo (a case swap, an adjacent transposition or a single deletion). A prior exchange is prepended 65% of the time; the continue class always receives the reminder prior. The window is rendered with the same U: / A: format and 1,500-character cap as at inference. Labels are derived from the trajectory: action, harm and steer are fixed functions of the class, so the four heads learn a consistent mapping. 80,000 examples were generated with seed 7, shuffled and split 90/10 into 72,000 training and 8,000 validation rows.

Recipe. Eight epochs, batch size 128, AdamW at learning rate 2e-3 with weight decay 0.01, constant learning rate, no scheduler and no gradient clipping; PyTorch seed 7. The loss is the sum of four cross-entropies: trajectory; action with class weight 2.2 on abort; 1.25 × harm with class weight 1.8 on crisis, crime, child_sexual and scam; and steer. Training from scratch — ELIM has no lineage and was not warm-started from LIM or any other model. After training, six fixture phrasings were scored as a sanity print (an explosives request → abort / crime; a weather request → allow / weather; a chest-pain request → steer / medical_emergency; a scam question → steer / scam_check, and two abort fixtures for the child-sexual and crisis-method classes).

Not trained on. Real conversations, non-English text, long-form text, transcripts with more than three prior turns, or any responder output. The typo jitter is the only augmentation; there is no paraphrasing, so the model has seen roughly two hundred distinct phrasings and their one-character variants.

Evaluation #

The held-out set is the first 2,000 of the 8,000 validation rows produced by the same synthetic generator (seed 7), evaluated on CPU in batches of 64 after the final epoch. All four heads score 1.000 on it, as recorded in run.json for the 2026-09-03 run and repeated in the meta.json catalogue. The latency figure is a separate in-process measurement against the released weights, not a training artefact.

Known gaps. The validation rows come from the same 214 templates as the training rows, so a perfect score measures that the mapping from template to label was learned, not how the model behaves on real text. There is no held-out set of real requests, no measurement of false-positive rate on benign traffic, no per-class recall on paraphrases, and no measurement of the bypass rules’ coverage. The confidences are near-saturated on template-like text and have not been calibrated. Treat the numbers as a training sanity check; measure ELIM on your own traffic before relying on any threshold.

API #

Route /v1/intention · quota bucket intention · body limit 64,000 bytes.

ELIM is public on the Falcon API at POST /v1/intention. The route is shared with LIM and LIM Nano: the optional model field selects which model scores the request — "lim" or "lim-nano" — and ELIM answers when the field is absent or "elim". Any other value answers 400 unknown_model with models listing the three accepted names. Authentication, the response envelope, retry guidance and quota sizes are described on API conventions; this page documents only what is specific to this route.

POST /v1/intention HTTP/1.1
Authorization: Bearer fln_your_preview_key
Content-Type: application/json

The base URL of the Falcon API is given on API conventions; paths on this page are relative to it.

Request body — text required, model optional ("elim", "lim" or "lim-nano"):

{ "text": "is this a scam they sent me", "model": "elim" }

Response — 200 with ok: true and a result object, or result: null when the intention weights are not available to the server:

{
  "ok": true,
  "result": {
    "action": "steer",
    "trajectory": "scam_check",
    "harm": "scam",
    "steer": "scam_warn",
    "pAction": 1,
    "pHarm": 1,
    "pTrajectory": 1,
    "model": "elim",
    "rule": "traj-steer≥0.58",
    "message": "…"
  }
}

The HTTP route passes an empty history, so the window is the single U: line built from text; to score a multi-turn window, embed the model in-process (see Runtime & deployment). text is trimmed before the empty check and before scoring. message is omitted from the JSON when the action is allow.

Errors. Every error is a JSON body with ok: false and an error code:

Quota and limits. Each request counts one against the intention preview quota bucket, per UTC calendar month, whichever of ELIM, LIM or LIM Nano scored it; a request that fails validation or authentication does not count. The request body is limited to 64,000 bytes. There is no batch route; send one window per request. Bucket sizes are listed on API conventions.

Runtime & deployment #

ELIM runs in-process. The runtime is a small TypeScript loader plus a handful of dense-math helpers (embedding-bag mean, linear, GELU, softmax) with no native dependencies and no network call; the Falcon API server hosts the same code behind /v1/intention, and a host that wants the multi-turn window embeds it directly. The Falcon API runs on 2 vCPU / 2 GiB and is kept warm with one minimum instance, so there is no wait for the service to start; ELIM answers through the API in well under a second.

• Load behaviour. The weights are read lazily on the first call: the loader reads meta.json (the label catalogue and dimensions under its elim key) and elim.bin (16 named float32 tensors, 52,774,490 bytes), then caches both for the process lifetime. About 53 MB stays resident. The same loader also reads LIM’s weights when they sit beside ELIM’s, adding 35.8 MB, and LIM Nano’s 17.4 MB bundle from its own directory. If neither file loads, the loader records the pack as missing and every score call returns null rather than throwing; the Falcon API surfaces that as result: null with status 200, never as a 503, so the “503 while loading, retry once after 2.5 s” pattern used by the served models does not apply here.
• Selection. ELIM is the default. The model: "lim" request field — or the equivalent per-caller setting in-process — selects LIM for that request, and model: "lim-nano" selects LIM Nano; if elim.bin is absent the loader falls back to LIM silently and reports model: "lim" in the result. No process restart is needed to switch. GET /health lists the loaded variants as limVariants: ["elim", "lim", "lim-nano"].
• What the host must provide. When the weights are available to the host process (they are not distributed during the private preview): a directory containing meta.json and elim.bin; a Node 22 runtime; the conversation history (up to three prior turns, with role set to user or model) and the current request; optionally a location hint used only to choose which regional crisis line the crisis suggestion names.
• Concurrency and timeouts. Each call is synchronous and takes under a millisecond on the calling thread, so throughput scales with the host’s event loop; there is no worker pool, no batching and no timeout to configure.
• Disabling. The host can switch intention scoring off entirely, in which case the scorer returns null and the host must decide its own default (usually allow).

Weights are not distributed during the private preview; the hosted route is the way to call this version.

Integration notes #

• Treat null as “no opinion”, not as allow: decide in the host whether an unavailable scorer fails open or closed.
• Read action, not harm, when deciding what to do. harm can be non-none on an allow result when the trajectory head disagreed with the harm head; the decision rules require trajectory agreement precisely so that a lone harm vote does not abort a benign request.
• Hand message to the responder as guidance on steer, and use it as the reply on abort. Replace it freely — it is a fixed line chosen by key, and the register is casual.
• Keep the bypass rules in mind when testing: a request that mentions food ordering, transit, reminders, weather, maps or spatial layout will never reach the weights, and a flagged request that matches those patterns is overridden to allow.
• ELIM scores only the user’s side. If your application needs to check what the responder wrote, that is a separate pass with a different model.

Limits & safety #

It does not see the responder’s output, the wider transcript beyond three prior turns, or anything outside the last 1,500 characters of text; it reads a lowercased window and nothing else.

• It does not write replies. message is a suggested short line selected by key, safe to replace; the responder or the host writes the reply.
• It does not score the responder’s output. Only the user’s turns and the current request are labelled; earlier safety replies are stripped from the window before scoring.
• It is not a safety classifier of record. Thresholds favour silence (a benign trajectory wins at 0.28), greetings and known job phrasings bypass the weights entirely, and a flagged request that matches a known job pattern is overridden to allow by design. A harmful request wrapped in a benign job phrasing is allowed.
• It has seen only 214 English template phrasings and their one-character typo variants. Novel phrasings, other languages, sarcasm, long requests (only the last 360 characters reach the character bag) and multi-step reasoning are out of distribution, and the 1.000 validation scores say nothing about them.
• Confidences are softmax maxima, not calibrated probabilities. The released weights are near-saturated at 1.00 on in-distribution text, and hash collisions across 16,384 buckets per bag can make unrelated n-grams share an index.
• Five of the 32 trajectory classes are routing labels that only make sense for a host with those jobs; they are not documented and should be mapped to unknown by hosts that do not use them.
• The crisis and medical suggestions are fixed lines. They are not medical, legal or crisis advice, and the regional crisis line they name is chosen by a location hint, not detected from the request.

Out of scope. ELIM is not a content filter, a toxicity scorer, a language detector or a sentiment model. It does not extract entities, dates or amounts from the request, does not track state across requests, and does not learn which of its labels the host acted on. Not medical, legal or crisis advice.

Fixed weights per version; the model does not learn from requests.

Versions #

Compatibility. A major version bump changes the input or output contract: the window format, the label catalogue of any head (adding, removing or renaming a trajectory, harm or steer label), the decision-rule thresholds, or the shape of the result object. A minor bump is a retrain on the same contract — new weights, same labels and same fields — and may move confidences and change individual decisions without changing what a caller has to parse. A patch bump changes only metadata or runtime behaviour, such as the loader or this documentation. Hosts should pin to a major version and re-validate their thresholds on any minor bump.

Current weights. Version 1.0.0 is the tensor bundle elim.bin (52,774,490 bytes, 16 float32 tensors) written by the 2026-09-03 Vertex AI run with seed 7, paired with the meta.json catalogue whose elim entry records 16,384 hash buckets, 384-wide bags, a 384-wide hidden state, 32 / 3 / 8 / 8 head sizes and 13,193,523 parameters. The catalogue file was last regenerated on 2026-09-09 when LIM was added beside it; the ELIM tensors did not change.