Draw the Hidden Handoffs

A home internet connection presents itself as one thing. There is a monthly payment, a box with lights, and an expectation that a page will open. When it fails, the phrase “the internet is down” feels like a complete description.

It is usually the beginning of the description. The device, the local wireless link, the router, the building connection, the provider’s network, and the destination service do different jobs. They may also belong to different people. A fault at one boundary can look remarkably similar to a fault at another from the kitchen table.

Infrastructure literacy begins by separating those jobs. You do not need to operate every layer. You need enough of a map to ask a useful question and find the right person when the usual result does not arrive.

Follow one ordinary journey

Pick a service you use frequently and describe one successful journey through it. A delivered parcel travels through an address record, a seller, a carrier, a building entrance, and a final handover. Drinking water reaches a tap through systems whose ownership and maintenance boundaries differ from one property to another. A payment instruction crosses several organisations before the recipient sees the result.

Keep the first drawing small. Use named boxes for the stages you actually know and question marks for the rest. Distinguish observation from inference. A router label may identify its manufacturer without telling you who must replace it under your service arrangement.

The question marks are useful. They indicate where one document, conversation, or observation could replace a vague assumption. A diagram full of uncertain labels is more honest than a polished diagram borrowed from a different kind of building.

For a web service you host, the journey is concrete enough to measure:

dig +short A git.example.org
dig +short AAAA git.example.org
curl -sI https://git.example.org/ | sed -n '1,15p'
traceroute -n git.example.org | tail

That tells you: which address the name currently has, whether IPv6 is a second path or a trap, which TLS certificate answered, and where packets start disappearing. It does not tell you who bills the fibre.

Put people at the boundaries

Technical components rarely explain the whole recovery path. Add the person or organisation responsible for each accessible stage, along with the source of that information. A tenancy document, building notice, service agreement, or current support page may establish a boundary that cannot be inferred from the equipment itself.

Consider a shared entrance intercom. The indoor handset may be inside a private dwelling, while the entrance panel and connecting system are maintained collectively. Knowing that distinction changes whom you contact and what information they need. It may also prevent you from treating a shared problem as an individual purchase decision.

Responsibility can be divided further. One party pays, another approves work, and a third performs it. Marking those handoffs makes delays less mysterious. It also helps identify who needs to hear about a problem early, before the eventual repair can be scheduled.

Identify evidence you can gather

A useful map includes safe observations that narrow uncertainty. With connectivity, you might note whether more than one device is affected, whether an already configured wired connection behaves differently, and whether one destination fails while others load. The point is to describe the boundary of the symptom without changing the system blindly.

ip -br addr
ping -c 3 192.168.1.1
ping -c 3 1.1.1.1
getent hosts git.example.org

If the LAN ping works and 1.1.1.1 does not, do not reinstall the browser. If 1.1.1.1 works and the name fails, you have a DNS handoff, not “the internet.”

For a building service, observations may be simpler: which locations are affected, when the change began, and whether a scheduled notice explains it. Do not open service cabinets or interfere with shared equipment to complete a diagram. An inaccessible boundary can remain a named boundary.

Good evidence saves attention on both sides of a support conversation. “Three devices stopped connecting at approximately the same time; the provider’s box shows this message” gives someone a starting point. It remains useful even when your initial guess about the cause is wrong.

Look for common foundations

Two services can look separate while depending on the same foundation. Home internet and a voice service may use the same powered router. Two delivery arrangements may rely on the same locked entrance. Two administrative accounts may send their recovery messages to the same email address.

Draw these shared dependencies only where they affect an actual decision. You are looking for places where apparent alternatives would disappear together. A second communication route has limited value if no one can use it when the one shared device is unavailable.

This does not make shared infrastructure undesirable. Shared systems can be efficient and well maintained. It simply means that the shape of your alternatives should reflect the shape of the dependency. Sometimes the best improvement is a paper contact detail or an agreed meeting point, not another subscription.

Leave a map someone can inherit

Date the drawing and keep it near the records for the service. Include useful identifiers while excluding passwords and other secret access material. Name what would make the map stale: a provider change, a move, replacement equipment, or a new building manager.

Ask another person to use it to answer an ordinary question. Who receives a fault report? Which reference number identifies the service? What evidence can be collected safely? If the drawing cannot answer those questions, simplify it around them.

An infrastructure map is not a miniature engineering department. It is a bridge between everyday experience and the systems that make that experience possible. The hidden handoffs become visible enough that you can participate intelligently when something needs attention.