Platform Settings

What this screen is for

Platform Settings is where your whole installation is configured, and this is its root: the landing the Platform Settings sidebar entry opens before you have chosen anything. It shows eight cards, one per purpose group, each with its name, a one-line statement of what that group decides, and a live count of the values it holds. The same eight groups hang under the sidebar entry as a tree, so you can drill straight to a group or to one of its entries without passing through here.

Underneath the cards the shape is fixed: eight purpose groups, 38 subgroups between them, and 316 configuration values in total.

The tree is organised by purpose, not by service. Each value carries the group and the subgroup it belongs to, and the console renders the tree from those — never from the value's name and never from which service reads it. So a timeout that three services honour appears once, under the purpose it serves, and you look for a value by asking what it decides rather than by knowing which service owns it.

What must exist first

This is a platform screen. Opening it while you are working inside a tenant sends you to that tenant's dashboard, and every request behind it is refused unless your token carries the platform tenant — a refusal that says only Forbidden and never which tenant or which permission was wrong. Beyond that:

The permission to read platform configuration. It is what puts the Platform Settings entry in the sidebar at all, and what fetches the catalogue the cards count. The platform super administrator, auditor and viewer roles hold it.
The permission to write platform configuration, for any change at all. Only the platform super administrator holds it. Without it every value is readable and none carries an edit control.
A third permission for values classified dangerous. It is required in addition to the write permission, and the platform refuses the write without it whether or not the screen let you type the confirmation.
Six of the 38 subgroups are not lists of values but administer records, and each has its own permissions. Holding platform configuration read does not carry them, and holding only them still admits you to that one entry.

Decisions you make here

Reading the landing

The catalogue is read once when you open the surface, so every count on this landing and on every screen below it was read at the same moment; filtering, searching and drilling never fetch it again.

Each card's count is scoped to the Posture filter beside the search button, so it is a filtered count and not the group's size whenever the filter is not All. The other three values are Editable, Read-only and Secrets, and a value falls into exactly one: a secret is a secret whether or not it is writable, anything else you may write is editable, and everything left is read-only. A group with no match still shows its card, reading 0.

On a deployment whose environment is not production a persistent advisory sits above the cards — Non-production environment — stating that some parameters are relaxed relative to production. It is informational, it cannot be dismissed, and it is absent when the environment is production or unknown.

Finding a value by name

Search settings, or Ctrl/Cmd+K, opens a palette over the whole catalogue. It matches a value's key, its label, its description, its category and its group name — the key ranking above the label, and the label above the description. A query of three characters or fewer matches only against the key and the label, so a short fragment cannot drag in loosely worded descriptions. An empty query lists nothing rather than everything.

Choosing a result takes you to where that value actually lives and opens it. A subgroup that is not offered on your deployment is removed from the palette as well as from the cards and the tree, so search cannot reach a screen your deployment does not have.

Changing a value, and what confirms it

Opening a value gives you an editor built from that value's own rules: an enumerated value offers its choices, a bounded number rejects an out-of-range entry as you type, and the platform is asked to validate your candidate before Save becomes available. If that validation call fails, Save stays disabled and says so — a value is never saved against a verdict nobody gave.

A dangerous value asks you to type its key exactly before Save is enabled. Navigating away from an unfinished edit raises a choice between Keep editing and Discard changes. If another administrator changed the same value while you had it open, the save is refused and you are told to reload rather than to retry.

When a saved value takes effect

This is the part that most often surprises. A saved value does not always apply at once, and the editor states which of these it is, in words, beside the value:

Live — published to the services that read it and in force on the next operation. No restart.
Forward only — the change is in force but does not reach back: a rescheduled job takes its new schedule on save, and a cache lifetime applies to new entries while existing ones keep the lifetime they were created with.
Restart required — the value binds when a service starts, so it is stored now and applied when the service is restarted.

A value of the third kind is saved, marked as waiting, and raises a Restart required banner naming how many values wait. The banner never clears by itself. View pending restarts lists exactly which keys are waiting and the command that applies them — a command the platform computes from the environment it is running in, so when it can name none the banner still reports the pending restart and simply offers nothing to copy, rather than an instruction meant for another environment.

Secrets

A secret is never shown to you. The platform substitutes a mask for its value before sending it, so the console has no copy of it and there is no reveal control anywhere on this surface. What you can read is whether one is stored: every value shows Set or Not set beside the layer that supplied it, and for a secret those are two different facts — a stored credential and a code default can both be true at once.

Editing a secret gives you an empty field, not the mask. Typing replaces the stored value outright; submitting the mask itself, or an empty value, is refused rather than written. Resetting a secret does not restore a default, because a credential has none — it clears what is stored, and the confirmation says so.

Values you cannot change here

Some values carry a lock instead of an edit control, and there are two different reasons, labelled apart because they need different actions from you:

Diagnostic — an observation the platform reports about itself. There is nothing to set.
Deployment — a real parameter, but one the deployment owns. Its value comes from an environment variable, the entry names that variable, and you change it by editing the deployment environment and redeploying.
N/A — a value that applies only to ANKA-hosted deployments. It is shown, it is never writable here, and a write is refused before anything else is checked.

Subgroups that administer records

Six of the 38 subgroups hold no configuration value at all. They sit in the tree because that is where an operator looks for them, but each administers records with a lifecycle of their own rather than a list of values: Counterparty Types, Observability Export, SIEM / XDR Forwarding, Platform Alerts, Workload Identity Federation and Managed key backends by Edition. The last of those is not offered on a customer-operated install.

How it relates to other screens

Two of the eight groups are documented here so far, and the subsystems inside them have pages of their own:

What this surface configures, another screen draws: the map of everything your installation is connected to, and the policies tenants inherit, are decided elsewhere.