Capability Guide

0 How to read this guide

CrossConnect is a single, trusted record of your network plus the intelligence that reads it. It keeps an authoritative inventory of everything you run, every device, port, address, circuit, and the services they deliver, then works over that record to tell you what is at risk, what changed, and what to do next. It is built for mixed estates, including professional audio-visual (AV) networks, where keeping traffic separated and clocks in sync matters as much as uptime.

This guide follows the product's own menus. Each numbered section is one navigation area. It opens with a short summary and a diagram of how the area fits together, then describes the headline capabilities and lists the rest in a compact table. Every capability shows where to find it in the product as a route. Instead of describing a feature with an adjective, each section names how it actually works: the signal, the protocol, the engine, the exact behavior. Capabilities that are an add-on you turn on at install, or an early preview rather than a shipped default, are labelled as such.

Three ideas used throughout

flowchart TB
  subgraph SRC["SIGNALS · read-only, no packet capture"]
    direction LR
    S1["SNMP / LLDP
inventory · topology · sensors"]
    S2["SSH show-config
running configuration"]
    S3["NetFlow / sFlow
flow summaries"]
    S4["mDNS / SSDP
AV announcements"]
    S5["Vendor / cloud APIs
Meraki · Mist · DDM"]
  end
  SOT[("SOURCE OF TRUTH
devices · interfaces · IP · VLANs
cables · circuits · services")]
  ENG{{"REASONING ENGINES
Batfish formal model · classifiers
scoring · triangulation · grounded AI"}}
  SRC -- "validation gate · confidence-scored" --> SOT
  SOT --> ENG
  ENG --> A1["Situational awareness
hotspots · health · maps"]
  ENG --> A2["AV & media
classify · segment · timing"]
  ENG --> A3["Assurance
reachability · CVEs · fix plan"]
  ENG --> A4["Operations
readiness · capacity · change safety"]
  classDef src fill:#ffffff,stroke:#9aa8c0,color:#173a6b;
  classDef store fill:#173a6b,stroke:#0f2a4f,color:#ffffff;
  classDef eng fill:#fdf0dd,stroke:#e0892a,color:#173a6b;
  classDef out fill:#e3f3f6,stroke:#1797b3,color:#173a6b;
  class S1,S2,S3,S4,S5 src;
  class SOT store;
  class ENG eng;
  class A1,A2,A3,A4 out;
  

1 Overview & situational awareness

Where you land and where you look first. This area pulls every risk the platform finds into one ranked list of what to act on now, tells you whether each problem was caused by a recent change, and gives you the live maps and health view you need to get your bearings fast.

flowchart LR
  R1["EoL HW / SW"] --> Q
  R2["Config drift · CVEs"] --> Q
  R3["Capacity near full"] --> Q
  R4["Down devices · spoofing"] --> Q
  R5["L2 loops · power gaps"] --> Q
  R6["Unticketed changes"] --> Q
  Q{{"Hotspots
normalize · severity-rank"}}
  Q --> ACT["One ranked queue
worst-first, with evidence"]
  ACT --> WC["'What changed?'
trace the audit chain to a verdict"]
  classDef src fill:#ffffff,stroke:#9aa8c0,color:#173a6b;
  classDef eng fill:#fdf0dd,stroke:#e0892a,color:#173a6b;
  classDef out fill:#e3f3f6,stroke:#1797b3,color:#173a6b;
  class R1,R2,R3,R4,R5,R6 src;
  class Q eng;
  class ACT,WC out;
  

Hotspots /hotspots GA

One ranked "what should I act on now" queue. It gathers every risk the platform finds, gear and software past end-of-life, configuration that has drifted from intent, known security vulnerabilities (CVEs), capacity nearing full, devices that are down, address spoofing, Layer-2 loops, gaps in power redundancy, and changes made without a ticket, then orders them worst-first. Open any hotspot for a full panel showing the affected object, the evidence, and the recommended next step.

Topology & maps /topology /map GA

The Layer-2 wiring map is built automatically from the neighbor announcements switches exchange (LLDP/CDP) and drawn as an interactive diagram. Filter it by vendor, by VLAN, or by a named network service to show only the devices that deliver one outcome and the links between them. The Network map is the geographic companion: your sites pinned on a map, with device counts and drill-down into each location.

More in this area

2 AV & media

Professional audio-visual gear is built into the model from the start, not bolted on afterward. CrossConnect finds AV equipment on its own and labels each device by what it is (camera, microphone, display, and so on). It then checks that AV is walled off from the rest of the network, that the precise timing every Dante/AES67 audio stream depends on is healthy, and that the shared media and discovery traffic actually flows. All of it runs on signals already collected, with no extra data entry and no packet capture.

flowchart LR
  subgraph SIG["Collected signals"]
    direction TB
    G1["MAC OUI (vendor)"]
    G2["mDNS service types"]
    G3["Observed media flows"]
    G4["LLDP / SNMP model strings"]
  end
  CLS{{"AV classifier
weighted vote → role + confidence"}}
  SIG --> CLS
  CLS --> INV["AV inventory
equipment · endpoints · evidence"]
  CLS --> ASR["AV assurance
segmentation posture · PTP · QoS"]
  CLS --> MC["Media plane
multicast · mDNS discovery"]
  classDef src fill:#ffffff,stroke:#9aa8c0,color:#173a6b;
  classDef eng fill:#fdf0dd,stroke:#e0892a,color:#173a6b;
  classDef out fill:#e3f3f6,stroke:#1797b3,color:#173a6b;
  class G1,G2,G3,G4 src;
  class CLS eng;
  class INV,ASR,MC out;
  

AV endpoints & evidence /av-endpoints /av-classify-evidence GA

Find out what AV gear is on the network and what each piece is, with no data entry from you. CrossConnect labels every AV device by type, codec, display, camera, microphone, DSP, AV-over-IP encoder/decoder, control processor, room PC, speaker, by combining four clues: the maker behind the hardware address (the MAC OUI), the services the device advertises over mDNS, the media traffic it is seen sending and receiving, and the model names it reports over LLDP/SNMP. Those clues produce one role and a Confirmed / Inferred / Unconfirmed chip. AV gear that is not in your inventory is flagged as a shadow AV device. When you want the detail, the evidence view shows one row per clue behind every decision: its kind, its raw value, the role it pointed to, how much weight it carried, the highest confidence it can support, and which collector saw it, so a label is never a black box.

Example: a Shure Dante box that advertises _dante._tcp and is sending AES67 audio is labelled av-microphone, Confirmed; an Apple device with no mDNS stays Unconfirmed, shown alongside a concrete next check to settle it.

AV posture & PTP / clock health /av-posture /ptp-health Configurable

AV posture tells you how well your AV gear is walled off from the rest of the network, as a 0–100 score with the reasons itemized. It combines the AV classifier, the zone model, and Batfish reachability into ranked findings, each backed by evidence: shadow AV on a sensitive segment (critical), AV control ports reachable from the user or guest network, cameras or microphones reachable from guest, AV devices straddling two VLANs. The score is honest about what it has checked, reachability findings only count once the formal analysis has actually run. PTP / clock health scores each timing domain and flags the two faults that make audio and video drift: a domain with only one master clock (no backup) and a master clock that has lost lock.

Example: posture 62/100, with one critical (a camera reachable from the guest VLAN); clock-health 70/100, where domain 0 has a single master clock and the domain-1 master is running free, no longer locked (clockClass 248).

QoS & the media plane /qos /multicast /mdns-health Configurable

QoS, the rules that give AV traffic priority, is read from each switch's running config into a per-port inventory (policy-maps, priority and bandwidth classes, markings, WRED, the DSCP trust boundary). From that, it finds AV-carrying devices with no priority policy at all, priority classes with no cap that can starve other traffic, and missing trust boundaries. Facts read from config are Confirmed; live queue-drop counts are honestly marked Not Measured until the matching counters (CISCO-CBQOS-MIB) are collected. The multicast suite scores the 239.x media traffic 0–100 across snooping, querier, routing, live delivery, and interoperability, each with vendor-specific fix steps. mDNS / discovery health watches the 224.0.0.251 discovery traffic and finds AV devices split across VLANs with nothing relaying their announcements between them. Every failing item comes with a copy-paste fix in Cisco, Arista, and Juniper syntax; nothing is applied for you.

More in this area

3 Inventory & facilities

The authoritative record of the physical world: every device with its vendor, model, role and software; the modules and spares inside each chassis; and the locations, racks, and power circuits that carry it all. This is the foundation every other area builds on.

flowchart LR
  V["Vendor"] --> M["Device model
U-height · lifecycle"]
  M --> D["Device
role · software · status"]
  D --> R["Rack position
U · front / rear"]
  R --> L["Location
site › building › room"]
  D --> P["Power port (PSU)"]
  P --> O["PDU outlet"]
  O --> F[("Power feed
rolled-up load")]
  classDef src fill:#ffffff,stroke:#9aa8c0,color:#173a6b;
  classDef store fill:#173a6b,stroke:#0f2a4f,color:#ffffff;
  classDef out fill:#e3f3f6,stroke:#1797b3,color:#173a6b;
  class V,M,L src;
  class D store;
  class R,P,O,F out;
  

Devices & network services /devices /network-services GA

The device inventory home lists every switch, router, and access point with its vendor, model, location, software version, role, and status. Every column filters and sorts, and this is the object the rest of the platform hangs risk, config, and connectivity off of. Above it sits the service layer: a named outcome the network delivers (for example, "Dante audio fabric" or "Site-B payments"), with the devices, VLANs, and circuits that deliver it tied to it, so health and impact roll up to the business outcome rather than to a single box. Create a service by hand, or accept a suggested one that CrossConnect pieces together from traffic flows, running-service names, and shared VLANs.

Racks & the power chain /rack /power GA

Rack diagrams track what sits in each rack unit, with drag-to-place, front and rear faces, and half-width mounting so two 1U devices can share one slot side by side. The power chain links a device's power-supply inputs through PDU outlets to a supply circuit (a feed), so you can trace draw from end to end. A feed's total load is the sum of every port that chains up to it, which is exactly what makes the redundant A/B power check in Operations meaningful.

More in this area

4 Connections & topology

How everything links together, and what travels along those links. This area covers physical cabling and ports, the endpoints learned off the switches, circuits and paths, wireless and room occupancy, and the analysis that tells you what would lose connectivity if a given device failed.

flowchart LR
  N["Discovered neighbors
LLDP / CDP"] --> T{{"Topology model"}}
  E["Endpoint records
forwarding + ARP"] --> T
  C["Running-config L3
adjacencies"] --> T
  T --> TR["Path tracing
physical · VLAN · IP"]
  T --> FI["Failure impact
blast radius"]
  T --> LOC["Locate a device
where-is-it + dossier"]
  classDef src fill:#ffffff,stroke:#9aa8c0,color:#173a6b;
  classDef eng fill:#fdf0dd,stroke:#e0892a,color:#173a6b;
  classDef out fill:#e3f3f6,stroke:#1797b3,color:#173a6b;
  class N,E,C src;
  class T eng;
  class TR,FI,LOC out;
  

Locate a device /locate GA

Type a MAC or IP address to find exactly which switch and port it sits on, learned from the records switches keep (their forwarding and ARP tables). Then get the full file on that endpoint in one place: what it is doing (observed traffic), whether it has hopped ports, any threat it is named in, and how to reach the switch out-of-band if the network is down. It is a single "where is it?" lookup with no manual entry, plus the context you would otherwise have to gather from four separate screens.

Failure impact & multicast delivery /failure-impact /multicast-groups Configurable

Failure impact answers "what breaks if this fails?" Pick a device, and CrossConnect removes it from a copy of the live network (using the Batfish model) and reports what loses connectivity. An empty result means your redundancy is proven; a list is your real exposure, named alongside the network services that device delivers. Multicast delivery is covered in detail in the AV area; the groups & map view here draws source-to-group-to-listeners from real traffic and IGMP membership, with no packet capture.

More in this area

5 Addressing & routing

Your full address plan, from the blocks a registry issued you down to the individual host, plus the VLANs, trust planes, and routing layered over them. The platform works out utilization, overlap, and the next free address as you go; purpose labels let you read the network by what each part is for; and the routing diagram is read from both live device state and what the configs intend.

flowchart LR
  AG["Aggregate
RIR / private"] --> SP["IP space"]
  SP --> PX["Prefix
utilization · next-free"]
  PX --> HO["Host IP"]
  VL["VLAN
+ IPAM role"] --> ZN["Trust plane / zone"]
  ZN --> SEG{{"Segmentation matrix
where planes bridge"}}
  RT["Routing
BGP · OSPF · fabric"] --> RM["Routing map
live state + config intent"]
  classDef src fill:#ffffff,stroke:#9aa8c0,color:#173a6b;
  classDef store fill:#173a6b,stroke:#0f2a4f,color:#ffffff;
  classDef eng fill:#fdf0dd,stroke:#e0892a,color:#173a6b;
  classDef out fill:#e3f3f6,stroke:#1797b3,color:#173a6b;
  class AG,SP,VL,RT src;
  class PX,ZN store;
  class HO,RM out;
  class SEG eng;
  

Prefixes & network zones /prefixes /zones GA

Prefixes are address blocks (in CIDR notation) with status, scope, and how full they are, plus overlap detection and a "next free subnet" answer worked out from both documented and discovered hosts. Network zones group your estate into trust planes (audio, video, control, management, data, guest) derived from your VLANs, with a matrix that shows where two planes meet on the same switch. This is the structural view behind the AV posture and segmentation checks: it tells you which planes should be kept apart.

Routing: BGP, OSPF, fabric & map /bgp /ospf /fabric /routing-map Configurable

BGP and OSPF routing sessions are found automatically from two sources, the live device counters (BGP4-MIB / OSPF-MIB) and the Batfish config model, with each row badged to show whether it came from what is documented or what was discovered. An assertions panel calls out sessions that are configured but down, and peerings nobody documented, as clickable findings with fix steps attached. Fabric checks a spine-leaf (Clos) design against the real topology and its BGP numbering (every leaf connected to every spine, no side links inside a tier, a unique number per leaf), and can suggest roles for you to confirm before committing. The routing map pulls all of this into one clickable diagram with a BGP / OSPF / site-level layer toggle, built once by a shared service so the map and the tables never disagree.

More in this area

6 Assurance & compliance

Proof that the network is correct, secure, and within policy, worked out from the configs and signals the platform already holds. This area answers plain questions ("can a guest reach the cameras?"), pinpoints the change that broke a flow, scores compliance frameworks as data, and rolls every risk into one ranked fix plan.

flowchart LR
  CFG["Running configs"] --> BF{{"Batfish formal model
whole-fleet"}}
  SIG["SNMP · flows · CVE feed"] --> ENG{{"Scoring & correlation"}}
  BF --> Q1["Reachability · segmentation"]
  BF --> Q2["ACL · config check · duplicate IPs"]
  BF --> Q3["Black box · change preview"]
  ENG --> Q4["CVEs · hardening · lifecycle"]
  Q1 --> FP[("Fix plan
one decision per device")]
  Q2 --> FP
  Q4 --> FP
  Q1 --> CO["Compliance
frameworks as data"]
  classDef src fill:#ffffff,stroke:#9aa8c0,color:#173a6b;
  classDef eng fill:#fdf0dd,stroke:#e0892a,color:#173a6b;
  classDef store fill:#173a6b,stroke:#0f2a4f,color:#ffffff;
  classDef out fill:#e3f3f6,stroke:#1797b3,color:#173a6b;
  class CFG,SIG src;
  class BF,ENG eng;
  class FP store;
  class Q1,Q2,Q3,Q4,CO out;
  

Reachability, segmentation & the black box /reach-check /segmentation /black-box Configurable

The "is AV properly separated?" question, answered two ways. Reachability check tests what you meant to happen: does traffic from A actually reach B through routing and every traffic rule (ACL), and is that what you intended? Segmentation goes further, comparing which trust planes should be kept apart against the traffic actually seen between them, so it catches the dangerous case nobody spots today: planes that are isolated on paper but have traffic crossing anyway. The network black box is a flight recorder for your configs: name a flow that used to work and stopped, and CrossConnect searches the saved config history against the formal model to pinpoint the exact change that broke it, returning the before/after difference and the time window as proof. It names the cause; it never changes anything.

Under the hood the black box (BlackBoxService) is built from four parts. A property oracle states the symptom as a yes/no question (today, reachability: can the source reach the destination on a given port?). A config timeline reconstructs the whole fleet’s state at any past moment from the saved configuration history. A bisector runs a binary search over that timeline (only about log-n checks, the halving trick used to find a word in a dictionary) for the moment the property flipped from good to broken. A cause report then names the exact devices and config lines that changed, with the full before and after text and an advisory note on how to reverse it. The property is evaluated by the Batfish formal model, which reasons across Cisco, Arista, and Juniper in one vendor-neutral model, so a failure that crosses vendors is proven, not guessed.

flowchart LR
  SYM["Symptom
flow should reach B"] --> OR["Property oracle
reachability"]
  TL["Config timeline
fleet state per instant"] --> BIS{"Bisector
binary search
good to bad flip"}
  OR --> BIS
  BIS -- "evaluate each probe" --> BF["Batfish model
vendor-neutral proof"]
  BF --> BIS
  BIS --> CR["Cause report
changed lines · proof
time window · reversal"]
  classDef app fill:#173a6b,stroke:#0f2a4f,color:#ffffff;
  classDef store fill:#e3f3f6,stroke:#1797b3,color:#173a6b;
  classDef gate fill:#fdf0dd,stroke:#e0892a,color:#173a6b;
  classDef ext fill:#ffffff,stroke:#9aa8c0,color:#173a6b;
  class OR,CR app;
  class TL,SYM store;
  class BIS gate;
  class BF ext;
  

Example: guest 10.99.0.0/24 to Dante 10.20.0.0/24 UDP 4440: PASS (isolated). The black box shows that path was healthy 48 hours ago and broken by an outbound traffic rule (ACL) added to Vlan20 on cor-bb-01 24 hours ago.

Fix plan & compliance /fix-plan /compliance Configurable

The fix plan is one ranked, per-device to-do list built from several separate risk lists, vulnerability (CVE) exposure, software and hardware lifecycle, and config hardening. Each at-risk device gets a single blended risk score and one recommended action, Replace, Upgrade, or Harden, ordered worst-first, with devices that carry a critical network service pushed up the queue. Compliance scores the controls in each framework (CIS, NIST-CSF, SOC 2, PCI, ISO) as data over evidence the platform already holds, so one reusable check counts toward many frameworks instead of being re-gathered for every audit.

More in this area

7 Operations

Running the network day to day: whether a site is ready, where capacity is heading, whether a change is safe to make right now, plus the automation, maintenance windows, and reporting that keep the work moving. It all reuses read-only telemetry you already collect, so there is nothing new to install or wire up.

flowchart LR
  TEL["Health telemetry
reachability · sensors"] --> RD["Service readiness
worst-of rollup"]
  TEL --> CP["Capacity
forecast-to-full"]
  CS{{"Change safety
GO / CAUTION / HOLD"}}
  RD --> CS
  CP --> CS
  BF["Reachability delta
blast radius (Batfish)"] --> CS
  MW["Maintenance window"] --> CS
  FL["Live flows"] --> CS
  CS --> AUT["Automation · jobs · reports"]
  classDef src fill:#ffffff,stroke:#9aa8c0,color:#173a6b;
  classDef eng fill:#fdf0dd,stroke:#e0892a,color:#173a6b;
  classDef out fill:#e3f3f6,stroke:#1797b3,color:#173a6b;
  class TEL,BF,MW,FL src;
  class CS eng;
  class RD,CP,AUT out;
  

Service readiness & change safety /readiness /change-safety GA

Service readiness rolls device health (reachability and environmental sensors) up to the groups that actually deliver a service, by site or by role, so you see whether a whole site is ready rather than just whether one switch is up. A group takes on the state of its worst member, with click-through to the reason. Change safety is the pre-flight cockpit: pick a device, optionally paste in a proposed config, and get one GO / CAUTION / HOLD verdict that combines four things, what would change about reachability, what breaks if the device fails, what the device is carrying right now, and whether you are inside a maintenance window. If the Batfish model is briefly unavailable, the check still runs on what it has.

Capacity planning /capacity Configurable

How full things are now and when they will run out, across power-over-Ethernet (PoE), rack space, bandwidth, and IP space, with a growth dial and what-if scenarios. A "capacity by service" rollup maps the most-stretched resource on each device onto the network services it supports, worst and most critical first, so you see pressure against a business outcome rather than just against a single device.

More in this area

8 AI assistant

A chat layer over your whole source of truth. You ask in plain language; it answers from your real records, cites what it used, and keeps documented truth separate from discovered reality. It advises and explains; it never changes the network on its own, and anything that would write a change asks you to confirm first.

flowchart LR
  QN["Question
plain language"] --> TOOLS{{"Grounded tools
tenant- & role-scoped"}}
  SOT[("Source of truth")] --> TOOLS
  TOOLS --> VAL{"Citation validator
cite or 'I don't know'"}
  VAL --> ANS["Cited answer
linked to records"]
  VAL --> WI["Write intent
confirm-before-commit"]
  TOOLS --> AUD["AI audit entry
prompt · retrieval · output"]
  classDef src fill:#ffffff,stroke:#9aa8c0,color:#173a6b;
  classDef store fill:#173a6b,stroke:#0f2a4f,color:#ffffff;
  classDef gate fill:#fdf0dd,stroke:#e0892a,color:#173a6b;
  classDef out fill:#e3f3f6,stroke:#1797b3,color:#173a6b;
  class QN src;
  class SOT store;
  class TOOLS,VAL gate;
  class ANS,WI,AUD out;
  

Assistant & AI quality /assistant /ai-quality Configurable

Ask about your fleet and get cited, formatted answers drawn from the live source of truth. The assistant respects each user's access rights (it never shows data the user is not allowed to see), reveals the records behind an answer, and logs every prompt, lookup, and answer. AI quality is the improvement loop: a quality score plus a backlog of answers the assistant handled poorly (unsupported by records, held back, or thumbed-down), where each miss points to a tool to add, a feature to document, or a record to fix.

More in this area

9 Administration & governance

The controls that make the platform safe to run and trust: keeping each tenant's data separate, users and roles, a tamper-evident record of every change, the discovery settings that find new gear, encryption-key administration, and connectors that stay off until you turn them on and that pass through a trust review, so nothing from outside quietly becomes truth.

flowchart LR
  subgraph T["TENANT BOUNDARY"]
    direction TB
    U["Users & roles
RBAC, granular perms"]
    SOT[("Source of truth")]
    K["Encryption keys
master key, rotation"]
  end
  CH["Every change"] --> AUD["Tamper-evident chain
hash-linked, verifiable"]
  IN["Inbound feeds"] --> GATE{"Inbound review
score · operator confirm"}
  GATE --> SOT
  SOT --> OUT["Outbound: webhooks · sinks
signed, retrying"]
  classDef src fill:#ffffff,stroke:#9aa8c0,color:#173a6b;
  classDef store fill:#173a6b,stroke:#0f2a4f,color:#ffffff;
  classDef gate fill:#fdf0dd,stroke:#e0892a,color:#173a6b;
  classDef out fill:#e3f3f6,stroke:#1797b3,color:#173a6b;
  class CH,IN src;
  class SOT,U,K store;
  class GATE gate;
  class AUD,OUT out;
  

Audit chain & inbound review /recent-events /logs /inbound-review GA

Every change is recorded into a chain where each entry is cryptographically linked to the last, so you can prove none of it was altered. That guarantee is what backs the "what changed, likely cause" traces and the compliance evidence. Filter by kind and time, verify the chain, and export to CSV. Inbound review is the trust gate for feeds coming in: outside claims arrive as proposals, matched to a known entity and scored for confidence by how well other sources back them up, for you to confirm or dismiss. Nothing inbound quietly becomes truth, two sources that agree score high, while an unknown host scores low and waits for review.

Encryption keys & connectors /encryption-keys /integrations /webhooks Configurable

Encryption keys is the administrator view of the master key that protects stored secrets, with a rotation that re-wraps the data key under a fresh master key without having to re-encrypt all your secret data, plus a snapshot taken before rotation that you can roll back to. Integrations lists every inbound and outbound feed, each off by default and switched on in config, with its status and how to enable it. Webhooks are signed outbound messages on 50+ event types, with automatic retries; outbound sinks are a lighter way to push the activity stream to a security log system (SIEM), Slack, Teams, or PagerDuty.

More in this area

10 Experimental & Labs

Forward-looking capabilities shipped as clearly labelled previews. Each is read-only and advisory, runs on the same signals and formal model the rest of the platform uses, and is honest about where an educated guess ends. They live under the product's Experimental menu so an evaluator can watch the roadmap working against real data without mistaking a preview for a guaranteed feature.

Gravitational Wobble & Happy Auditor /wobble /happy-auditor

Gravitational Wobble spots a device CrossConnect does not manage by the mark it leaves on the gear it does, the way astronomers find an unseen mass by how it tugs on visible stars. It never probes the unknown device and never captures packets; it reads state already collected (LLDP neighbors, forwarding/ARP tables) and flags a neighbor or endpoint that matches nothing in inventory, pinned to the exact managed port that sees it. Happy Auditor builds a one-click, timestamped, control-by-control evidence pack that an auditor or cyber-insurance underwriter will accept as proof: each control's Satisfied / Gap / Not-applicable status with its evidence, segmentation attestations, the tamper-evident change history, and a verdict on whether the audit chain itself is intact, exportable as self-contained HTML or CSV.

Sense & Red Twin /sense /red-twin

Sense turns the network itself into a building sensor: room occupancy, AV in use, energy draw, and signs of physical tampering, all inferred from signals the switches already give off (PoE power draw, mDNS AV announcements, IGMP membership, reachability, LLDP), with no cameras, badge readers, or packet capture. Red Twin is a continuous, zero-risk attacker that lives entirely inside the Batfish model and never touches production: starting from a foothold, it searches the model for a path to a high-value target, works out the single traffic rule (ACL) or trunk line that would cut that path (checked in the model to confirm it closes the path and breaks nothing else), and prices each finding against a published cost table (Uptime Institute, ITIC, IBM) as an advisory range, never a quote. It shows the path and writes the fix; it never applies one.

Peek-a-Boo /peek-a-boo /av-displays /av-codecs /av-dsp

Peek-a-Boo gathers every network-attached AV camera into one gallery: vendor, model, firmware, location, whether it is online, and whether it is in use right now, drawn from the cameras CrossConnect already classifies. Each card carries risk flags (a vendor barred under NDAA §889, past end-of-support, a known vulnerability) and a "watching" verdict worked out from media bitrate and PoE draw alone, with no video, so a covered lens (BLIND) or a replayed feed (LOOPED) gets caught; a camera missing from the latest scan stays on the board as GONE DARK. Companion views take the same approach to displays and projectors (checked live over PJLink), video-conferencing codecs (a credential-free SIP OPTIONS ping), and DSP/audio gear (Q-SYS cores checked over QRC). Each tries the real thing first: a device it can reach is Confirmed-live; one it cannot falls back to its classification and inventory data.

11 Learn & onboarding

The guided front door to both the product and your own network, plus a library of how-to workflows, end-to-end playbooks, the full API reference, and a map of where every piece of data comes from. Designed so a newcomer can build a working mental model without typing anything.

flowchart LR
  ATLAS["Start here / Atlas
your network in 60s"] --> WF["Workflows
single jobs"]
  WF --> PB["Playbooks
chained journeys"]
  DS["Where data comes from
provenance map"] --> ATLAS
  HW["Supported hardware
Formal · Config · Cloud"] --> ATLAS
  PB --> GOAL["Onboard a site ·
pass an audit"]
  classDef src fill:#ffffff,stroke:#9aa8c0,color:#173a6b;
  classDef eng fill:#fdf0dd,stroke:#e0892a,color:#173a6b;
  classDef out fill:#e3f3f6,stroke:#1797b3,color:#173a6b;
  class DS,HW src;
  class ATLAS,WF eng;
  class PB,GOAL out;
  

Start here, the Atlas /start GA

A guided front door that reads your real estate and draws its shape, counts, a tier diagram, breakdowns by vendor and role, and a clickable site-and-link map, then previews the operational features read-only against your own network: what is at risk, the AV fleet, what it is carrying, whether it is properly separated, and what is healthy. It also offers a live name/IP/MAC lookup, a built-in grounded assistant, and a clickable first-week path. Everything is read-only, so it teaches both the product and your network with no risk of changing anything.

Where our data comes from /learn/data-sources GA

A map of every kind of data CrossConnect holds and where it comes from, SNMP discovery, traffic flows, manual entry, config collection, the Batfish model, external feeds, cross-checking several sources, or pure computation, so you always know whether a fact was discovered, entered, computed, or pieced together. This honesty about origin is what lets the platform keep documented truth separate from discovered reality everywhere else, and it is what backs the AI's citations.

More in this area