Four no-code engines. Zero Rust files.

Engine comparison

Four engines · one platform.

MSP — Continuous dataflow

225 graphs. 20 domains. Single-digit-percent CPU budget.

MSP deep page →

AI Funnel — Declarative edge AI

TOML graph in. OTA out. No on-device toolchain.

The customer ships a TOML graph plus an ONNX/TFLite model and a COCO dataset. Munic cloud retrains, quantises, validates, packages, and OTAs. The on-device runtime executes camera → GPU → NPU with zero pixel-copy.

AI Funnel deep page →

Out of the box, together

One Python container drives all four engines.

The four engines are not silos. A single Python container, talking to the in-process MQTT broker, can drive MSP, MEP, Multi Stacks, and AI Funnel from one process — no Rust toolchain, no per-engine SDK, no custom glue.

c.publish(
    "mos/msp/LoadGraph",
    json.dumps({"name": "harsh_brake", "yaml": yaml_str}),
)

c.publish(
    "mos/mep/LoadPolicy",
    json.dumps({"name": "geofence", "yaml": policy_str}),
)

c.publish(
    "mos/multi-stacks/LoadStack",
    json.dumps({"name": "j1939_truck", "json": stack_json}),
)

c.subscribe("mos/ai-runtime/detections")
c.on_message = lambda _c, _u, m: handle(m.payload)

Same MQTT client, four engines, no language limit. Any MQTT-capable runtime — C, C++, Go, Rust, JavaScript — can do the same.

When no-code is not enough

Three programming tiers designed to coexist.

A typical MOS4 product mixes MSP for continuous signal processing, MEP for state-machine policy, Multi Stacks for vehicle or Modbus comms, AI Funnel for edge AI, a custom Rust micro service for the genuinely novel algorithm, and a Python or C++ container for the data-science team's classifier.

FAQ

Frequently asked questions

• How do the four engines fit together?

  MSP produces continuous named signals from sensor and bus inputs. MEP reacts to discrete triggers (signal threshold, event, cron) with state-machine policies. Multi Stacks talks to vehicle buses and industrial-IoT devices, driven periodically or composed with MSP/MEP. AI Funnel runs declarative edge AI — a TOML graph plus a model and dataset; Munic cloud retrains and OTAs. The four engines share one OS, one OTA channel, one off-target story.

• Is MEP a state machine or a T·C·A engine?

  Both readings ship. The product owner reads MEP as state-machine policies on the device — the policy YAML is the state machine. The engineer reads the same YAML as Trigger / Condition / Action primitives. There is no separate state-machine runtime; the composed rule set is the state machine.

• Is Multi Stacks the same as OBDStacks?

  Yes. OBDStacks is the legacy name; Multi Stacks is the canonical name as of 2026-05-05. Same engine, same JSON DSL, same default-stacks/ catalogue.

• Do I need hardware to test a policy or graph?

  No. The MEP standalone runner replays YAML scenario files off-target; the MEP lint tool catches errors statically. The MSP runner executes any .msp.yml with CSV inputs on macOS. The bundled ECU simulator covers Multi Stacks over virtual CAN. The AI runtime fake stubs inference for AI Funnel CI. All four engines have CI-level off-target runners.

• Does any of this require Rust?

  No. The four engines are configured with YAML, JSON, and TOML. The runtime is Rust, but the authoring surface is data files. A Python container can drive any of the engines over the in-process MQTT broker — see "Out of the box, together" below.

• When does the SDK path apply?

  When the algorithm genuinely cannot be expressed as a graph, a policy, a stack, or a TOML AI graph. Novel detection logic, proprietary model inference, custom hardware integration. The four no-code engines cover the bulk of the device-behaviour surface; Rust micro services, Python containers, and C++ containers cover the rest.