DMSS (Decision-Model Safety System)

DMSS adds a second opinion to Evonic’s safety pipeline. Where HMADS scores a command with local rules, DMSS asks a decision model whether the command should be allowed, reviewed, or blocked — and records what it said.

It applies to bash and Python (runpy) tool calls.

How a command is decided

The Safety page shows this flow live as you change the policy:

An agent runs a command — a bash or runpy tool call.
HMADS scores it — always in HMADS-only and shadow modes; only as a fallback in enforce mode.
The DMSS model evaluates it — skipped entirely while DMSS is off, recorded and compared in shadow mode, decisive in enforce mode.
A verdict is applied — a command is never left undecided.

There are three policies, picked at the top of the Safety page:

Policy	What happens
HMADS only	The model is never called. Only local rules decide. Zero extra latency.
DMSS enabled + Shadow	The model’s verdict is recorded and compared, but HMADS still decides.
DMSS enabled + Enforce	The model decides first. HMADS runs only when the model’s answer is unusable.

Choosing the model

DMSS uses a model whose Type is Decision (see Models). Its provider supplies the endpoint, credentials, and protocol adapter, so DMSS never stores a URL of its own.

Create or check the model in System › Models.
Open Safety and choose DMSS enabled.
Under Connection → Decision model, pick the model. An empty list means no decision model is configured yet.

The same card holds the guardrails around model calls:

Setting	Default	What it does
Timeout	1500 ms	How long DMSS waits before falling back to HMADS.
Minimum confidence	0.90	Answers below this abstain, and HMADS decides.
Maximum payload	12000 chars	Longest command payload sent to the model.
Circuit failures	3	Consecutive provider failures before the circuit opens.
Circuit cooldown	60 s	How long the circuit stays open before one probe call is allowed.

Settings save automatically as you change them, and a Diagnostic tester below the form sends a sample payload through the provider end-to-end. It is diagnostic only — production decisions, telemetry, and the circuit breaker are untouched.

When HMADS takes over

In enforce mode, a confident DMSS decision is final. HMADS steps in as the fallback when DMSS is unusable:

the call times out (request_timeout_ms)
the provider returns an error
the circuit breaker is open
the answer is malformed
confidence is below minimum_confidence

Identical inputs always produce identical outcomes, so a provider outage never leaves a command undecided.

Enforce behaviour: two switches

Enforce mode has an Enforce behaviour section with two toggles:

Record allowed decisions

When on, every allowed command is stored in the activity table. Refusals are always stored, whatever this switch says.

Turn it off when you only care about what was blocked — but note that it leaves no trace of what the model cleared, which makes later audits harder.

HMADS safety floor

Off by default, so model-first enforcement really is model-first.

Turn it on when local HMADS rules must still apply — for example git add -A, which HMADS wants to review but a model might wave through. With the floor on, every command is scored by HMADS as well, and its verdict can raise the DMSS severity, never lower it. The floor only makes a decision stricter.

This is the internal hmads_floor setting; it is stored as decim_safety.hmads_floor.

DMSS: allow (0.94)   HMADS: requires_approval
Floor off → allow    Floor on → requires_approval

Health and activity

The DMSS tab opens with an overview card showing whether DMSS is enabled, the active mode, the circuit state, and a recording indicator when decisions are being written to the activity table.

Below it, the activity table lists commands an agent ran side by side:

Column	Meaning
When	Timestamp of the check
Agent	The agent that ran the command
Command	A redacted command preview
HMADS	What the deterministic rules said
DMSS	What the model said, if it was called

You can filter by agent, by engine (decided_by), and by verdict. Click a row for the detail modal: the recorded command preview, how it was detected, and the final decision.

If the store cannot be read, the table says “activity storage unavailable” with the reason instead of showing an empty list.

What leaves the machine

Only a small, versioned policy packet is sent: the command and the tool type. No agent context, environment values, credentials, or conversation history leaves the process.

If a command contains something that looks like a secret (an API key, token, password, or a credential in a URL), the payload is not sent at all — redaction could change what the command does — and the command falls back to HMADS.

Every DMSS decision also writes one [dmss-audit] log line stating whether it was recorded and why.

Configuring DMSS

Go to System › Models and confirm you have a model with Type = Decision.
Open System › Safety and select the DMSS tab.
Choose DMSS enabled, then pick Shadow to observe first.
Wait a day, then read the activity table: compare the HMADS and DMSS columns.
When you are happy with the model’s calls, switch to Enforce.
Decide on Record allowed decisions and HMADS safety floor for your environment.
Run one harmless command and watch the flow diagram and activity table update.

Example — a cautious rollout:

Week one: Shadow, with the model recorded but not trusted.
Week two: Enforce with HMADS safety floor on, so local rules still catch git add -A.
Week three: keep the floor on; turn Record allowed decisions on for a full audit trail.

HMADS — the deterministic rules DMSS falls back to
Models — creating a decision model
Security Hardening — the wider security surface