Candidate Applications

Purpose

Candidate Applications is where Clarity Transform assembles individual candidate services into whole applications. A candidate service says "this host runs something on this port"; an application is usually several of those working together. Grouping proposes each connected set of hosts as a candidate application, and flags any group that looks like more than one application. The on-screen subtitle reads: "Single-host candidate services grouped by existing traffic evidence into one reviewable application, ready to rename and promote as a unit."

This page is also where you start application inference for every Application Inference queue, with Run inference.

A flagged group is a prompt to review. The group is not changed until you choose what to do with it.

Where to find it

Discover → Application Inference → Candidate Applications. The page header is Candidate Application Groups.

What you see

Buttons

• Run inference: runs application inference over the evidence from the integrations. While it runs, the button reads Running inference... and the result banner shows the stage the run has reached.
• Run grouping: groups the candidate services into candidate applications. The button is unavailable while a grouping run is in progress.

The grid toolbar has Reload table data and Export. Export offers Copy, Excel, CSV and PDF. There is no create or edit form: groups are produced by Run grouping, not entered by hand.

Columns

• Suggested Name: the group's name. A generated name has the form Candidate App-01.
• Status: Pending (not yet decided), Promoted or Suppressed; values seen: Pending. The page has no action that suppresses a group.
• Confidence: values seen: Low.
• Component Size: the number of hosts in the group, shown as "N host(s)".
• Seam Summary: shows a badge where grouping found something to review. Hover over the badge to read the full finding.
  • Review split: the group may be more than one application.
  • Check members: the group looks like one application but includes a host that may not belong, typically a client of the application rather than part of it.
• Actions: the row actions below.

Row actions

• View members: on every row. Opens the Members of dialog for the group.
• Looks like more than one application - review the split: shown only on a Pending group flagged Review split. Opens the Review split of dialog.
• Includes a host that may not belong - review the members: shown only on a Pending group flagged Check members. Opens the same dialog, titled Review members of.
• Promote to application: shown only on a Pending group. Opens the Promote Group to Application dialog.

A promoted group shows only View members.

Dialogs

• Members of group: the dialog reads "Remove a host before promoting if it does not belong in this application. Removing a host only detaches it from this group - its own candidate service is untouched and remains individually promotable." It lists the members with the columns Device, Flags and Action, and has the buttons Close and Promote this group.
  • Flags can show Conflict: followed by the application the device already belongs to, Shared dependency, and May not belong. May not belong is worked out from current evidence when the dialog opens, and only for a group that carries a finding. If that check fails, the list ends with "Could not check for hosts that may not belong - flags may be incomplete."
  • Action has a Remove from this group button on each member. It removes the host from the group straight away, with no confirmation, and rechecks the group's finding. When the last member is removed, the dialog shows "No members left in this group."
• Review split of group: the dialog reads "This group looks like more than one application connected by a small number of calls. Splitting creates one candidate group per application and records the crossing calls, so that once both sides are promoted the dependency between them is written to the CMDB as an app-to-app relationship. If it really is a single application, close this and promote it as-is." It then works the split out again from current evidence, showing "Recomputing the seam from current evidence..." while it does. When it is ready it shows:
  • Proposed applications: each proposed application, with its hosts.
  • Shared by all sides, where there are any: hosts "Reachable from more than one application, so kept in each rather than assigned to one."
  • Calls crossing between them: "These become the app-to-app dependency once both sides are promoted."
  • Hosts that may not belong to either side, where there are any: "Splitting keeps them with the larger side so nothing is lost. Remove them from that group afterwards."
  • The buttons It's one application and Split into separate applications, and the close icon. There is no Cancel. Split into separate applications stays unavailable until the proposed split has been worked out.
• If the recheck finds no split, the dialog says so instead and Split into separate applications stays unavailable:
  • "This group no longer looks like more than one application - current evidence connects it throughout. Nothing to split."
  • "This group could not be checked." with the reason, and "This is not an all-clear - the group may still be more than one application. Nothing has been changed."
