The Map¶

The map answers three different questions, and it has a view for each.

View	The question	What you get
Network	Where is everything, and where is the crypto risk?	Every device laid out by site and network, each marked by the crypto it serves. Click any device to see its services and their crypto.
Neighbourhood	What is this one thing attached to?	A graph around one asset, out to three hops, with the impact overlay.
Topology	Where is everything?	A tree of your whole estate by site, prefix and class, with counts and the connections between prefixes.

The switch between them sits at the top of the page, and the view you are in is in the address bar — so either one is a link you can paste into a ticket.

The map opens on the network view. A link that names an asset (from an asset's Relationships tab, or one somebody pasted) still opens the neighbourhood around it. Topology is at the bottom.

The network view¶

The network view draws your whole estate at once: each site, the networks at that site, and the devices on each network. Every device carries a small badge showing how many of its services carry crypto, coloured by what the platform found there.

Four layouts¶

Choose with View. They all draw the same devices; pick whichever reads best for the shape of your estate.

Layout	Best for
Funnel	A small or medium estate. Networks funnel up to their site, and sites up to the internet.
Circuit	Wide networks. Each site is a trunk line and each network a bus with devices hanging off it, so a big network grows sideways rather than into a tall block.
Radial	A large estate at a glance. Sites on the inner ring, networks in the middle, one wedge per device on the outside. Tall coloured wedges carry crypto; short grey ones do not.
By crypto	Deciding what to fix. Devices are grouped by an algorithm or certificate problem they share, worst first, so each row is one change that fixes every device in it. Strong algorithms nobody needs to act on are hidden until you ask for them.

Zoom¶

Sites shows one summary card per site: devices, networks, how many carry crypto, and the risk breakdown. Networks shows each network's device types and risk breakdown without drawing every device. Devices draws every device. A small estate opens at Devices; a large one at Sites.

Click a site — its name, its card, or its ring in the radial layout — to focus on it. All sites takes you back.

Colour¶

Colour by switches between:

Crypto risk — the device's risk rating on the platform's standard scale. A device nothing has assessed yet is drawn hollow and labelled Not assessed: that is not the same as low risk.
Quantum readiness — whether the device's crypto needs migrating before quantum computers can break it, using the same classification as the PQC dashboard. One configuration that relies on classical public-key crypto is enough to mark the device as needing migration.

A hollow grey badge means the device has open services but no crypto has been observed on them yet. A device with no badge has no services observed at all.

Only devices with crypto hides everything with nothing to show — usually phones, TVs and laptops seen on the network but never measured.

A device, exploded¶

Click any device in any layout. Below the map, the device appears on the left with a line out to each of its services. Each service lists the crypto measured on it — protocol, key exchange, cipher, signature, key size, and its certificate with the expiry date — coloured by the platform's algorithm assessment. Algorithms the server offers but did not use are shown only when they are weak, marked also offers, because a reachable weak option is still a weakness. Services with no crypto observed are grouped into one card.

From there, Open asset goes to the asset's page and Show neighbourhood draws the graph around it.

What the network view does not guess¶

Networks come from your data. A device is drawn in the network it is assigned to, even if its address suggests another. If a device looks misplaced, the assignment is what needs fixing.
Gateways are not inferred. A network names its gateway — the device's name and its address on that network, linking to its asset page — only once that device has reported it, which happens when you interrogate the router (see What interrogating a gateway records). Until then the network says gateway not recorded, rather than assuming the first address is the router.
Very large estates are capped. When that happens a banner says how many devices are shown out of how many, highest risk first.

The site you focus on and the device you open are in the address bar, so a view is a link you can paste into a ticket. Your layout, zoom and colour choices are remembered in your browser.

The neighbourhood view¶

The neighbourhood draws one asset and everything around it: what it runs on, what depends on it, what it talks to, and how far away each of those is. It is the same information the Relationships tab lists, drawn as a picture instead of as two lists.

A list is better for deciding about one relationship. A picture is better for seeing a shape — that three applications all rest on the same host, that a controller sits between you and forty access points, that the database you were about to reboot has four things hanging off it.

Where to find it¶

Inventory → Map.

Choose Neighbourhood at the top of the map. The list of assets runs down the left-hand side and the map opens on the first one, so there is always a map to look at; pick any other asset from the list to redraw it. The search box above the list speaks the same query language as the inventory list, so class:server and environment:production works here exactly as it does there.

An asset with no relationships is still drawn, on its own, with a note saying nothing has been observed or declared about what it is attached to.

Two other ways in:

From an asset. Inventory → open any asset → Relationships tab → View on map. This is the usual route: you are already looking at an asset and want to see its surroundings.
Full screen. The Full screen button gives the graph the whole window with no navigation rail. Exit returns you to the lens with your depth and pending settings intact.

The address bar always describes what you are looking at, so a map is a link you can paste into a ticket.

Reading the map¶

The nodes¶

Each box is an asset. Two things are shown at once and they are deliberately separate:


Colour and icon	What kind of thing it is — hardware, virtual, cloud resource, application, service, external party, or an unidentified host. These are the top-level asset classes.
The ring	Its lifecycle status: monitored (green), waiting for approval (amber), or archived and out of service (grey).

Keeping them separate matters: an asset waiting for approval is still a server, and should still look like one.

The asset the map is drawn around is outlined in its own colour and labelled Focus.

A node whose class this version of the platform does not recognise is drawn as Other, in grey. That is not the same as Unknown host — an unknown host is a real address in your estate that nothing has identified, which is a gap worth closing. "Other" just means a class name we have no icon for, usually one of your own subclasses.

The edges¶

Each line is a relationship, labelled with what it means — runs on, depends on, contains, manages. The arrow points the way the relationship reads.

Solid lines are confirmed relationships.
Dashed amber lines are pending — proposed by a collector or by a person, and not yet accepted. They are only drawn when you switch Pending on.
Rejected relationships are never drawn, in any mode. Someone decided that relationship was wrong; the map does not put that decision back up for grabs.

Hover a line to see where it came from: measured, declared, imported or inferred; how confident the platform is; how many times it has been observed; and when it was first and last seen. An inferred relationship is the platform's own guess and has not been confirmed by anything.

Two assets can be joined by more than one relationship — an application both runs on and connects to its host is ordinary — and each is drawn as its own line, curved apart from the others between that pair, so every one of them can be hovered for its own provenance.

Depth¶

The Depth slider controls how many hops out from the focus asset the map reaches, from 1 to 3. Two is the default and is usually the readable one — at three hops a well-connected asset in a busy estate can pull in most of a data centre.

Depth is the shortest path, so an asset reachable two different ways is drawn once, at the distance you would say it is.

Layout¶

The LR / TB button switches between left-to-right and top-to-bottom. Which one reads better depends on the shape of the neighbourhood; nothing else changes.

The layout is deterministic: the same neighbourhood is drawn the same way every time, so a screenshot in a ticket matches what the person reading it sees.

The impact overlay¶

Show impact of focus answers the question people open this page for: if I take this down, what goes with it?

Switch it on and the map highlights everything that depends on the focus asset, tinted by distance — the first hop strongest, fading outwards. Everything outside the blast radius is dimmed rather than hidden, because "nothing else is affected" is only readable if the something-else is still on screen.

Downstream / Upstream flips the question: what depends on this, or what this itself rests on.

Three things about this answer are worth knowing, and they are the same three that apply to the impact panel on the Relationships tab:

Observed network connections do not count. Two machines exchanging packets tells you nothing about whether one stops working when the other does. Nine of the ten relationship types carry impact; connects_to is the one that does not.
Only confirmed relationships count. A pending proposal is a guess, and you should not plan a maintenance window around a guess. Turning Pending on draws those lines but does not add them to the blast radius.
A very large answer is reported as a floor. If the closure is capped you will see "At least 500 assets…" rather than a total, because a number somebody schedules an outage around must not quietly be the smaller of two possibilities.

When the map is truncated¶

A neighbourhood can be bigger than a picture is useful at. The map draws at most 500 assets and 2,000 relationships; past that, a banner appears saying exactly how much was left out — "Showing 500 of 812 assets and 2000 of 3104 relationships."

The graph you are looking at is then a piece of the neighbourhood, not a small one. Reduce the depth, or click through to a node nearer whatever you were actually looking for and use Focus here to redraw around it.

Clicking a node¶

Clicking an asset opens a panel with its class, status, risk score and every relationship it has on the current map, plus two actions:

Open asset — its full page.
Focus here — redraw the neighbourhood around it. This is how you walk an estate: focus, look, step, look again.

A risk score of 0 on this panel means not assessed, not safe.

Exporting¶

Export writes the graph currently on screen to a file:


GraphML	The interchange format Visio, yEd and Gephi read.
Cytoscape JSON	Loads directly into Cytoscape.js.

Both carry the node and edge attributes the map shows — class, status, depth, relationship type, provenance, confidence and the first- and last-seen dates — so the picture is still readable after it leaves here.

The menu closes on Esc, on a click outside it, or once you choose a format.

These exports are convenience, not evidence. They are written in your browser from the graph you are looking at, which means they carry no provenance, no content hash and no record of what selected them — and when the map is truncated, the file is truncated with it. For audit-grade output with a hash and a stated scope, generate a CBOM artifact instead. The same distinction applies to the inventory's page-local exports.

"No relationships yet"¶

Most assets in most inventories are leaves — nothing runs on them and nothing depends on them — so an empty map is an ordinary answer rather than a sign something is broken. It does mean impact analysis has nothing to go on for that asset.

Relationships arrive four ways, and the empty state links to the first of them:


Measured	Sensors, cloud APIs and device interrogation observe them. See Discovery.
Imported	A spreadsheet import (or, in Enterprise, a CMDB pull) brings them with the assets. See Spreadsheet Import.
Inferred	The platform proposes one from what it has seen. These always wait for a person in Discovery → Approvals.
Declared	Someone records one by hand, on the asset's Relationships tab.

What you need to see it¶

The map reads the same data as the inventory, so anyone who can view assets can open it. Declaring a new relationship needs the assets.update permission, and is done from the asset's Relationships tab rather than from the map — see Roles & Permissions.

The topology view¶

Inventory → Map → Topology, or straight to /inventory?lens=map&view=topology. The Assets Monitored panel on the Dashboard links here too.

Topology answers where is everything. It is deliberately not a graph of every asset: a picture of several thousand nodes is unreadable everywhere it has been tried, and tells you less than the inventory list already does. It is a tree instead.

What it shows¶

Four numbers across the top: how many configuration items you have, how many sites they are spread across, how many have no site recorded, and how many confirmed relationships cross a prefix boundary.

The third of those is the one to read first. It tells you whether the tree below is your estate or a tidy corner of it.

Under them, the tree:

Site — each site you have recorded, and an explicit Unassigned node for everything that has none. Sites are read from the asset's own site field, falling back to a location.site or site tag, so an estate labelled by a CMDB import groups correctly.
Prefix — each prefix within the site, and an explicit No prefix node for assets that belong to none. The in no prefix node is drawn in a lighter style, because it is an absence rather than something somebody drew.
Class — expand a prefix and you get one chip per asset class present in it, coloured the same way the neighbourhood colours its nodes, with a count.

Nothing is left out. On a fresh inventory most assets have neither a site nor a prefix, and a topology that quietly omitted them would draw the curated minority and look complete. If the tree does not add up to the total at the top, the page says so rather than letting you assume it does.

Clicking through¶

Every count is a link into the inventory list, filtered to exactly the rows it counted:

Click	What opens
A prefix's count	Every configuration item in that prefix
A class chip	Every item of that class in that prefix

The filter arrives as a query in the address bar, so you can widen or narrow it from there. The No prefix bucket becomes not exists(prefix_id) — "no prefix recorded", which is a different question from any particular prefix.

Between prefixes¶

Beside the tree, the connections that cross a prefix boundary, aggregated per pair of prefixes and per kind — observed connections and declared dependencies are counted separately, because they are different claims.

Two things are deliberately not counted here:

Pending relationships. An aggregate is the one place a single unconfirmed observation is invisible, so drawing it would state a guess as fact with nothing on screen to qualify it. Accept it in Discovery → Approvals and it appears.
Containment. A virtual machine and its hypervisor sitting in two prefixes is one thing described twice, not a connection between those prefixes.

An empty list here means nothing has observed or declared a link between your prefixes — not that they are isolated.

When it is truncated¶

Very large estates are capped. Past the cap a banner says how much is shown against how much there is — the real totals, never a quiet shortening. The cross-prefix links headline is one of those totals: it counts every link your estate has, and says how many of them were drawn when the list beside it is short of that.

What it does not have¶

No full-screen mode and no export. The tree is a way into the list rather than a document; for something with a hash and a stated scope, generate a CBOM artifact.