Talon MonitorTalon Studio v1.0.2-beta

Validation Settings

Run validation on demand, see what each check measures, and set how strictly validation results gate a release.

The Settings page

Talon Monitor → Settings (/validate/settings) has one control: the Validation Check panel, showing when the check last ran, its cadence (User-triggered only) and the Run Check button. Below it, What this check measures explains the two layers: environment readiness, and the simulation bonus from replayed attack telemetry.

Run Check is admin-only; other roles see it disabled with the reason. It runs an environment-readiness check on every detection in the organisation that isn't deprecated, five at a time.

One click works for about 45 seconds and then stops after the batch in flight, so a proxy or load balancer never times the request out. On a large organisation, detections it didn't reach keep their previous result.

Only one check runs at a time per organisation; a second click while one is running is refused.

How gating works

By default, validation gating is fixed behaviour rather than a toggle. Environment readiness is the hard signal: a detection whose latest readiness run failed can't run in the connected SIEM, so the release gate's Validation check reads failed and tells you to fix or deprecate it. Simulation, replay and drift only warn. The other operational blockers are a missing current Package and a Target without a recent passing preflight; Review is a warn-only signal.

An organisation can make behavioural failures bite too. validation_gate_policy in the git-backed org config (Org/organisation.yaml) is warn by default; set it to block and failing simulations, degraded or Git-sync-failed detections, and missing environment dependencies become release blockers. There is no switch for it in the UI — edit and commit the file, or set validationGatePolicy through the admin-only org settings API.

When re-validation runs

Readiness re-runs automatically for every active detection in a workspace whenever content lands on main — a commit from the working tree or a change-request merge — and change-request checks run on every commit to a change-request branch. Drift — a rule that used to pass and now fails — surfaces as degraded on the Monitor summary and in Command.

The only timer rides the Claw cycle

Nothing re-validates on a clock unless an admin has switched on the Claw coordinator (Talon Claw → Settings, off by default). With it on, each Claw cycle re-validates the detections the evidence-gap engine flagged as unvalidated, stale, failed or drifted — never the whole organisation — at most once per validation_interval_hours (set in Org/organisation.yaml; default 24, minimum 1), and replays attack data for them against a Splunk test target if there is one. DISABLE_SCHEDULED_VALIDATION=true turns that off while leaving Claw running. The Settings page's "User-triggered only" describes the Run Check panel, not this re-check.

Tip

Run a check by hand before you lean on the automatic ones — you'll see which detections pass, which fail environment readiness, and which have no Atomic test, so later runs surface real drift instead of a backlog of never-validated rules.