Product

StørmDecision: policy-first fusion for bounded decision objects

Fuses inference, behaviour, and graph reasoning into a bounded decision object with policy references, rationale, required actions, and scope.

Not an alerting or analytics layer; it produces enforceable decision objects.

Role in the pipeline

Decision object contract

StørmDecision fuses StørmAI inference, StørmBehaviour state, StørmGraph reachability, and policy bundles to emit a bounded decision object and enforcement plan for StørmControl.

Policy-first decisioning: hard constraints override probabilistic scores.
Fused signals from inference, behavioural state, graph reasoning, and trust context.
Decision objects include action recommendations, policy references, and rationale.
Hysteresis and rate controls prevent oscillation during surges.
policy decision workflow

Contract: inputs → decision object

Policy-first fusion of signals into bounded outputs.

Inputs

StørmAI inference, StørmGraph reachability, and policy bundles.

Processing

Policy-first fusion with trust context and hysteresis controls.

Outputs

Decision objects to StørmControl and sealed records to StørmVault.

How it works

Three steps from validated inputs to a bounded decision.

Validate inputs

Verify signal provenance, policy bundle versions, and trust context.

Fuse via policy-first logic

Apply hard constraints before probabilistic weights.

Emit decision + rationale

Create a bounded decision object with explainability fields.

Interfaces

Interfaces

  • Inputs: StørmAI inference, StørmBehaviour state, StørmGraph reachability, policy bundle.
  • Outputs: bounded decision object and enforcement plan for StørmControl.
  • Contracts: policy bundle versioning and explainability fields.
  • Failure semantics: timeouts, safe defaults, and human-ack hooks.
stormdecision interfaces
How to think about StørmDecision

Policy gate for probabilistic signals.

StørmDecision is the policy-fusion layer, not an alert stream.

It binds probabilistic signals to hard constraints and trust context.

The output is a bounded decision object ready for enforcement.

Why this is not a rules engine: policy-first decisions are always attached to evidence context.

Contracts & guarantees

Decision object contracts.

  • Policy constraints override probabilistic scores.
  • Decision objects include action, rationale, and policy references.
  • Trust context and signal provenance are attached.
  • Hysteresis and rate controls prevent oscillation.
  • Sealed records are written to StørmVault.
decision contracts
Decision object fields

Decision object fields

  • Event id and classification.
  • Confidence summary.
  • Allowed actions and scope.
  • TTL and expiry bounds.
  • Rationale summary.
  • Evidence pointers to StørmVault.
decision object fields

Capabilities

Signal fusion, decision outputs, and evidence capture.

Guarantees

Policy-bounded, explainable decisions

Hard constraints cannot be overridden; outputs stay within policy and trust context with explainability hooks and stability controls. So what: decisions remain bounded and defensible.

Inputs

Signals + policy + trust context

StørmDecision consumes the following inputs:

  • StørmAI inference objects with model provenance.
  • StørmBehaviour state transitions and invariants.
  • StørmGraph reachability and blast-radius outputs.
  • Policy bundles, clauses, and governance epochs.
  • StørmTrust trust context (session state, artifact verification).

So what: every decision is tied to attributable inputs.

Outputs

Bounded decision object + enforcement plan

Emits a decision object to StørmControl, operator notifications to StørmOps, and a sealed record to StørmVault. So what: enforcement receives actionable, traceable plans.

Evidence & audit

Sealed rationale and provenance

Decision objects record the triggering event, contributing signals, graph context, policy clauses, and confidence context. Records are sealed and indexed in StørmVault. So what: audits can reconstruct decisions end to end.

What StørmDecision will not allow

Hard boundaries for policy-first decisioning.

Policy override

Probabilistic scores cannot override hard policy constraints.

Unattributed decisions

Decisions without provenance, policy refs, or rationale are rejected.

Unbounded oscillation

Hysteresis and rate controls prevent repeated action loops.

Works with

Enforcement, evidence sealing, and operational oversight.

FAQ

Common questions about decision objects.

How are policy updates handled?

Policy bundles are versioned and signed; decisions reference the active policy version.

Is the decision explainable?

Yes. Rationale, contributing signals, and policy clauses are attached to each decision.

Why is there a TTL?

Expiry bounds prevent stale decisions from being executed outside their valid window.

Request a StørmDecision demo.

Review decision contracts, schema, and evidence outputs.