Physics Is Informatics’ Bitch: Threat Models That Start With Data Flow
Physics is informatics’ projection. The measurable world — mass, charge, temperature, the weight of a server rack — is the output of a deeper information layer. Matter is the shadow; data is the light. This is not poetry. It is the north star’s first principle rendered operational: information is the ground of being, and everything else is what information does when it hits a medium.
The same inversion applies to security. The attack surface is not the open port. It is not the unpatched CVE, the misconfigured nginx block, or the expired TLS certificate. Those are symptoms — projections of a deeper structure. The attack surface is the data flow behind the port. Threat models that start with packets are modeling shadows. Threat models that start with data flow are modeling the source.
The Flow Audit: Ingest, Transform, Store, Emit
A data-flow threat model asks one question relentlessly: where does information go, and who can touch it along the way? Not “what services are exposed” but “what records traverse what paths, and at which points could they be read, copied, altered, or destroyed.” The port is a symptom. The flow is the disease.
This changes the security audit loop fundamentally. Instead of scanning for known weaknesses in known components — the traditional vulnerability-assessment posture — the loop walks each flow through four phases: ingest, transform, store, emit. At each step the question is identical: is the information intact, confined, and accounted for? The scanner finds the crack in the wall. The flow audit finds the path the water actually takes.
Consider an agent fleet that processes customer requests. The traditional model asks: is the API authenticated? Is the container isolated? Is the database encrypted at rest? The flow model asks something different: when a customer’s data enters the system, does it transit through any path that is not cryptographically bounded? When the agent transforms that data — enriches it, summarizes it, routes it — does the intermediate representation carry more privilege than the original? When the result is stored, is the storage path aware of the data’s provenance and the customer’s consent boundaries?
These are not the same questions. The first set defends infrastructure. The second set defends information. The north star is unambiguous about which one matters: information is the ground of being. If the information is compromised, the infrastructure is irrelevant. If the information is intact, the infrastructure can be rebuilt.
The Sovereign Stack Was Always a Data-Flow Decision
The sovereign stack was built on this premise without always saying it. Local-first is a data-flow decision: it says the information stays within a boundary the operator controls. Cloud-optional is a data-flow decision: it says the information may transit to external infrastructure, but only under explicit, auditable conditions. The narrow gate is a data-flow decision: it says every crossing point is a flow boundary where information must be validated, not just packets.
Naming these as data-flow decisions makes the architecture auditable. Every design choice becomes a statement about information movement. “Why is this service local-first?” Because the data flow it handles must stay within the operator’s trust boundary. “Why does this API go through the narrow gate?” Because the data flow it carries crosses from untrusted to trusted space. “Why is this agent’s output signed?” Because the data flow it produces must be traceable back to its origin.
This is the practical meaning of principle five from the north star: informatics outranks physics. The measurable world — the server, the network, the CPU cycle — is the output, not the source. Threat models, product narratives, and content all start from data flow, not from surfaces.
The Attacker Already Thinks This Way
Here is the uncomfortable truth: sophisticated attackers already model data flow. They do not start by scanning ports. They start by mapping the information architecture — which services hold what data, how data moves between them, where the trust boundaries are, and what happens at each boundary crossing. They follow the data because the data is the asset. The infrastructure is just the terrain.
The defender who models only infrastructure is fighting on the attacker’s terms. The terrain is complex, shifting, and full of false signals. A port scan returns hundreds of results. A CVE database returns thousands. Prioritizing among them without a data-flow model is guesswork — informed guesswork, perhaps, but guesswork nonetheless.
The flow audit replaces guesswork with geometry. Each flow has a start, a path, and an end. Each touchpoint along the path is a boundary. Each boundary is a control point. The threat model becomes a map, not a list — and on a map, you can see where the walls are thin.
From Audit Loop to Continuous Assurance
The S7.10 security audit loop — the incident-response and continuous-monitoring layer — gains a new spine when it starts from data flow. Instead of asking “what might go wrong?” it asks “what is happening to the information right now?” Each flow is instrumented. Each boundary crossing is logged. The audit trail is not an afterthought appended to incident response; it is the primary artifact that incident response consumes.
This is data permanence as a security property. A system that cannot prove what happened to its information cannot be trusted with that information. The audit log is the record of flows — who touched what, when, under what authority. When the audit log is the source of truth and the database is a projection, the security posture inverts: the record is protected first, and the infrastructure is disposable scaffolding around it.
The builder who adopts this posture stops asking “is the server secure?” and starts asking “is the information accounted for?” The first question has a boolean answer. The second has a continuous one — and continuous answers compound into assurance.
Build From the Data Up
Inventory every flow. Mark every touchpoint. Audit the journey, not the destination. The attacker is already following the data — the defense should be standing on the same path. When the defender’s model and the attacker’s model occupy the same geometry, the defender has the advantage of design: they built the flow, they know its shape, and they can reinforce it at every boundary.
Physics is informatics’ bitch because physics does what information tells it to. The port opens because the data flow demands it. The container spins up because the information needs processing. The record persists because the flow must be accounted for. Start from the flow, and the physics follows. Start from the physics, and the flow is invisible until it is too late.
Grounded in the SECTOR9 north star principles — Information is the ground of being, Informatics outranks physics — and extending the S7.x security & sovereignty series theme: S7.10 security audit loop. The data-flow threat model transforms the audit loop from a vulnerability scanner into a continuous-information-accountability engine. Sector7-grounded series article, SECTOR9 50+50.
