6 Managing Live Topology Changes

6.3 Topology Management Is Controlled Change To Network Evidence

This section: Topology Management Is Controlled Change To Network Evidence — Topology management is the discipline for changing which nodes participate, which roles they hold, which paths carry evidence, and which data is accepted for a decision.

Topology management is the discipline for changing which nodes participate, which roles they hold, which paths carry evidence, and which data is accepted for a decision. The change is useful only when the review record says what changed, why it changed, which decision path it affects, and what retest trigger makes the record stale.

The important distinction is that topology management is not the same as drawing a new network shape. A gateway can keep the same star-looking diagram while changing which sensors are trusted, which node acts as a relay, which route is used after a failure, or which readings are suppressed as stale. Each of those changes can alter the evidence seen by an alert, dashboard, control loop, or maintenance review. The topology-management record therefore has to preserve the before-and-after state, not just the final connected state.

A useful record answers four questions in plain terms. Which decision path is affected? Which nodes are in, out, fallback-only, or unavailable? Which role or route changed? What event forces a retest, rollback, or fresh review? Without those answers, the system may be connected but no longer auditable. That audit trail is the point of management.

+

Read the map as a review flow rather than an architecture diagram:

1. Review need — state the decision that needs topology support.
2. Active set — name the nodes or roles currently allowed to participate.
3. Roles — state whether each participant is a source, relay, observer, coordinator, or fallback.
4. Routes — show how accepted evidence reaches the next decision point.
5. Data value — decide whether a reading is new, confirming, contradictory, stale, missing, or rejected.
6. Mode change — state the trigger that changes participation, route, or acceptance rule.
7. Record — preserve the evidence and the bounded decision.
8. Retest — name the change that reopens the topology review.

Topology management is not a single algorithm. This module uses steps two to six as five practical decision types for reviewing the shape and behaviour of a live network; they are a working framework, not an exhaustive taxonomy of the discipline.

Each technique is bounded to the application question it supports. A change that is acceptable for a periodic status review may be unacceptable for a faster response path, or for a path that needs corroboration from several sources. A topology that passes messages is not automatically a topology that preserves decision evidence. Source identity, freshness, route role, quality state, rollback behavior, and excluded-source handling determine whether the topology change is safe to accept.

6.4 Practitioner Pattern: Write The Change Record Before Accepting The New Topology

This section: Practitioner Pattern: Write The Change Record Before Accepting The New Topology — Most topology-management failures come from accepting the new path too early.

Most topology-management failures come from accepting the new path too early. A relay change, active-set reduction, or denser observation mode should first be written as a bounded decision record: baseline, trigger, proposed change, evidence, impact, rollback, and retest.

Before writing that record, name which of this module's five decision types the change uses. Each one is reviewed against different evidence, and each one has a characteristic weak case that a reviewer should refuse.

For example, suppose a cold-room gateway stops hearing one corner sensor and promotes a nearby mains-powered device to relay. The change record should not simply say "relay enabled." It should name the affected temperature-alarm path, the old active set, the missing source, the new relay role, the first accepted messages through that relay, and the condition for reversing the change. If the missing sensor later returns, the record should say whether it is accepted immediately, held for quality review, or kept out of scope until a maintenance check confirms placement and freshness.

+

That shortcut keeps operations from treating topology management as an optimization-only step. The reviewer is not asking whether the new route is prettier or faster in isolation; the reviewer is asking whether the route still preserves source identity, freshness, quality state, affected decision, rollback option, and the next retest trigger. A record is strongest when it includes an unavailable or contradictory case, not only the normal path.

A mode change stresses the same record differently. Suppose a cold-room monitoring system normally accepts periodic temperature records, and one source crosses the local review rule, so nearby nodes are asked to report more often until an action decision can be made. The technique here is a context-triggered mode change, not a role or route change, but the record still has to name an active set: which nodes joined the dense mode, which stayed excluded or unavailable, and when the system returns to the normal set. Excluded sources are not silently forgotten; they remain visible as missing or out of scope.

The rest of the record follows the same discipline. Some nodes provide source readings, some relay accepted evidence, and some serve only as observers for consistency checks — and the review does not assume a source node can safely become a relay without its own evidence. Accepted readings are still traced from source to next decision point with identity and freshness preserved. The denser mode is accepted only for the stated review need, so reusing it for a different response path means checking role, route, and data-quality evidence again. Retest if the trigger rule changes, if a participant becomes unavailable, if a relay role changes, if a route changes, or if the data-quality rule changes.

6.5 Practice Checks

This section: Practice Checks — Two short drills before the implementation view.

Two short drills before the implementation view. The first checks that each technique is tied to the evidence it should capture; the second checks the order a topology change is reviewed in.

6.6 Under the Hood: Keep Missing, Stale, and Rejected Data Visible

This section: Under the Hood: Keep Missing, Stale, and Rejected Data Visible — Under the hood, topology management is a state transition.

Under the hood, topology management is a state transition. The active set, role map, route map, data-value rule, and mode trigger all change the meaning of later observations. Keep unavailable, stale, suppressed, buffered, rejected, and contradictory data as explicit states rather than erasing them.

The data model needs more than a current neighbor table. Keep current and previous active-set states, role assignments, observed routes, timestamps, quality markers, excluded-source reasons, and the operation that authorized the transition. If the system stores only the new route, a later check cannot tell whether a missing reading was never expected, temporarily unavailable, suppressed by a rule, rejected for low quality, or hidden by a topology change.

Keep topology changes reversible or at least explainable afterward. Document what changed, which data was accepted, held, or rejected, which action applied to the current path, and what event requires the topology to be checked again.

Use a small state machine rather than overwriting the old state. A candidate route can be proposed, observed, accepted, held, rolled back, or marked unavailable. In the earlier G2 move, missing S19 keeps the candidate from acceptance; after rollback, check all 20 sensor identities again. A node can be proposed as a relay, tested by forwarding data, accepted for one decision path, and later revoked when the gateway, duty cycle, firmware, or responsibilities change. This is slower than a silent automatic switch, but preserves how data reached a decision and why it was trusted.