01SERVICES
Every operational unit that exists in the system — regardless of whether it is formally registered.
VARUX LAB / INFRASTRUCTURE INTELLIGENCE
RESEARCH DIRECTION
Know where a change can reach,
before it propagates.
ATLAS is a future infrastructure mapping layer for visualizing services, data flows, operational dependencies, risk surfaces and policy boundaries across critical systems.
A research direction for making the structure of critical systems explicit — not an inventory, not a dashboard. A map: relationships, boundaries and the paths a change can travel.
SHEET 01 DOMAIN
What ATLAS maps.
A mapping layer is defined by the dimensions it records. ATLAS conceptualizes five of them for critical systems — none of which is a single metric.
02DATA FLOWS
What moves between services: requests, writes, events, exports. A flow is a dependency with direction.
03DEPENDENCIES
Which component can fail, delay or change another. The graph is the unit of analysis, not the list.
04RISK SURFACES
Regions of the system where a change has outsized blast radius or where state is hard to recover.
05POLICY BOUNDARIES
The explicit limits where authority, trust or write permission changes — whether they are enforced or only implied.
SHEET 02 WHY THIS EXISTS
Infrastructure is usually documented as an inventory — but it is operated as a structure.
Systems grow through deployments, migrations and emergency changes. What was once a known architecture becomes a list of services with implicit relationships: undocumented edges, unowned dependencies, boundaries that exist in policy documents but not in the running system.
When something fails or changes, the structure has to be reconstructed under pressure — from dashboards, logs and memory. ATLAS conceptualizes the opposite: structure made explicit before a change, so blast radius and boundary crossings are visible in advance.
ATLAS is a research direction for a mapping layer. It does not propose a scanner, an agent or an auto-remediation engine — it proposes a representation of structure that other control layers can reason over.
SHEET 03 REFERENCE ARCHITECTURE
Conceptual architecture — not an implemented stack.
Four conceptual layers, ordered from observation to analysis. This is a reference model for discussion, not a deployed pipeline.
LAYER 01
OBSERVE
DISCOVERY
Collect service metadata, configuration and connection records from existing sources. The map is only as honest as its inputs.
LAYER 02
MODEL
DEPENDENCY MODEL
Build and maintain a graph: nodes, directed edges, lineage, critical paths. This layer owns structure, not opinions about it.
LAYER 03
BOUND
OVERLAY
Superimpose policy boundaries, trust boundaries and risk surfaces on the graph. Boundaries are first-class objects, not styling.
LAYER 04
REASON
ANALYSIS
Change impact, blast radius, dependency lineage and critical path reasoning over the modeled structure — presented for human review.
SHEET 04 CONTROL MODEL
Boundaries ATLAS keeps visible.
ATLAS does not block anything by itself. It surfaces the boundaries a control layer would need — a boundary that is mapped can be governed; a boundary that is invisible cannot.
TRUST BOUNDARY
Who may pass.
Regions where identity, authority or network position changes. The map records where trust actually transitions, not where the diagram says it should.
SURFACES: implicit trust zones
POLICY BOUNDARY
Where rules change.
Edges of the graph where write permission, approval requirements or evidence obligations differ. Policy boundaries should align with dependency boundaries — the map exposes when they do not.
SURFACES: policy / topology drift
BLAST RADIUS
How far damage reaches.
The set of nodes reachable from a given change, weighted by data flow and shared state. Blast radius turns an intuition into a bounded set.
SURFACES: change exposure
CRITICAL PATH
What must not break.
The minimal set of dependencies without which the system's core function degrades. Critical path is the opposite of "everything is critical".
SURFACES: resilience priorities
SHEET 05 DEGRADATION MODEL
A map has value only if it can state what it does not know.
A mapping layer degrades in specific, describable ways: discovery stops finding new components, topology goes stale between syncs, edges remain untyped, and some dependencies are only reachable, never declared.
ATLAS conceptualizes these as explicit map states rather than silent failures. An unmapped dependency is itself a finding — not an empty cell.
PROPOSED STATES: PARTIAL · STALE · UNTYPED · UNKNOWN-EDGE — each rendered as a distinct uncertainty, never merged into "normal".
D1PARTIAL DISCOVERY
Components exist in runtime traffic but not in the inventory. Coverage is reported, never assumed.
D2STALE TOPOLOGY
The graph reflects a past state. Age is shown on every edge, and old structure is never mistaken for current structure.
D3UNTYPED EDGES
Direction may be known while semantics are not — a call exists, but is it a dependency, a fallback or a side channel? Unknown remains unknown.
D4UNKNOWN NODES
Reachable but undeclared services, like an undocumented legacy consumer, are drawn as stubs — visible, flagged, unresolved.
SHEET 07 RESEARCH DIRECTIONS
Open surfaces for future work.
Directions ATLAS could explore next — each stated as a question, not a roadmap.
ATLAS-R-01
State-aware topology
How should the map represent runtime state — healthy, degraded, draining — without becoming an observability platform?
ATLAS-R-02
Change impact analysis
Given a proposed change, which nodes are reachable and which boundaries are crossed — as a review artifact, not a prediction engine.
ATLAS-R-03
Dependency lineage
How a dependency came to exist: introduced by which change, owned by whom, and whether it is still load-bearing.
ATLAS-R-04
Critical path reasoning
Minimal dependency sets whose failure degrades core function — and how that set shifts as the system evolves.
ATLAS-R-05
Policy boundary overlay
Aligning declared policy boundaries with the modeled dependency structure, surfacing where the two diverge.
ATLAS-R-06
Blast-radius visualization
Rendering reachable sets and boundary crossings in a way a human can review before approving a change.
SHEET 08 SCOPE
What this concept is — and is not.
ATLAS IS
- ▸ an infrastructure intelligence research direction
- ▸ a dependency mapping concept
- ▸ a risk surface and policy boundary visualization concept
- ▸ a change impact reasoning surface
- ▸ a reference model for future control layers
- ▸ an illustration of VARUX's structure-first philosophy
ATLAS IS NOT
- ✕ a CMDB replacement
- ✕ a SIEM
- ✕ an observability platform
- ✕ an automated remediation engine
- ✕ a configuration scanner
- ✕ a released product, deployment or benchmark
SHEET 09 INTERACTIVE DEMONSTRATION
Topology map — concept simulation.
A static, illustrative topology. Select a node to inspect its dependencies, toggle boundary overlays, and simulate a change to watch propagation. No live infrastructure data is involved.
ATLAS MAP — INFRASTRUCTURE INTELLIGENCE
LOCAL SIMULATION · NO LIVE DATA
STATUS — RESEARCH DIRECTION
ATLAS is a research direction. It is a concept for a future infrastructure mapping layer — not a released product, not a deployed system, not a benchmarked implementation. This page documents the concept and its proposed shape.
The Future Needs Boundaries.
Critical systems require deterministic boundaries before intelligence scales. ATLAS is a research surface for making the structure of those systems explicit — so that a change can be understood before it propagates.