MQTT QoS Applies to Each Delivery Path, Not the Whole AI Workflow

Follow the publication to the recipient the task requires

Consider a factory-data offer that advertises QoS 2 while supplying both an archive input and an AI feature-building input. The useful purchase question is whether the promised evidence reaches each required consumer. MQTT's publish/subscribe model lets a publisher send to a broker and multiple clients subscribe to relevant topics. Those clients can serve different purposes. An archive client's receipt can be valuable without answering whether the feature-building client obtained its input. Name the publisher, broker and required subscriber before interpreting a delivery claim. MQTT 5.0's delivery scope treats each receiving client independently.

References: [MQBG][MQ50]

Keep the useful delivery property of each QoS level

The reference for this comparison is MQTT Version 5.0, the OASIS Standard dated 7 March 2019. For a sender–receiver delivery, QoS 0 is at most once: arrival can occur once or not at all, without MQTT acknowledgment or retry for that exchange. QoS 1 provides at-least-once delivery, allowing duplicates. QoS 2 provides exactly-once message delivery; acknowledgment and receiver-state rules prevent repeated protocol traffic from becoming duplicate delivery of that message. These are useful, different contracts. For example, an application able to tolerate missing occasional display updates can have a different requirement from an application needing every published input. The QoS number alone leaves that task requirement unspecified.

References: [MQ50][MQBG]

Use the granted subscription maximum in the onward comparison

Section 3.8.4 requires the server's subscription response to identify the granted maximum QoS or a subscription failure. A successful grant can be lower than the requested level. Rule MQTT-3.8.4-8 makes onward QoS the minimum of the original publication QoS and that granted maximum. A request for QoS 2 therefore cannot stand in for evidence of a QoS 2 grant. When comparing an offer, use its actual granted subscription contract. A subscriber's QoS 2 grant likewise leaves an originally QoS 0 publication with QoS 0 onward delivery.

References: [MQ50]

MQ-41: one publication creates two different onward paths

Fictional case MQ-41 has one nonretained publication M arriving at one broker with QoS 2. A and B each have exactly one matching ordinary, nonshared subscription. A's granted maximum is 2; B's is 0. There are no overlapping filters, expiry or other messages. Successful publisher-to-broker protocol completion, including broker acceptance of M, is stipulated. A is intended to supply an archive application; B is intended to supply a feature-building application. Applying the minimum rule gives min(2, 2) = 2 for the broker-to-A path and min(2, 0) = 0 for the broker-to-B path. The original payload is the same, but the onward delivery contracts differ. These invented premises are an explanation of the rule, rather than a broker test or a recommended system arrangement.

References: [MQ50]

Publisher completion and an A-only observation establish different facts

At the case's observation cutoff, stipulate one observed MQTT delivery of M to A, no observed delivery to B and no supplied application result from either consumer. The publisher-to-broker completion establishes the successful incoming QoS 2 transfer. The later A observation establishes that M reached A through its separate delivery path. There remains one original publication, with one observed subscriber delivery in the supplied record. Neither observation establishes B's receipt. B's missing observation also supplies no fault cause: the case does not determine whether B received M outside the available record or did not receive it. No accepted archive record or feature input is documented. That means the task outcomes are unknown; it does not mean zero business effects occurred. Counting these observations as two completed application tasks would replace missing evidence with an invented result.

Receipt leaves the application's processing result to identify

Section 4.3.3's Figure 4.3 footnote permits QoS 2 acknowledgment before onward delivery finishes. Rule MQTT-4.5.0-2 also requires a client to follow the applicable acknowledgment rules even if it elects not to process the message. Receipt and ownership therefore carry a bounded, useful meaning. In MQ-41, an A-delivery record still leaves the archive application's accepted record to identify. Even a later B-delivery observation would leave the feature application's consumed input and resulting task outcome to identify. Exactly-once delivery on a defined MQTT path supplies no independent evidence that an external database committed once or an inference application completed once.

References: [MQ50]

Choose evidence that reaches the required consumer and task

Suppose the buyer requires an archive record and a feature input corresponding to every publication in an agreed set. An offer supported only by MQ-41's publisher completion and A observation leaves that requirement unresolved, regardless of its headline QoS label. Have the appointed platform provider identify the evidence connecting each relevant publication to the required subscriber and the application's accepted input, with a defined observation cutoff. The application result needs to say what was consumed or accepted; a generic connected status cannot supply that relationship. If the requirement is instead a latest-state display that permits omissions, compare the offer against that stated tolerance. Neither case yields a universal QoS recommendation. Select a contract whose recipient coverage and application evidence match the actual task, including any separately promised continuity during interruptions. This is an evaluation of an offer's stated behavior and records, rather than an instruction to operate a control system.

Keep input coverage alongside the delivery contract

MQ-41 begins with M already created. It supplies no evidence that M contains every observation the factory-data task needs, that its values have the intended meaning or that its source attribution is correct. A perfectly delivered incomplete input remains incomplete for a task requiring the omitted information. Use the related OPC UA sampling and queue guide for the earlier capture-and-retention decision. Use this MQTT comparison for the later publication and subscriber paths. Additional AI processing cannot turn an absent observation into a supplied measurement.

Scope a separate equipment-cabling requirement

If the selected equipment also needs physical network connections, Leviathan's Structured Cabling & Fiber Installation service covers agreed fiber and copper installation against approved pathways, endpoint schedules and labeling rules. Use the related service and project inquiry with a nonconfidential outline of the equipment, connections, materials responsibilities and required connection records to discuss scope and availability. MQTT integration, broker operation and application acceptance belong with the separately appointed software and process teams. A physical cabling engagement establishes its agreed installation handoff.

References: [L1]