{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibfebuo2z774dvc2hqzwtzuocaruor3hhwxo2od6wfgig64sllaga",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mm5vwkptjcz2"
  },
  "path": "/t/new-jneopallium-mqtt-sparkplug-b-bridge-safe-biologically-inspired-ai-for-industrial-unified-namespaces/176089#post_1",
  "publishedAt": "2026-05-18T21:42:44.000Z",
  "site": "https://discuss.huggingface.co",
  "tags": [
    "https://github.com/rakovpublic/jneopallium"
  ],
  "textContent": "Hey HF community!\n\nIf you’re into neuromorphic / biologically-grounded AI and you also work with real-world industrial systems, I’m excited to share something fresh from the Jneopallium project. We just shipped a full-featured MQTT bridge (with native Sparkplug B support) that lets the Jneopallium neuron network act as a cognitive layer on top of any MQTT-based IIoT / unified-namespace architecture — while staying strictly advisory-only for safety. Why this mattersJneopallium is an open-source Java framework (BSD 3-Clause) that models natural neuron networks with typed signals, multi-receptor neurons, dual fast/slow processing loops, and built-in autonomous-AI safety (harm discriminator, hard constraints, transparency logging). The new MQTT bridge turns it into a drop-in cognitive engine for factories, energy plants, water utilities, etc.Key highlights of the bridge:\n\n  * Full Sparkplug B session state (NBIRTH/DBIRTH/NDATA/DDEATH/… + metric aliasing & wildcards)\n\n  * Plain MQTT JSON fallback for greenfield devices\n\n  * Structural ADVISORY ceiling — the aggregator never publishes to real DCMD actuator topics. All writes go to a configurable /advisory/ namespace so the HMI/operator stays in the loop.\n\n  * Per-binding SHADOW ADVISORY modes (AUTONOMOUS is rejected at config load time)\n\n  * Full audit trail (JSONL + optional MQTT mirror) with clamp, queue-full, and transport-failure records\n\n  * Quality & timestamp propagation from Sparkplug metrics\n\n  * Zero extra dependencies — everything is already in the worker artifact\n\n\n\n\nQuick start (5 minutes)\n\nyaml\n\n\n    # mqtt-bridge.yml\n    connection:\n      brokerUrl: \"ssl://broker.plant.local:8883\"\n    sparkplug:\n      enabled: true\n      groupId: \"Plant1\"\n      edgeNodeId: \"Jneopallium-Edge-01\"\n      advisoryNamespace: \"advisory\"\n    reads:\n      - bindingId: \"TIC-101\"\n        sparkplugMetric: \"Plant1/Edge-Reactor/Reactor1/temperature\"\n        signalTag: \"PLANT.TIC101.PV\"\n        signalKind: MEASUREMENT\n    writes:\n      - bindingId: \"TIC-101-ADV\"\n        advisoryTopic: \"spBv1.0/Plant1/DCMD/Edge-Reactor/Reactor1/advisory/setpoint_temperature\"\n        signalTag: \"PLANT.TIC101.SP\"\n        minClampValue: 0.0\n        maxClampValue: 100.0\n        qos: 1\n    perTagSafetyMode:\n      TIC-101-ADV: ADVISORY   # start in SHADOW, promote after validation\n\n\nThen just wire it into your worker bootstrap (see the full manual in the repo). The bridge re-subscribes automatically on reconnects and plays nicely with the rest of the Jneopallium pipeline.How it fits the bigger pictureThe industrial-process-control module already ships oscillation monitoring, cascade-loop stabilization, and PID-style neurons. The MQTT bridge is the clean, auditable on-ramp that lets the network observe thousands of Sparkplug metrics and recommend setpoints without ever touching a real actuator. Perfect for shadow-mode pilots → advisory → (eventually) autonomous loops routed through OPC UA/PLC4X where safety demands it.We also have an optional LLM advisory layer (which can consume HF models via the existing integration) that can be cross-validated against the internal world model before any recommendation is emitted. So yes — you can literally bring your favorite HF model into the loop as a non-blocking knowledge source!Come play / contribute!\n\n  * Repo: https://github.com/rakovpublic/jneopallium\n\n  * Full MQTT manual (with bootstrap code, audit schema, session-state details, smoke-test instructions): docs in the repo + attached in the original release\n\n  * Looking for contributors in:\n\n    * FPGA / gRPC deployment path (low-latency industrial edge)\n\n    * Richer plain-MQTT JSONPath / schema support\n\n    * More domain examples (energy, water, pharma)\n\n    * HF model → Jneopallium neuron adapters\n\n    * Performance benchmarks on real Sparkplug brokers (HiveMQ, EMQX, Mosquitto)\n\n\n\n\nIf you’ve built IIoT cognitive layers before, or you just want to try a biologically-plausible alternative to pure RL/LLM agents in industrial settings, I’d love to hear your thoughts! Drop a reply with:\n\n  * Your typical broker/stack (Mosquitto? HiveMQ Edge? Ignition?)\n\n  * Whether you need Sparkplug B or plain MQTT\n\n  * Any safety / audit requirements you care about\n\n\n\n\nHappy to hop on a quick call or review PRs. Let’s make industrial AI safer and more brain-like together! (Full paper “Jneopallium: A Biologically Grounded Framework…” is also available if you want the 30 000 ft view of the whole architecture.) Looking forward to your feedback!",
  "title": "New Jneopallium MQTT + Sparkplug B Bridge: Safe, Biologically-Inspired AI for Industrial Unified Namespaces"
}