Your recovered data-flow diagram has an edge telemetry proves but no configuration explains — what now?

## The scenario A telecom's number-porting service has never been modeled. You reconstruct a draft from the infrastructure config, the route table and the grants, and then check it against request telemetry. The telemetry shows a steady, low-volume exchange with a partner carrier's network on a port that appears in no configuration file you have found. Nothing you have read explains it. This is one of the most instructive moments in recovering an undocumented system, because it forces the question of which evidence wins. ## Behaviour wins over paperwork A data-flow diagram is a model of what the system **does**. Configuration describes what someone once told the system to do; telemetry describes what actually happened. When they disagree, the observation is the fact and the configuration set is the thing proven incomplete. The failure mode to avoid is deleting the edge because it is not in the config — that is optimising the diagram for tidiness at the exact point where it is telling you something you did not know. ## Characterise before you ask You will get far better answers from humans if you arrive with specifics. From the telemetry alone you can usually extract: - **Which identity or host originates it** — a service account, an instance, a NAT address, a client certificate subject. - **The destination and protocol** — host, port, whether the transport is authenticated and encrypted. - **Direction of the payload** — is the system pushing subscriber data out, or pulling records in? This is what decides which threats matter. - **Volume and shape** — a few hundred bytes on a heartbeat cadence is a very different edge from a nightly bulk transfer. - **Schedule** — continuous, business-hours, or aligned to a batch window. With that, the hypothesis space usually collapses to a short list: a resource created by hand and never adopted into the declarative config; a destination that arrives at runtime from a database row or environment variable, so no grep would find it; a legacy static route in a network device configuration you have not been given; a shared credential used by a system outside your inventory; or a partner integration set up by an agreement rather than a commit. ## Then walk it with the operator The people who carry the pager for a system know the flows that leave no artifact. Walk the draft edge by edge and ask specifically: what is this, who owns the far end, what happens if it stops. Three cautions about what you accept as an answer: 1. **"That's just the old porting sync, ignore it" is not a closure.** It is a lead. Record it as an operator statement, with the name and the date, and keep pushing until you have the far-end owner, the authentication, and the data class. 2. **A verbal explanation is still an assumption** until an artifact — a credential, a firewall rule, a contract, a job definition — corroborates it. Mark it as such on the diagram. 3. **Unowned is a finding.** If the edge is confirmed to exist but nobody will claim the far end, you have an inter-organisational flow with no owner, no change control and no one to call. That is a modeling result worth reporting on its own, before any threat enumeration. ## Why it matters for the threats you will enumerate An edge that leaves the organisation almost always crosses a trust boundary that the existing mental model did not contain. In the porting case, the far end is a partner carrier: an adversary who compromises that carrier now sits on a flow into a system that moves subscriber identity and controls whether a number keeps working. Both the confidentiality of subscriber identity and the availability of the service are exposed through an edge that, an hour earlier, nobody had drawn. Delete the edge and you delete every threat that follows from it. ## When it stops being a modeling problem There is a real branch here. If no configuration, no code, no credential inventory and no human can account for a flow leaving your estate, the possibilities include an active compromise or an exfiltration path, and that is no longer something to resolve at your own pace. Escalate it to the people who run incident response and let them decide. Your job is to hand over a precise description — source identity, destination, protocol, volume, first-seen and last-seen — and to keep the edge in the model regardless of what the investigation concludes, because the model must reflect the system as it is. ## What ends up on the diagram The edge is drawn, with its protocol, direction and data class as far as you know them, and annotated with its evidence: telemetry only; owner unknown; observed from this date; operator statement pending corroboration. A recovered diagram that shows its own confidence per edge is far more useful than one that projects false certainty, because the next reader can see exactly which parts are safe to reason from.