Skip to content

Application Inference

Purpose

Application inference is how Clarity Transform turns discovered traffic and listening-port evidence into applications and dependencies. It works in three stages:

  1. Candidate services and candidate applications: hosts that run something, grouped by the traffic between them into proposed applications.
  2. Device suggestions: devices that belong to no confirmed application but talk to one that does.
  3. App-to-app suggestions: dependencies between two confirmed applications.

A confirmed application is one you have promoted from a candidate group. Stage 2 and stage 3 work against confirmed applications, so the order you work in matters. This workflow follows that order, then shows how to tune the reference lists and run again.

All runs start from one screen, Candidate Applications. The review pages (Device Suggestions, Suggested App-to-App, Unknown Hosts) have no run button of their own.

Before you start

  • Load the evidence. Inference reads relationships and flows brought in by integrations, for example the NetFlow page or a firewall integration, and listening ports from the Network Scan integration. See Infrastructure Discovery.
  • Check that the devices exist in the CMDB. Flow addresses that match no device are not grouped: they are listed on Unknown Hosts instead.

Stage 1: run inference and grouping

  1. Go to Discover → Application Inference → Candidate Applications.
  2. Select Run inference. While it runs, the button reads "Running inference..." and the banner above the grid shows the stage it is on. When it finishes, the banner reports the flows assessed and the numbers of discovered services, device suggestions and app-to-app suggestions.
  3. Select Run grouping. The banner reports how many groups were proposed and how many "need review". The grid reloads by itself.

Read both banners before going on. They report things that are easy to miss:

  • "Stage 3 needs at least two confirmed applications; N found. Promote candidate applications to enable it." This is expected on a new engagement.
  • Hosts "excluded from the device and app-to-app stages for talking to too much of the estate", named. Check whether these are shared infrastructure (stage 4 below).
  • Flows "with an IP address not in inventory left out". Those addresses are listed on Unknown Hosts.
  • Groups that "could not be checked for a split (too few hosts, no usable flow evidence, or no naming convention)". The banner says this "is not an all-clear": check those groups' members yourself.

If Run inference reports "An inference run is already in progress.", wait for that run to finish and try again.

More: Candidate Applications.

Stage 2: review and promote candidate applications

  1. In the Candidate Application Groups grid, look at Seam Summary:
    • Review split: the group looks like more than one application. Use the Looks like more than one application - review the split row action. If the members are separate applications, select Split into separate applications.
    • Check members: the group includes a host that may not belong. Use the Includes a host that may not belong - review the members row action and select Remove next to each host that does not belong.
  2. Select View members on any group to see its hosts and their Flags (Conflict: application, Shared dependency or May not belong). Remove from this group detaches a host from the group. Its own candidate service is not changed.
  3. Select Promote to application on each group you have confirmed. In Application name, replace the generated placeholder with the real business application name, then select Promote.

Promotion "Creates one Application record and a runs-on relationship for each eligible member. A member that already carries a different application is skipped and left untouched." Promotion cannot be undone. If the result banner says "with exclusions", the devices it names were not mapped to the new application.

It's one application in the split dialog records nothing. The group keeps its Review split flag. To keep the group whole, promote it and accept the warning in the promote dialog.

More: Candidate Applications.

Stage 3: run inference again

  1. Go back to Candidate Applications and select Run inference again.
  2. Check the banner. The "Stage 3 needs at least two confirmed applications" line should be gone once two or more applications are confirmed.

Device suggestions and app-to-app suggestions are worked out against confirmed applications, so a run made before you promoted finds few or none.

Stage 4: accept or suppress the suggestions

  1. Go to Discover → Application Inference → Device Suggestions. The grid opens on Pending. For each row, choose Accept - write runs-on relationship to add the device to the application, or Suppress - never recreate.
  2. Go to Discover → Application Inference → Suggested App-to-App. The grid opens on Pending. Read Evidence, Confidence, Direction and Contributing Pairs together, then choose Accept - write the app-to-app relationship or Suppress - never re-propose.

