Experimental Features Explained

0 How to read this document

Each section names a capability, explains the idea in everyday terms, then states the mechanism: the signals it reads, the service that computes it, and the boundary of what it can and cannot prove. Where a capability currently runs on illustrative data, or depends on a collector that is not yet connected, we say so plainly. An inference is called an inference, and a number that has a source is shown with that source.

1 What “experimental” means here

These five are previews: capabilities we are still shaping. They are kept in a clearly marked corner of the product, separate from the features you use every day. The "experimental" label is precise, not decorative. Here is what it guarantees.

The map below shows how the five relate and what they lean on. All of them read signals CrossConnect already collects. Two of them stand on production capabilities documented elsewhere: Red Twin and (through its verdict) Gravitational Wobble use the same Batfish formal model and the production Network Black Box the assurance tooling uses, and Peek-a-Boo sits on top of the production AV endpoint classification. (A formal model is a precise mathematical representation of the network that questions can be tested against.)

flowchart TB
  COLL["Collected signals
SNMP · SSH config · LLDP · PoE · mDNS · IGMP · audit chain"]
  AVC["AV endpoint classification
(production)"]
  BF["Formal model
Batfish sidecar"]
  BB["Network Black Box
(production)"]
  COLL --> AVC
  COLL --> BF
  BF --> BB
  PB["Peek-a-Boo
which cameras are blind?"]
  WB["Gravitational Wobble
what unmanaged device is here?"]
  RT["Red Twin
where could an attacker reach?"]
  SE["Sense
what is happening in the building?"]
  HA["Happy Auditor
can I prove compliance now?"]
  AVC --> PB
  COLL --> WB
  BB -. "external-cause verdict" .-> WB
  BF --> RT
  COLL --> SE
  COLL --> HA
  classDef app fill:#173a6b,stroke:#0f2a4f,color:#ffffff;
  classDef store fill:#e3f3f6,stroke:#1797b3,color:#173a6b;
  classDef ext fill:#ffffff,stroke:#9aa8c0,color:#173a6b;
  class PB,WB,RT,SE,HA app;
  class COLL,AVC store;
  class BF,BB ext;
  

2 Peek-a-Boo and the AV endpoint modules Live engine Experimental camera layer

Know every audio-visual (AV) device on the network by type, codec, display, camera, microphone, or signal processor, from the signals the gear already gives off, then watch the ones that matter most: the cameras.

AV gear is the hardest inventory to keep honest. Integrators plug it in, it moves between rooms, and it rarely makes it onto the diagram. CrossConnect types it automatically from signals it already collects, and then, for cameras specifically, adds an experimental preview (Peek-a-Boo) that tells you not just that a camera exists but whether it is doing its job. The typing layer underneath is production; the camera preview on top is experimental.

The production layer: AV endpoint classification

The classifier (AvEndpointClassifier) sorts each device into an AV role from signals already in the database, then attaches a confidence label so a guess is never mistaken for a fact. It writes no new collection of its own. The roles and the views that surface them (av-endpoints, av-classify-evidence) are part of the shipped product, not the experimental corner.

The roles it assigns are av-codec, av-display, av-camera, av-microphone, av-dsp (digital signal processor, the audio matrix in a room), avoip-encoder and avoip-decoder (AV-over-IP source and screen), av-control (the room control processor), av-room (a meeting-room PC), and av-speaker. Per-type modules then go a step further and ask the device itself how it is doing, live first and falling back to the classified record when a probe is not available: Displays (av-displays) over PJLink for power and input state, signal processors (av-dsp) over Q-SYS for run-state and loaded design, and codecs (av-codecs). When a typed device is not in inventory, it is surfaced as a shadow AV endpoint for an operator to confirm, never created automatically.

Peek-a-Boo: the experimental camera layer Experimental

Cameras are the AV devices a security team cares about most, and the ones most likely to be quietly broken. Peek-a-Boo (PeekABooService, route peek-a-boo) starts from the cameras the classifier already found (by vendor, OUI, mDNS, ONVIF announcement, and existing media flows) and adds a condition read: not just online or offline, but a watch-state, live, blind, looped, static, or no-stream, plus flags for cameras that are prohibited under NDAA section 889, exposed to a known CVE, gone dark, or silently swapped for different hardware. An operator can acknowledge or clear these conditions in bulk; a read-only viewer cannot.

Peek-a-Boo is genuinely experimental. The early stages are live (build the candidate set, resolve MAC to IP, and correlate each camera with its switch location, firmware age, and CVE exposure). The deeper stage, a live ONVIF probe that logs into the camera to confirm it is really streaming, is built and real-first but dormant by default (crossconnect.peekaboo.probe-enabled=false) until camera credentials are wired in. Until then a camera is reported from classification and inventory, and the report says so.

flowchart LR
  subgraph SIGNALS["Signals already collected"]
    direction TB
    MDNS["mDNS service types"]
    FLOW["AvMediaFlow
Dante · AES67 · NDI · Q-SYS"]
    MODEL["LLDP / SNMP model"]
    OUI["OUI vendor · DHCP"]
  end
  CLS{"AvEndpointClassifier
role + confidence"}
  SIGNALS --> CLS
  CLS --> DISP["Displays
PJLink probe"]
  CLS --> DSP["Signal processors
Q-SYS probe"]
  CLS --> COD["Codecs"]
  CLS --> CAM(["Peek-a-Boo cameras
watch-state · NDAA · CVE
live ONVIF probe (dormant)"])
  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 DISP,DSP,COD app;
  class MDNS,FLOW,MODEL,OUI store;
  class CLS gate;
  class CAM ext;
  

3 Gravitational Wobble Hybrid Experimental

Find a device you do not manage, one you never discovered and that gives off no SNMP, no config, and no LLDP, by the mark it leaves on the equipment you already watch.

Astronomers find an unseen planet without ever photographing it: they watch the visible stars and measure the tiny wobble that the unseen planet’s gravity causes. A network has the same shape. The riskiest thing on it is often the device nobody knows is there: a switch plugged in under a desk, an unauthorized wireless access point, or a hidden device spliced into a path. It never announces itself, but the moment it does anything that matters it disturbs the state of the managed devices around it, and we read that disturbance. We do not detect the device directly. We detect its wobble, and from the wobble we locate it, classify it, and tie it to whatever it broke.

How it works

GravitationalWobbleService runs read-only (@Transactional(readOnly = true)) and matches what it sees live against the managed inventory. Two wobble signals are live today:

• Unknown LLDP neighbour. LLDP is the protocol switches use to announce themselves to their neighbours. A managed switch reports an LLDP neighbour (DiscoveredNeighbor.remoteSysName) that matches no device in inventory. The matcher unknownNeighbours(...) ignores blank names and known devices, removes duplicates by (device, port, identity), and produces a finding pinned to the exact port.
• Unmanaged endpoint. RogueDeviceService.unmanaged(tenantId) surfaces a MAC or IP address seen in forwarding or ARP tables that belongs to no device in inventory: an unknown host on a known port.

Each WobbleFinding is a ghost node. It records the managed device and port it hangs off, an optional VLAN, the inferred identity (remote name, or MAC/IP address), a severity, a confidence label that always begins with Inferred (for example “Inferred (LLDP neighbour not in inventory)”), and a plain-language recommendation, never an action. The design extends this list to many more kinds of wobble: sudden spikes in the number of MAC addresses on a port, ARP-to-MAC changes over time, MAC-flap and STP churn from an unauthorized loop, rogue DHCP servers, and the silent inline device that quietly absorbs traffic. Those depend on a syslog collector and time-based comparison snapshots that are not yet connected. The document is clear that today only the LLDP and endpoint signals are live.

flowchart LR
  subgraph SIG["Live wobble signals"]
    direction TB
    LLDP["Unknown LLDP neighbour
remoteSysName ∉ inventory"]
    EP["Unmanaged endpoint
MAC / IP in FDB·ARP
∉ inventory"]
  end
  BBV(["Black Box verdict
'external cause'
(corroborating, design)"])
  JOIN{"Join
wobble + symptom
+ no internal cause"}
  SIG --> JOIN
  BBV -. "negative evidence" .-> JOIN
  JOIN --> GHOST["Ghost node
port · VLAN · identity
severity · Inferred · advice"]
  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 GHOST app;
  class LLDP,EP store;
  class JOIN gate;
  class BBV ext;
  

4 Red Twin Hybrid Experimental

A safe attacker, set loose on a faithful copy of your network inside the formal model, that finds the path to your most sensitive systems and writes the single line that closes it, before anything happens for real.

The only way to be sure a burglar cannot reach the safe is to try, and you would never run that test on your real network. Red Twin runs it against the Batfish formal model, the same mathematical model that already powers reachability and ACL analysis. It explores a copy, so the real network is never touched, and it produces two kinds of finding.

• Attack paths. A path an attacker could follow from a starting foothold (a guest VLAN, or a compromised AV endpoint) to a high-value target (cardholder data, an OT controller, a domain controller). Each AttackPath records its hops, the weakLink, the single minimalCut config line that cuts the path, a severity, and a confidence percentage. That cut is re-checked in the model to confirm it closes the path without breaking something else.
• Failure futures. A simulated failure (a switch reboot, a lost circuit, a failed power supply) that would cascade into an outage. Each FailureFuture records its trigger, how far the damage spreads, the cheapestFix, and a rough cost.

Red Twin stays grounded in your live network through a ModelScope. This records whether the formal model is online, how many real segmentation exposures exist today (management interfaces left exposed, cameras reachable from the guest network, shadow devices on sensitive segments, all totalled from the live AvSegmentationAnalyzer), and how many sensitive endpoints there are. The exposures it counts are the real footholds. The attack paths and failure futures shown in the preview are an illustrative set (flagged illustrative: true) so the capability can be shown before the background scenario runner is connected. The live grounding is real; the worked examples are for illustration.

The cost outlook

RedTwinEconomics adds an advisory cost layer. For each finding it matches the closest profile in a sourced reference table and shows, ahead of time, the cost if it happens and the cost to fix it now, with a return-on-investment (ROI) line. Attack paths match to breach costs by the type of target (cardholder/PCI, OT/SCADA, domain controller) against IBM 2024–2025 ranges; failure futures scale by severity against Uptime Institute 2025 and ITIC 2024 figures. Every number is a range with a source and a caveat. A CostProjection records where its figure came from and a confidence of SPECIFIC (a matched profile) or BROAD (a fallback range). When the match is weak, the interface says “no close cost match” rather than inventing a precise figure.

flowchart LR
  LIVE["Live network"] --> SCOPE["ModelScope
real exposures
= the footholds"]
  SCOPE --> TWIN["Batfish twin
safe copy of the model"]
  TWIN --> AP["Attack paths
foothold → crown jewel
minimalCut (validated)"]
  TWIN --> FF["Failure futures
trigger → outage
cheapestFix"]
  AP --> ECON["Cost outlook
incident vs remedy
range · source · ROI"]
  FF --> ECON
  classDef app fill:#173a6b,stroke:#0f2a4f,color:#ffffff;
  classDef store fill:#e3f3f6,stroke:#1797b3,color:#173a6b;
  classDef ext fill:#ffffff,stroke:#9aa8c0,color:#173a6b;
  class AP,FF,ECON app;
  class SCOPE,TWIN store;
  class LIVE ext;
  

5 Sense Hybrid Experimental

Read the physical and human state of a building, which rooms are in use, what is drawing power, and what just got unplugged, from the switches you already own, with no cameras, badge readers, or motion sensors.

Every meeting room runs on a network switch, and that switch already tracks more than traffic. It sees when displays and microphones wake up, how much power they pull over PoE (Power over Ethernet, which delivers electricity to devices through the network cable), the announcements that AV gear broadcasts, and the moment a device goes dark. Sense is a thin, read-only layer that derives meaning from signals already in the database, turning them into a live, per-room view of who is present and what is happening physically. It inspects no packets and adds no new collection.

What it derives, and from what

SenseService caches results per tenant on a 15-second timer (TtlMemo), since physical state changes at human speed. It reads live counts today, distinct AV mDNS services, PoE switches and total watts, and multicast groups, through gatherReal(...), which is wrapped so that a failed query degrades gracefully instead of crashing the view. Presence and AV-in-use are inferences: each room carries a confidence percentage built from weighted ConfidenceFactors, and is clearly labelled as inferred, never presented as a direct sensor reading.

flowchart LR
  subgraph EXIST["Already collected · no new ingestion"]
    direction TB
    POE[("DiscoveredPoe
watts · operStatus")]
    MDNS[("DiscoveredMdnsService
AV announcements")]
    IGMP[("DiscoveredIgmpMembership")]
    PTP[("DiscoveredPtpClock")]
    AUD[("audit chain
work-order evidence")]
  end
  ASM["Snapshot assembler
per-room rollup"]
  POE --> ASM
  MDNS --> ASM
  IGMP --> ASM
  PTP --> ASM
  AUD --> ASM
  ASM --> SVC["SenseService
TtlMemo 15s"]
  SVC --> PR["Presence + AV-in-use
(inferred · confidence)"]
  SVC --> EN["Energy per room"]
  SVC --> TA["Physical-tamper
advisory finding"]
  classDef app fill:#173a6b,stroke:#0f2a4f,color:#ffffff;
  classDef store fill:#e3f3f6,stroke:#1797b3,color:#173a6b;
  class PR,EN,TA,ASM,SVC app;
  class POE,MDNS,IGMP,PTP,AUD store;
  

6 Happy Auditor Live engine Experimental

Audit-ready in one action: a dated, point-by-point evidence pack with a single score and a tamper-evident proof that nothing was edited after the fact.

An audit should not cost three weeks of screenshots and spreadsheets. Happy Auditor builds the proof while you watch. One action produces a dated evidence pack for a chosen compliance framework: what is satisfied, where the gaps are, a single score, and a verdict on whether the audit trail behind it is intact.

What the pack contains, and how it is built

EvidencePackService.build(tenantId, frameworkKey) takes a snapshot at the moment you generate it, combining several live evaluations into one EvidencePack record:

• Controls: from ComplianceService.evaluate(...), each control shown as Satisfied / Gap / Not applicable (PASS / FAIL / NOT_APPLICABLE) with its supporting evidence text, plus counts and a score (scorePct).
• Segmentation: what policy says must stay isolated versus the traffic actually observed (segMustIsolate, segVerified, segLeaks).
• Drift: devices that have drifted away from their approved golden-config baseline (driftCount and the list).
• Audit-chain integrity: EventAuditService.verifyChain(tenantId) returns an AuditIntegrityReport (intact, total, verified) that becomes the pack’s auditChainIntact verdict, plus a sample of recent audit entries.

The evaluation runs a Batfish-backed compliance check off the UI thread, so it never freezes the view. The pack renders to a self-contained HTML document (with its styling embedded and no external dependencies) or to a CSV file for auditors who work in spreadsheets. Both are produced by EvidencePackExport, a self-contained renderer, so the same input produces the same bytes every time. Nothing is written to a file on the server; the export is handed to the browser as a download.

flowchart LR
  CS["ComplianceService
controls · score"] --> PACK["EvidencePack
(snapshot @ now)"]
  SEG["Segmentation
isolate vs observed"] --> PACK
  DR["Golden-config drift"] --> PACK
  AC["verifyChain()
recompute hash · HMAC"] --> PACK
  PACK --> OUT["One action → export"]
  OUT --> H["HTML pack
self-contained"]
  OUT --> C["CSV pack
spreadsheet"]
  classDef app fill:#173a6b,stroke:#0f2a4f,color:#ffffff;
  classDef store fill:#e3f3f6,stroke:#1797b3,color:#173a6b;
  classDef gate fill:#fdf0dd,stroke:#e0892a,color:#173a6b;
  class PACK app;
  class CS,SEG,DR,H,C store;
  class AC gate;
  

7 What is real, and what is illustrative

The rule across the product is real-first: every capability tries the real source first, and clearly labels anything it cannot fully ground in live data yet. The table below is the honest summary of where each one stands today.