Skip to documentation
eli.aidocs

Lens

Chat configuration

Grounded chat has sensible defaults, but not one-size-fits-all defaults: a client-facing engagement workspace wants tight, badge-verified answers; a personal sandbox wants breadth and experimentation. Chat behavior is therefore configurable in three layers — workspace defaults, per-user preferences, and per-send overrides — with the most specific layer winning, knob by knob. What is not configurable is the grounding contract itself: citations, the refusal gate, and safety rules sit outside every layer.

The three layers

  1. Workspace defaults — the chatDefaults bag inside workspace settings, owner/admin-set. The baseline every member starts from, and the only layer that can set customInstructions — the right place for house rules like an engagement-wide style guide or a conservative temperature.
  2. User preferences— each member's own overrides, set from the chat preferences panel and persisted in the browser, per workspace. Personal and scoped: your preferences in one engagement never leak into another (or onto a colleague's machine). Only explicitly-set keys are stored, so an untouched knob keeps tracking the workspace default.
  3. Per-send overrides — the optional optionsfield of the chat request, driven by the composer's inline controls and applying to that one exchange only. Drop the view's data context for a purely document-grounded question, add one-off instructions, then the next message is back on your defaults.

Resolution is per-knob, most specific wins: per-send > user preference > workspace default > built-in. Every layer stores only its overridden knobs, so clearing an override restores inheritance from the layer above — the same precedence discipline as workspace settings generally. Out-of-range numbers are clamped into range server-side rather than rejected — a stale preference can degrade a send, never break it.

The knobs

Chat configuration knobs

retrievalLimitnumber (1..20)How many retrieved chunks feed the model per question — the [Sn] source budget. Default 12. Higher casts a wider evidence net for synthesis questions; lower keeps answers tight and fast.
groundednessBadgebooleanWhether the post-answer groundedness judge runs and streams the "verified n/m claims" badge. Default on. Off means no judge call at all; flag-only either way — the badge never blocks or rewrites an answer.
includeDataContextbooleanWhether contextual chat attaches its non-document evidence blocks — cited as [Cn]: the graph neighborhood when you chat from an entity or graph view, the report snapshot from a report, the run trace from a run. Off drops those blocks and answers ground in [Sn] document sources only. Document scoping from the current view always applies either way — the knob controls extra evidence, never scope. Default on. Shown as "Use data context" in the chat preferences panel.
temperaturenumber (0..1)Sampling temperature for the chat model. Unset by default, so the model/slot default applies. Low for deterministic, repeatable client-facing answers; higher for exploratory phrasing.
customInstructionsstring (≤2000 chars)Workspace style guide appended to the system prompt inside a delimited style block — "answer in bullet points", "assume a technical audience". Workspace layer only; per-send `instructions` append to the same block for one exchange. Style only; see the guardrail below.

A typical setup: the workspace pins temperature low and writes an engagement-wide customInstructions; a member who lives in the graph and report views keeps includeDataContext on and retrievalLimit high in their preferences; and anyone flips a knob in the composer for a single unusual question. After each exchange the route streams back the effectiveconfig it actually applied, rendered as a subtle chip on the answer ("12 sources · verified") — so what happened is never a guess.

per-send overrides (the chat request's optional `options` field)json
{
  "messages": [ /* … */ ],
  "options": {
    "retrievalLimit": 20,
    "groundedness": true,
    "temperature": 0.1,
    "includeDataContext": false,
    "instructions": "Answer as a one-paragraph executive summary."
  }
}

Where each layer is set

  • Workspace defaults — workspace Settings, owner/admin-gated, stored as the chatDefaults bag alongside the other workspace settings (only overridden keys stored; null clears a key back to the built-in).
  • User preferences — the preferences panel inside chat, per member per workspace, no admin role required; persisted client-side and sanitized on load, so a corrupt value falls back to the workspace default instead of erroring.
  • Per-send overrides— the composer's inline controls next to the send action, submitted as the request's options; an untouched send carries no options at all, so workspace defaults apply untouched.

What configuration can never touch

Custom instructions cannot override citation or safety rules

Custom instructions — workspace customInstructions and per-send instructions alike — are appended inside a delimited style block below the platform's system rules. They are style guidance, not a jailbreak surface: no instruction at any layer can disable the [Sn]/[Dn]citation mandate, bypass the refusal gate when evidence doesn't support an answer, unwrap the untrusted-content delimiters around retrieved chunks, or relax safety rules. "Ignore your citation requirements" in a workspace default does exactly nothing: the grounding contract is enforced by the platform prompt and by deterministic guardrails that run regardless of configuration.

The same boundary applies to the other knobs: retrievalLimit and temperature are clamped to platform ranges, turning the groundednessBadge off skips the judge but never the deterministic citation guardrail, and includeDataContext only toggles the [Cn] context blocks the current view already assembles — those blocks ride inside the same untrusted-content delimiters as [Sn] sources, are citable exactly like them, and count as evidence for the groundedness check. The knob grants no data access of its own.

Related