3 Systems Thinking: Decision Records and Communication

3.12.1 Start With Flow, Not Protocol

Picture a cold room with one sensor and one cooling unit. The sensor sends a temperature every minute. A worker can also change the target. An open door must trigger a local warning. A repair note can wait until the office system is ready.

These messages do different jobs. A communication model describes the shape of each exchange. It asks who starts. It asks who waits. It asks whether one or many receivers need the message. It also asks what happens when the other end is missing.

Use four simple shapes. A request asks for a direct answer. A published event lets several listeners react. A local event can act without a distant service. A queued task can wait for later work. The same product may need all four.

Choose from the consequence. A late repair note is inconvenient. A late cooling command may spoil stock. A missed door warning may need local action. Record when a retry is safe. Record how the receiver proves that it acted. Keep the owner of each wait clear.

This first view gives each message one tidy shape. Real systems can combine shapes and cross several trust boundaries. The Practitioner layer turns each flow into a design record. Under the Hood examines delivery state, duplicate action, outage behavior, and the cases where a simple arrow hides important responsibility.

Communication models describe how a message behaves before the team chooses HTTP, CoAP, MQTT, AMQP, WebSocket, a queue, or a stream. The model names who starts the exchange, who consumes it, whether the sender waits, what happens during outage, and what evidence proves the flow worked.

In a refrigerated warehouse, the same gateway may need four different communication models. Temperature telemetry can be pushed every minute and published to a broker so a dashboard, history store, alert service, and maintenance model can consume it independently. A compressor setpoint change should behave like a request-response command: the operator needs to know whether the gateway accepted, rejected, timed out, or deferred the change. A door-left-open event should run locally even if the cloud path is down. A maintenance report can be queued asynchronously because a technician can wait for a final work-order reference.

Do not carry Start With Flow, Not Protocol forward as an untested abstraction. Figure 3.3 anchors it in the visible claim that communication models turn message movement into an architecture boundary.

+

Use Figure 3.3 to compare the responsibilities named sense, act, sleep and Application, then inspect What evidence? for the consequence. This comparison explains why communication models turn message movement into an architecture boundary. It closes the visual loop back to Start With Flow, Not Protocol and the design choice now under review.

Request-response fits a command, query, enrollment step, or configuration change that needs an accepted-or-rejected result. Publish-subscribe fits telemetry, alarms, status, and fan-out where new consumers may appear later. Event-driven design fits meaningful state changes such as threshold crossings, failures, workflow transitions, and local safety actions.

The surrounding explanation becomes actionable when its components can be followed. Figure 3.4 provides that route for Start With Flow, Not Protocol, showing how the core patterns differ in waiting behavior, consumer coupling, and recovery evidence.

+

The visual argument in Figure 3.4 starts with Caller, turns on Dash, and becomes reviewable at Risk: noisy or non-idempotent events. These labels are the mechanism behind the core patterns differ in waiting behavior, consumer coupling, and recovery evidence. Their progression advances the chapter beyond the introductory statement of Start With Flow, Not Protocol.

3.12.2 Separate Timing and Outage Needs

The practical review is a flow table. For each flow, classify whether the source pushes or the consumer pulls, whether the sender waits synchronously or hands off asynchronously, whether the data needs fan-out, and what recovery evidence is required after outage.

The chapter now shifts from naming Separate Timing and Outage Needs to proving it. Figure 3.5 matters because it shows how push, pull, synchronous, and asynchronous are timing behaviors that can combine with the core patterns.

+

Read the diagram in Figure 3.5 by comparing Source sends when data or event appears with Consumer asks when it needs data. Then contrast Caller waits for the result with Sender continues; work completes later. Those pairs separate push from pull and synchronous from asynchronous behavior, carrying Separate Timing and Outage Needs into a per-flow outage and replay decision.

For a cold-storage facility, temperature telemetry usually fits push plus publish-subscribe because dashboards, history, alerting, and analytics can consume the same reading. A high-temperature alarm should trigger local event-driven behavior so safety action does not depend on cloud availability. A compressor setpoint change needs request-response because the operator must know whether the command was accepted, rejected, stale, unauthorized, or blocked by local limits.

Make the table concrete enough to test. For telemetry, write the topic name, timestamp rule, duplicate rule, and buffered replay rule. For an alarm, record the local threshold, latch behavior, operator acknowledgement, and the cloud event that proves it was later synchronized. For a command, record the requester role, freshness window, device state precondition, rejection reason, and audit event. Those fields matter more than whether the first implementation uses MQTT, CoAP observe, HTTP polling, WebSocket, or an AMQP queue.

Figure 3.6 compares communication models against the needs of each cold-storage flow.

+

Temperature telemetry can be published for several consumers and replayed after a link gap. A high-temperature alarm needs a local action when the cloud is unreachable. A compressor setpoint command has a different path: the requester needs an accepted, rejected, stale, or unauthorized result. The route asks about timing, fan-out, energy, connectivity, reliability, state ownership, and replay before assigning a model. Record the receiver and failure evidence for each flow, then choose a protocol that implements that model. One message pattern cannot satisfy all three just because it is convenient to deploy.

3.12.3 Model as Evidence Contract

Under the hood, a communication model is a contract about state, timing, replay, and ownership. A publish-subscribe flow is weak if nobody owns topic contracts or duplicate handling. A request-response flow is weak if the response only proves that a packet arrived, not that the command was fresh, authorized, and applied. An event-driven flow is weak if handlers are not idempotent or if local and cloud records disagree after recovery.

To keep Model as Evidence Contract auditable, the chapter now needs a visual contract. Figure 3.7 provides it by showing how the review record keeps protocol changes from erasing the original model reasoning, describing behavior first and implementation second.

+

Figure 3.7 separates Flow Name, Waiting Behavior, and Reopen the Decision so the reader can see where the claim might fail. Taken together, they show the review record keeps protocol changes from erasing the original model reasoning, describing behavior first and implementation second. That failure-aware reading connects the figure directly to Model as Evidence Contract and its later proof obligations.

Protocols can change while the model remains stable. A telemetry path can move from one broker to another if the topic contract, timestamp rule, retained-state rule, replay behavior, and consumer expectations still hold. A command path can change transport if it still preserves freshness, authorization, applied-state proof, rejection reasons, and audit evidence. That is why the review record should describe behavior first and implementation second.

The hardest failures usually come from hidden model changes. A "simple" dashboard feature may turn one telemetry consumer into five consumers and require publish-subscribe fan-out. A firmware update may turn a configuration write into a safety-relevant command that needs a response contract. A battery-saving change may make pull polling impractical because devices sleep longer. Treat those changes as model changes, not only protocol changes.

3.12.4 Summary

IoT communication models explain how each flow behaves: who starts it, who consumes it, whether the sender waits, what happens during outage, and which evidence proves the behavior. Start with the flow, split mixed requirements, choose request-response, publish-subscribe, event-driven, push, pull, synchronous, asynchronous, or hybrid behavior where it fits, and then choose the protocol that implements the selected model with clear ownership.

3.12.5 Key Takeaway

3.12.6 See Also

Pick the message model from flow needs. Check time, replay, and owner before protocol choice.