Platform settings
The Platform settings page in the admin console (Admin → Platform settings) is a
small key→JSON store that holds platform-wide defaults. These values layer over
the defaults baked into the code (and any ENV overrides): an absent or cleared setting
always falls back to the built-in default, so the platform behaves exactly as it does
out of the box until an admin overrides something here.
Every setting on this page is server-enforced — the toggle is not just a UI hint; the backend reads the effective value at run time and acts on it.
!!! note “Effective values, not raw overrides” The page shows the effective configuration (built-in defaults merged with any admin overrides). Saving with a field left at its built-in default clears the override rather than pinning the current default in place.
Default security mode
This control sets the default tool-call security mode for runs that don’t carry their own per-chat or per-user pick.
| Option | Value | Behaviour |
|---|---|---|
| Built-in default | (cleared) | No platform override — the code default applies. |
| Autonomous (no approval) | autonomous |
Tool calls run without approval. |
| Approve each tool call | approve_each |
Every tool call waits for the user to approve it. |
| Judge (model-reviewed) | judge |
A guard model reviews each tool call. |
The effective mode for a run is resolved in this order:
- the run’s per-chat / per-user security pick, if any;
- this platform default;
- the built-in default (
judgewhen a guard model is configured, otherwiseautonomous).
!!! note “Per-chat and per-user picks still win”
This is only a default. A user’s per-chat or per-user security choice always takes
precedence over the platform default. If judge is selected but no guard model is
configured, runs fall back to approve_each.
The platform default applies on every chat run. Inline and durable chat share one
executor, so a durable chat run resolves the same effective mode and is wrapped by the
same guard (judge / approve_each parity included). Triggered workflow scripts run
headless: writes stay gated by the effective security mode, but any tool call that would
need interactive approval fail-denies instead of hanging the background run. When no mode
is in force, the catastrophic-command deny-floor still blocks destructive shell commands.
Feature flags
Feature flags turn platform capabilities on or off for everyone. They default to on (current behaviour); an admin can disable one platform-wide. Unknown keys are ignored.
| Flag | Key | What it toggles |
|---|---|---|
| Proactive review | proactive |
Hourly briefings written into the main chat about due items. |
| Voice | voice |
Microphone (speech-to-text) and read-aloud (text-to-speech). |
Each flag is enforced at the feature’s own gate: proactive gates the hourly proactive
scheduler, and voice gates the voice endpoints (and is surfaced to clients so the UI
hides voice controls when it is off).
Entity history retention
Numeric entity state is recorded as raw history, periodically rolled up into long-term per-period statistics, and then the now-rolled-up raw rows are trimmed to a bounded window. This setting is the single source of truth for that window.
| Setting | Key | Default | Effect |
|---|---|---|---|
| Entity history retention (days) | entity_history_retention_days |
30 |
How far back raw entity state history is kept before being pruned. |
Both paths read the same value: the roll-up’s trim (it only ever deletes raw rows already captured in a statistics period) and the backstop prune. The backstop never deletes data newer than the window. Statistics graphs on the entity detail page keep working past the window because they read the rolled-up statistics, not the raw rows.
Extension point
Platform settings is the GUI home for global knobs. It is designed to grow: new
admin-managed defaults are added by extending the typed accessors in
core/platform_settings.py (which own the setting keys and their fallback defaults) and
surfacing them on this page — keeping callers decoupled from how the values are stored.