5  Topology Selection Records

Decision Gates, Candidate Shortlists, Record Matrices, Pilot Checks, Selection Limits, and Recheck Triggers

Keywords

topology selection, topology decision gates, topology shortlist, topology pilot checks, topology selection record

5.1 Start With the Story

Think of topology selection as a design review, not a shopping list. A team brings a scenario with devices, traffic, coverage, power limits, ownership boundaries, and recovery expectations. Your job is to narrow the possible shapes, reject the ones that fail a must-pass gate, pilot the remaining candidate, and leave behind a record that says when the choice must be revisited.

5.2 Overview: Start With Scenario Facts

Topology selection is the process of choosing a network shape from scenario facts. It starts with device roles, traffic direction, placement, power, ownership, and failure expectations. The topology name comes after those facts, not before them.

The practical goal is a bounded decision. A selection answer should say which pattern fits now, which candidates were rejected, what records support the choice, what remains unproven, and what future change should reopen the decision.

A good selection packet therefore looks more like a design review note than a diagram caption. It names the primary flow first: sensor-to-gateway telemetry, gateway-to-cloud reporting, controller-to-actuator commands, peer-to-peer alarms, or local fallback. It then separates must-pass facts from preferences. If a battery node cannot relay, mesh is not viable just because it appears resilient. If one gateway cannot cover the placement, a simple star is not proven just because it is easy to draw. If ownership changes at a gateway, broker, parent, or relay boundary, the topology record must say who observes and repairs that boundary.

This keeps the choice portable. A future reviewer can reuse the record only when the same facts, gates, limits, and recheck trigger still hold.

If you only need the intuition, this layer is enough: extract the scenario facts, apply must-pass gates, shortlist plausible patterns, test the riskiest assumption, and leave a selection record that can be rechecked.

A defensible topology decision moves from scenario facts through must-pass gates, shortlist, pilot evidence, and a durable recheck trigger.

Scenario Facts

Device roles, primary flow, placement, power state, gateway options, and operations ownership.

Decision Gates

Must-pass requirements that remove candidates before preference can take over.

Shortlist

A small set of star, tree, mesh, bus, ring, or hybrid options that still match the facts.

Recheck Trigger

The future change that makes the old decision unsafe to reuse without rechecking.

Overview Knowledge Check

5.3 Practitioner: Build the Selection Record

A topology selection record should be short enough to maintain and specific enough to defend. It should help a reviewer understand why one pattern fits the current evidence and why other plausible patterns were not selected.

Use gates to remove candidates that cannot satisfy the primary flow, coverage, energy, ownership, or recovery requirement.

Record field

Question

Record to keep

Failure it prevents

Primary flow

What message path matters most?

Source, destination, direction, cadence, freshness, and acceptable loss behavior.

Choosing a shape that optimizes the wrong traffic.

Candidate gate

What can remove a topology from the shortlist?

Coverage, power, latency, relay, gateway, boundary, and recovery constraints.

Keeping a favorite option after it contradicts a must-pass fact.

Shortlist reason

Why is each surviving pattern plausible?

The prompt fact or design record that supports star, tree, mesh, bus, ring, or hybrid behavior.

Comparing topology names with no scenario anchor.

Pilot check

Which assumption could invalidate the choice?

Path trace, dependency removal, gateway handoff, load shape, or operations check.

Turning an untested recommendation into a fixed design.

Decision limit

What does the current record not prove?

Unverified coverage, relay burden, gateway capacity, command latency, repair path, or ownership handoff.

Overstating the topology as universally correct.

Recheck trigger

What future change reopens the decision?

New placement, traffic class, device count, power model, gateway owner, or service dependency.

Letting an old selection survive changed conditions.

Worked Selection Record

A greenhouse monitoring scenario has battery sensors in two rooms, one mains-powered gateway per room, and cloud reporting every few minutes. A bounded selection can choose a hybrid pattern: room-level star collection to each gateway, then gateway-to-cloud reporting upstream.

The record should reject full mesh unless the sensors have relay budget and a reason to relay. It should reject one large star unless the evidence shows one gateway can cover both rooms. The pilot should disable or isolate one gateway and record buffering, alert ownership, and recovery behavior.

Practitioner Knowledge Check

5.4 Under the Hood: Boundaries, Pilots, and Recheck Logic

Topology selection fails when the answer treats a topology family as a guarantee. Star, tree, mesh, bus, ring, and hybrid patterns describe connection structure. They do not prove coverage, latency, route repair, gateway capacity, local control, or operational ownership by themselves.

The under-the-hood check separates the candidate's promise from the record that would make the promise credible. The pilot check should test the assumption most likely to invalidate the selected pattern, not the easiest path that already works.

For example, a mesh candidate often promises alternate paths, but the record still has to show whether the alternate path reaches the real destination, whether relay nodes have enough power budget, whether route repair converges before the application deadline, and whether all paths still collapse through the same gateway. A tree candidate can match floors, rooms, or zones, but it must expose the parent role as a failure domain. A hybrid candidate can be the right answer when local collection and upstream reporting have different constraints, yet the handoff boundary must be visible instead of hidden inside the word "hybrid."

The recheck rule is the maintenance hook. It should reopen selection when a new room, gateway owner, traffic class, firmware duty cycle, device count, or service dependency changes the assumptions that made the old record valid.

A selection record keeps support, rejection reasons, unresolved assumptions, pilot result, and recheck logic together.

Star Boundary

Prove center capacity, coverage, handoff ownership, and behavior when the center fails or buffers traffic.

Tree Boundary

Prove parent roles, branch failure domains, route repair behavior, and whether tier ownership is explicit.

Mesh Boundary

Prove relay budget, path diversity, route stability, duty-cycle impact, and gateway dependency.

Hybrid Boundary

Prove which segment uses which behavior, where handoffs occur, and what record crosses the boundary.

Pilot And Recheck Rules

• Trace the primary flow through the selected pattern before testing secondary flows.
• Remove one shared dependency and record who is affected.
• Match the pilot traffic shape to the real flow: periodic, bursty, command, diagnostic, or local control.
• Record the owner of each gateway, parent, broker, relay, or shared service.
• Reopen the choice when placement, device count, traffic direction, power budget, or ownership changes.

The pilot tests the risky assumption that could overturn the topology choice, then records the owner boundary and recheck trigger.

Under-the-Hood Knowledge Check

5.5 Summary

• Topology selection starts with scenario facts, not a preferred shape.
• Decision gates remove candidates that cannot satisfy the primary flow, coverage, energy, ownership, or recovery requirement.
• A shortlist should preserve only candidates with support from the scenario or design record.
• Pilot checks test the riskiest assumption before the recommendation becomes fixed.
• Selection records should name the chosen pattern, rejected candidates, unresolved assumptions, limits, and recheck trigger.
• A topology name does not prove resilience, latency, route repair, or operational fit without records.

5.6 Key Takeaway

Choose topologies as bounded records: facts first, gates second, shortlist third, pilot result before commitment, and a clear trigger for reopening the decision.

5.7 See Also

Network Topologies: Basic Types

Compare the topology families before using them in a selection record.

Topology Analysis and Metrics

Use graph metrics and failure domains to strengthen the selection record.

Topology Failures

Check the failure modes that can invalidate a candidate topology.

Topology Management Techniques

Connect the selected shape to operations, route changes, rollback, and retest triggers.