Product

Størm Engine: event-level enforcement pipeline

Event-native pipeline that admits PQC-bound events and emits bounded decisions.

Inputs → outputs: trusted events + deterministic features + inference + behaviour + graph + policy → bounded decision object + enforcement plan + sealed evidence.

Not a SIEM or rules engine; it is a real-time enforcement pipeline.

Role in the pipeline

Role in the pipeline

Størm Engine is the system-level enforcement pipeline that admits PQC-bound events, normalizes semantics, runs inference, updates behavioural and graph state, and emits bounded decisions within configured latency tiers.

Admission contract: PQC session binding, anti-replay ordering, and schema validation; failures are rejected or quarantined.
Deterministic preprocessing with signed feature schemas; same event and context yield the same vector.
Probabilistic inference is fused with policy constraints and graph reachability for bounded decisions.
Decision objects, provenance, and enforcement receipts are sealed in StørmVault.
How to think about Størm Engine

A deterministic pipeline with bounded AI.

Størm Engine treats every event as a state transition.

Deterministic preprocessing feeds probabilistic inference.

Policy-first fusion bounds actions and seals evidence.

storm engine mental model
Contracts & guarantees

Pipeline contracts.

  • Admission requires PQC session binding, ordering, and schema validation.
  • Deterministic preprocessing yields stable feature vectors.
  • Probabilistic inference is bounded by policy constraints.
  • Latency targets are tiered and configurable per stream.
  • Decision objects and provenance are sealed in StørmVault.
pipeline contracts
System contracts

System contracts

  • Bounded latency targets per enforcement tier.
  • Deterministic preprocessing and replay safety.
  • Provenance for models, policies, and schemas.
  • Evidence sealing and chain-of-custody.
system contracts
How to evaluate

Acceptance criteria

  • Latency budget meets enforcement tier requirements.
  • Audit reproducibility from event to decision.
  • Policy governance with versioned approvals.
  • Segmentation by trust domain and role.
  • Integration surfaces for data, policy, and execution.
evaluation criteria

How Størm Engine works

Three steps from admission to sealed enforcement.

Admit trusted event

PQC-bound sessions, schema validation, and deterministic feature construction.

Fuse signals into decision object

Inference, behaviour, graph reachability, and policy constraints combined.

Enforce + seal evidence

Action receipts and decision records sealed into StørmVault.

Interfaces

Interfaces

  • Inputs: trusted events, deterministic features, policy bundles, trust context.
  • Outputs: bounded decision object, enforcement plan, sealed evidence records.
  • Contracts: schema and policy bundle versioning with signed provenance.
  • Failure semantics: timeouts, fallbacks, and bounded safe-mode behavior.

Capabilities

Deterministic admission and feature construction feed probabilistic inference, graph reasoning, and policy-first decisioning.

Admission & normalization

Trust-bound intake and deterministic features

StørmTrust establishes PQC sessions and signs artifacts. The Størm Ingest Gateway enforces ordering, schema checks, and backpressure. StørmPrep outputs canonical events and deterministic feature vectors. So what: only trusted, normalized events reach inference.

admission and normalization pipeline
Inference & behaviour

Probabilistic signals with controlled learning

StørmAI runs multi-model inference with micro-batching and reserved capacity, emitting versioned probabilistic scores. StørmBehaviour maintains state machines and invariants; learning is gated by trust state. So what: probabilistic signals remain bounded and attributable.

Graph & decision

Reachability plus policy-first fusion

StørmGraph maintains event and trust graphs and computes reachability and blast radius. StørmDecision fuses AI, behaviour, and graph signals under hard policy constraints to produce a decision object. So what: decisions are scoped to actual reachability.

Control & evidence

Enforcement with audit sealing

StørmControl executes actions with acknowledgements and timeouts. StørmVault seals events, decisions, and provenance, while StørmOps monitors latency, drift, and change control. So what: enforcement is auditable and operationally governed.

What Størm Engine will not allow

Hard boundaries for event-level enforcement.

  • Untrusted events without PQC session binding or schema validation.
  • Non-deterministic preprocessing that breaks reproducibility.
  • Policy overrides by probabilistic scores.
  • Unbounded latency backlog for enforcement-critical tiers.
  • Decisions without sealed provenance and rationale.

Where it fits

Key interfaces across the Størm Engine suite.

Request a Størm Engine demo.

Review the architecture and pipeline contracts for event-level enforcement.