• Review members of group: shown instead when the group is one application with a host that may not belong. It says "This looks like one application with a host that may not belong." (or "hosts"), explains "Each only calls into this application and shares no naming with it - typically a client of it rather than part of it. Remove what does not belong, then promote the group as a single application.", and lists each host with a Remove button. Split into separate applications is not shown. When nothing out of place is left, the dialog says "Nothing left that looks out of place. This group can be promoted as a single application."
• Promote Group to Application:
  • Application name: text, filled in with the group's suggested name and selected, ready to overwrite. Help: "This becomes the Application's permanent name in the CMDB. Promotion cannot be undone, so give it the real business application name rather than the generated placeholder."
  • The dialog states what promotion writes: "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."
  • The buttons Cancel and Promote. Promote is unavailable while Application name is blank.
  • While the name is still a generated placeholder such as Candidate App-01, the dialog warns "Still the generated placeholder - rename it to the real application name." You can still promote.
  • A warning when the group has an open finding: "This may be more than one application." (use Review split first if it should be separate applications) or "This may include hosts that do not belong." (use Check members first to remove them). Promoting with the warning creates one application covering every member.

Result banner

Run inference, Run grouping, a split and a promotion each report their outcome in a banner above the grid, and the grid reloads itself.

• Run inference shows "Starting inference run..." and then its progress while it runs. It then reports "N flow(s) assessed." and the number of discovered services, device suggestions and app-to-app suggestions it produced, with the app-to-app count split into new and updated. It can add:
  • "Stage 3 needs at least two confirmed applications; N found. Promote candidate applications to enable it." Stage 3 is the app-to-app stage. Until two applications are promoted, it proposes nothing.
  • "N pair(s) left alone - already accepted or suppressed."
  • "N pair(s) not proposed - the dependency is already recorded."
  • "N pair(s) were not proposed because the per-run ceiling was reached - the queue is incomplete. Accept or suppress what is there and re-run."
  • "N host(s) excluded from the device and app-to-app stages for talking to too much of the estate", with the number of flows and the host names.
  • "The app-to-app queue could not be updated by this run (candidate services and device suggestions were saved). Check the log."
  • If a run is already going: "Error: An inference run is already in progress."
• Run grouping reports "N group(s) proposed.", then the candidates that "stayed ungrouped", the "node(s) excluded for high connectivity", the "set(s) excluded as too broad" and the "set(s) had no unresolved signal". It can add:
  • "N set(s) left alone - already split by hand." A group you split is not regrouped.
  • "N flow(s) with an IP address not in inventory left out - run inference to list those addresses under Unknown Hosts."
  • "N group(s) need review - see the row actions."
  • "N group(s) could not be checked for a split (too few hosts, no usable flow evidence, or no naming convention) - that is not an all-clear."
• Split into separate applications reports "Split into N candidate application(s). Name and promote each one; the crossing calls become an app-to-app dependency once both sides are promoted."
• Promote reports "Promoted as" the new name and "Every member was mapped to the new application." If some devices could not be mapped, the banner says "with exclusions" and names them: "excluded - already carries a different application" or "excluded - no candidate service still Pending". If the promotion is refused, for example because the name is already in use, the banner shows the reason and the dialog stays open so you can correct the name and select Promote again.

If the grid itself fails to load, the banner says "This grid did not load. Nothing here reflects the state of your estate", with the reason. Reload the page; if it persists, check the Event Log.

Filters

The grid remembers its Search: text, column filters, sort order and page size between visits. If the grid shows fewer rows than you expect, clear the Search: box and the filter row.

How to

Run application inference in the right order

Each stage needs the one before it. Work in this order:

