Did my change save?

Every save or apply control in the console ends in one of three visible states. You never have to guess.

The three endings

• Saved · View in audit log. The server accepted the change and wrote it to your book together with an audit line in the same step; the link opens that exact line on Activity › Config. Changes that loosen risk, raise autonomy, widen who can see the book or touch broker credentials also say code verified.
• Not saved, followed by the server's reason. Nothing changed. The dialog stays open with what you typed so you can fix it and press the button again. A red toast repeats it (for a posture: "Posture not changed, still Moderate").
• Nothing was sent, try again. The click never reached the server (a stalled tab, a lost connection at the wrong moment). Nothing changed; press the button again. This is the case that used to be silent.

When settings pull against each other

You make three choices: the posture· Strategy › Profile › Posture, the approval line· Strategy › Profile › Autonomy and your guidance. Limits, the core sleeve share, how often the desk looks and which models run follow from those unless you override one; an overridden value says so, with the posture's value beside it.

Some combinations contradict each other: an Aggressive posture whose own position cap is below the size it calls a starter, a core sleeve larger than the exposure cap, a guidance rule that forbids everything the sleeve would buy, an approval line above the per-order cap, a model choice that is quietly ignored. When that happens:

• Strategy shows a banner, "N settings pull against each other", one line per problem with Fix on … pointing at the one screen that resolves it. Nothing in the banner changed a setting; the desk keeps running on what is stored.
• A save that would create such a contradiction is refused: the dialog stays open and says Not saved: this would make settings pull against each other, with the reason. Change the value, fix it on the screen named, or press Apply anyway, which asks for your authenticator code and is written to the audit log as a forced change.
• The Settings check lists the same findings, and for every setting a Changes: line: what the setting actually changes in the desk's behaviour, what it derives from, where it is edited, and how many behaviour tests prove it.

The Settings check page

Settings › Settings check lists every setting on the book you are looking at (risk limits, posture· Strategy › Profile › Posture, the approval line, halts, the never-trade list, the focus list, guidance, cadence and role configuration, the algorithm line-up, scheduled reports, who manages which position, the broker connection, sharing), each with:

• where it is stored, in plain words (they all live in the platform database; nothing is kept only in your browser);
• today's value and when it last changed and by whom, with a link to the audit line; a change made from a shell during an incident instead of the console is marked changed outside the console (no code check possible);
• who reads it: one chip per service (the Executor as the risk gate, the desk sessions of the PM, Researcher and Trader, Consult, the Scheduler) saying on the stored version, not picked up yet or no read yet. The Executor re-reads your limits, halts, never-trade list, holds, guidance rules and algorithm line-up on every loop, about every five seconds, and reports the version it holds within a minute; desk sessions read everything when a session starts; the Scheduler reads cadence on its next planning pass.

Verify now runs the read-back checks on the spot: every stored limit inside its bounds and matching its last audit line, the declared posture matching the limits· Risk › Limits, flags in a shape their readers understand, every service on the stored version, and no risk-loosening change in the last 30 days that skipped the authenticator code. Open it from the card on Settings or type "settings check" in the command palette. The platform owner can open it for any book from Admin.