Accepting an app-to-app suggestion writes an app-to-app relationship to the CMDB. The dialog explains: "Wave planning, move groups and the migration risk dashboard all read these, so this dependency will start affecting planning." Suppressing tells inference never to propose that pair again, and "This cannot be undone." Accepted and suppressed rows have no actions on the page. Leave a row pending if you are not sure.

If the run banner said pairs "were not proposed because the per-run ceiling was reached", the queue is incomplete. Accept or suppress what is there, then run inference again.

More: Device Suggestions, Suggested App-to-App.

Stage 5: tune the reference lists and run again

Five lists change what the next run does. Saving a row on any of them does not start a run: select Run inference, then Run grouping, on Candidate Applications afterwards.

List What it changes When to use it
Port / App Mapping The service name given to a port seen in traffic or listening. The estate uses its own ports, or a registered port for something else.
Flow Exclusions Ports and protocols "excluded from inference entirely". Infrastructure noise links unrelated hosts. Check Discovered Listening Ports first, so you do not exclude a port an application uses.
Utility Hosts Devices flagged as shared infrastructure, "so candidate grouping doesn't bridge unrelated applications together through them". A monitoring, backup or directory server merges applications into one group.
Evidence Sources Which relationship types and integrations count as evidence, and how much each can weigh. A relationship type is ignored, or firewall permits carry too much weight.
Unknown Hosts Nothing in the run itself: it is "a discovery hygiene queue, not something inference groups". Extend discovery to cover addresses that belong in the migration, then run inference again. Dismiss only addresses you have identified.

Later runs keep your decisions: suppressed pairs are not proposed again, pairs you accepted are reported as "already recorded", and groups you split by hand are left alone by Run grouping.

Settings → System Settings also holds four seeded inference settings: CandidateGroupingDegreeThreshold (20), CandidateGroupingSizeThreshold (12), EphemeralPortFloor (49152) and FlowDerivedListeningPortMinSources (3).

More: System Settings.

Stage 6: check the result as a graph

Go to Discover → Application Mapping, select an application in the sidebar, and check its relationships. Right-click a connection for its Connection Details, including whether it "Crosses move group boundary".

More: Application Mapping, Asset Relationships.

Troubleshooting

Symptom Cause What to do
Device Suggestions or Suggested App-to-App is empty. The queues are filled only by Run inference, and stages 2 and 3 work against confirmed applications. Run inference, run grouping, promote at least two applications, then run inference again.
The banner says "Stage 3 needs at least two confirmed applications". Fewer than two applications are confirmed. Promote candidate groups, then select Run inference again.
A queue shows fewer rows than expected. The grid opens filtered to Pending. Select All.
A group still shows Review split after It's one application. That button only closes the dialog. Promote the group and accept the warning, or split it.
Promote is greyed out. Application name is empty. Enter the application name.
The promote result says "with exclusions". A member already carries a different application, or has no candidate service still Pending. Resolve that device's application on its own.
Changes to a reference list made no difference. Saving does not start a run. Select Run inference, then Run grouping.
Many applications merge into one group through a single host. The host is shared infrastructure. Flag it on Utility Hosts, then run inference and grouping again.
"An inference run is already in progress." Another inference run has not finished. Wait, then run again.

Questions people ask

Where do I start a run? On Candidate Applications, with Run inference. The Run App Inference button on the NetFlow page starts the same run and reports it as a flow and relationship summary.

Does Run grouping undo a split I made? No. The banner reports sets "left alone - already split by hand".

Can I undo a promotion or a suppression? Not from these pages. The promote dialog says "Promotion cannot be undone", and accepted or suppressed suggestions have no row actions.

What is the difference between Observed, Permitted and Corroborated? Observed is traffic that was seen. Permitted is a firewall rule allowing traffic, not traffic anybody saw. Corroborated ranks above both. See Suggested App-to-App.

Why are some addresses not in any group? Flow addresses that match no device are left out of grouping and listed on Unknown Hosts.