About TrailMQ

TrailMQ was created to bridge the gap between machine-level messaging and the requirements of regulated, quality-critical and audit-heavy environments.

It started with secure MQTT control and audit evidence. Its planned plugin layer extends that idea: live MQTT messages can be enriched with domain context, compared against historical baselines and linked to decision traces.

Why TrailMQ exists

Standard MQTT brokers are optimized for throughput and simplicity. In industrial and regulated environments, this is often not enough.

Quality assurance, validation teams, OT engineers and platform owners need answers to questions like:

• What exactly happened, and in which order?
• Who sent what, and under which policy?
• Why was a message accepted, denied or rate-limited?
• What does this MQTT message mean in machine, batch or process context?
• Which historical baseline was used for this value?
• Was the value normal, warning-level or critical?
• Was a calculation completed, deferred or failed?
• Was anything lost, modified or blocked?

TrailMQ exists to make these questions technically answerable.

From transport to evidence

A standard broker answers one basic question: did the message move?

TrailMQ is designed to answer more useful questions — what the message meant, which policy applied, which context was attached, which historical reference was used, which decision was made, and whether the result can be reviewed later.

That turns MQTT from a pure transport mechanism into a source of structured, reviewable evidence.

What is available now

The current evaluation build is a full self-hosted stack:

MQTT broker TLS on port 8883 and WebSocket transport. Standard MQTT clients connect without modification.

Policy engine Versioned access rules control which clients can publish or subscribe to which topics. Policy versions are recorded with every audit event so later reviews can match decisions to the rule set that was active.

Audit trail Broker decisions are written as hash-chained, sequenced records. The chain can be verified to detect gaps or tampering.

Identity and user management Users, roles and client credentials are managed through the REST API and admin UI. Change events are linked to the audit record.

Connected client visibility The REST API surfaces which MQTT clients are currently connected and what topics they access.

Queue and dead-letter visibility Queue state and dead-letter entries are inspectable through the REST API without requiring broker-level access.

REST API Full programmatic access at /api/v1. Covers authentication, topics, clients, users, policies, queue state, audit evidence, plugin state and system capabilities.

Admin UI A React-based admin interface served at /trailmq/. Covers topic management, user and client management, policy review, audit evidence and queue status — without requiring API knowledge.

Plugin architecture The system includes plugin slots with capability discovery through the API. Plugin state and available capabilities are inspectable at runtime.

Planned plugin layer

The planned plugin layer is focused on one practical goal: make MQTT messages more understandable, comparable and reviewable in process terms. The first planned embedded plugins are:

• Decision Trace — explains why accept, deny or rate-limit decisions happened
• Domain Context Lite — extracts machine, batch and metric context from topics and payload headers
• Historical Context Feed — accepts historical comparison values through REST
• KPI Lite — compares live MQTT values with historical baselines and records deviations

Together, these plugins support a concrete flow:

1. A live MQTT value arrives.
2. TrailMQ extracts domain context from topic and payload data.
3. A historical baseline is resolved through the context layer.
4. KPI Lite calculates the deviation.
5. The result is linked to the audit chain.
6. If context is missing, the calculation is deferred instead of silently skipped.

Audit-first, not audit-later

TrailMQ treats auditability as a core design principle, not an afterthought. Instead of relying on log files and external tooling, it embeds the following directly into the messaging layer:

• Policy-driven enforcement
• Hash-chained audit trails
• Retention and sequencing rules
• Explicit violation handling
• Queue and dead-letter visibility
• Evidence-oriented API surfaces

Explain, don’t expose

TrailMQ explains decisions and enforcement without turning itself into a raw message inspection tool. The core system surfaces who connected and with what permissions, which policies were enforced and why, and exportable audit evidence for review. The planned plugin layer adds domain context, historical baselines and calculation outcomes where those richer process signals are configured.

You do not need to expose TrailMQ as a general-purpose live debugging console. This is by design: evidence over observation.

Built for regulated and quality-critical environments

TrailMQ is designed to support validated systems, not to replace validation processes or claim certifications. It provides audit-ready technical evidence that can be used within existing quality, validation and compliance frameworks.

TrailMQ supports workflows aligned with GMP / GxP requirements, 21 CFR Part 11 (electronic records), Annex 11 (computerized systems), GAMP 5 guidelines, industrial traceability and review workflows, and quality-critical IIoT architectures.

Beyond pharma

Pharma and life sciences are the clearest starting point because auditability, traceability and data integrity are explicit requirements. But the same product logic applies anywhere machine communication needs to be understood and reviewed later:

• Automotive production and test stands
• Food and beverage manufacturing
• Chemical and process industries
• Energy and utilities
• Rail and maintenance operations
• Building automation
• Logistics and cold-chain monitoring

The common question is always the same: what happened, why was it relevant, and can we prove it later?

Deployment model

TrailMQ follows an evaluation-first model:

• Free to evaluate — deploy via Docker, test locally, integrate into your workflows
• No registration required — clone the GitHub repo and run the launcher
• Commercial licensing — production use in regulated or commercial environments requires a valid license

The deployment files are available on GitHub. Container images are hosted on Docker Hub: trailmq-backend and trailmq-frontend.

About the author

TrailMQ is maintained by Florian Przybylak, working on the architecture of regulated industrial systems, data pipelines and trustworthy automation. — LinkedIn