1. On this page, select Run inference. It produces the candidate services, and lists unknown addresses on Unknown Hosts.
2. Select Run grouping. The candidate services are grouped into candidate applications.
3. Review each flagged group: split it, or remove the hosts that do not belong (see below).
4. Promote each confirmed group to an application.
5. Select Run inference again. Device suggestions and app-to-app suggestions are worked out against confirmed applications, so a run made before promotion finds few or none. App-to-app suggestions need at least two promoted applications.
6. Review Device Suggestions and Suggested App-to-App.

After you change Port / App Mapping, Flow Exclusions, Utility Hosts or Evidence Sources, run inference and grouping again: saving a row on those screens does not start a run.

Group candidate services into applications

1. Go to Discover → Application Inference → Candidate Applications.
2. Select Run inference. Inference reads the evidence from the integrations and produces the candidate services, device suggestions and app-to-app suggestions. Wait for the result banner.
3. Select Run grouping. Read the result banner: it says how many groups were proposed and how many need review. The grid reloads with the groups.

Run inference is the starting point for every Application Inference queue. Device Suggestions, Suggested App-to-App and Unknown Hosts are filled by it, not by their own pages. The same run is offered as Run App Inference on the NetFlow page, which reports it as a flow and relationship summary instead.

Remove a host that does not belong

1. In the grid, find a group whose Seam Summary shows Check members.
2. Select the Includes a host that may not belong - review the members row action. The Review members of dialog lists each host that may not belong.
3. Select Remove next to each host that is not part of the application. A host that only calls into the application is usually a client of it, not part of it. Each removal is confirmed with a message such as "host removed from this group."
4. When the dialog says nothing out of place is left, promote the group as a single application.

You can also remove any member from the Members of dialog with Remove from this group. If a removal reports that the finding could not be rechecked, select Run grouping again to settle it. Do not treat that as an all-clear.

Review a flagged group

1. In the grid, find a group whose Seam Summary shows Review split.
2. Select View members to see the hosts and their Flags, then Close.
3. Select the Looks like more than one application - review the split row action. The Review split of dialog opens and works out the proposed split.
4. Read Proposed applications and Calls crossing between them.
5. If the members are separate applications, select Split into separate applications. Splitting creates one candidate group per proposed application, and the banner reports how many. Name and promote each one. Once both sides are promoted, the crossing calls become an app-to-app dependency.
6. If it really is one application, select It's one application, or use the close icon. Neither records a decision: the group is unchanged and keeps its Review split flag. Promote it as-is, accepting the warning in the promote dialog.

If the dialog listed Hosts that may not belong to either side, the split keeps them with the larger side. Remove them from that group afterwards with View members and Remove from this group.

Promote a group to an application

1. In the grid, select Promote to application on the group's row, or Promote this group in the Members of dialog. The Promote Group to Application dialog opens.
2. If the dialog warns that the group may be more than one application or may include hosts that do not belong, select Cancel and resolve it with Review split or Check members first.
3. In Application name, replace the suggested name with the real business application name. Promotion cannot be undone.
4. Select Promote, or Cancel to close the dialog without promoting.
5. Read the result banner. If it says "with exclusions", the named devices were not mapped to the new application.

Promotion writes one Application record to the CMDB and a runs-on relationship for each member it maps. A member that already belongs to a different application is skipped.

Run inference again after promoting

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

1. Promote the candidate applications you have confirmed. App-to-app suggestions need at least two.
2. Select Run inference again.
3. Review the new rows on Device Suggestions and Suggested App-to-App.

Related pages

• Device Suggestions: devices that talk to a confirmed application.
• Unknown Hosts: flow addresses that match no device, listed by Run inference.
• Suggested App-to-App: dependencies between confirmed applications, which needs at least two promoted applications.
• Utility Hosts: shared infrastructure kept out of grouping.
• Application: the Application records that promotion creates.
• System Settings: the grouping thresholds CandidateGroupingDegreeThreshold and CandidateGroupingSizeThreshold.