Skip to documentation
eli.aidocs

Platform

Workspace settings

Operational knobs are per-workspace, not per-deployment. A consulting instance hosts workspaces with very different risk profiles — a high-budget enterprise engagement and a personal sandbox should not share a spend cap or an alert threshold. Workspace settings are a small, typed bag of overrides stored on the workspace, with a strict precedence rule over environment and built-in defaults.

The settings

  • Scheduled spend cap — the maximum model spend scheduled work (drift scans, canaries, scheduled agent runs, report generation) may accrue per period. When the cap is reached, scheduled jobs skip with a recorded reason instead of running; interactive use is unaffected. See Cost & schedules.
  • Drift thresholds — the orphan-rate jump (driftOrphanRateThreshold) and the absolute document-churn count (driftDocChurnThreshold) between drift snapshots that trip a drift alert.
  • Staleness threshold — hours without knowledge-base activity (staleAfterHours, default one week) before the dead-man's-switch considers the KB stale and raises the kb.stale alert. See Scheduling, drift & alerts.
  • QA sample rate — the fraction of auto-applied links/relations routed to the audit queue (default ~2%). See Silent QA sampling.
  • Chat defaults — the nested chatDefaults bag (retrieval limit, groundedness badge, data context, temperature, custom instructions), the workspace layer of the chat configuration chain. Each inner key overrides and clears independently. See Chat configuration.

Settings live in the workspace's metadata as a JSON bag — only overridden keys are stored, so an untouched workspace carries {}and tracks the deployment's defaults automatically. Editing is owner/admin-gated in Settings.

a workspace's settings (only overrides are stored)json
{
  "monthlySpendCapUsd": 50,
  "qaSampleRate": 0.05
}

Precedence

Every setting resolves through the same three-level chain, first match wins:

  1. Workspace setting — an explicit override stored on the workspace.
  2. Environment default— the deployment-wide value from the server's env configuration, letting an operator set a house default for every workspace on the instance.
  3. Built-in default — the shipped value, so a bare install with no env config still behaves sensibly.

Why workspace wins

The same inversion as credential precedence: the setting closest to the tenant's risk profile must win. An instance-wide env default is a starting point, never a ceiling a specific engagement can't adjust — and never a silent override of a cap a client's workspace has deliberately tightened.

Behavior notes

  • Changes apply on next evaluation. Thresholds are read when a scan runs and caps when a job is about to start — no restart, no re-scheduling required.
  • Strict on write, lenient on read.Writes reject unknown keys and invalid values, so a typo'd key can't silently disable a cap; reads validate each stored key independently and drop corrupt values back to their defaults instead of failing the whole bag.
  • Clearing a key restores inheritance. Deleting an override returns the workspace to the env/built-in default rather than freezing the last value.

Related