When a scanner check matches an AppMap, it issues a finding. A finding includes detailed information about the match, indicating such information as:

  • A title and message.
  • AppMap in which the finding was found.
  • The primary and secondary events that are relevant to the finding.


  • ruleId identifier of the rule algorithm.
  • checkId identifier of the check, which a configured instance of a rule.
  • ruleTitle human-friendly title of the rule.
  • message human-friendly message describing the finding.
  • appMapFile relative path to the AppMap file containing the match.
  • event JSON object of the primary event on which the match was found.
  • relatedEvents JSON of other events in the AppMap which are associated with the finding. They can be inspected in the AppMap to better understand the finding.
  • scope JSON of the event which defines the AppMap subtree in which the finding was discovered.
  • hash of the finding which can be used to identify duplicate findings.

Finding hash

A hash of the finding is computed from the finding properties that are most important and characteristic. The hash is used implement a critical feature of AppMap Analysis - de-duplication. De-duplication serves two purposes:

1) A finding may occur many times within a set of AppMaps. As a user, you’re only interested in unique findings, therefore the hash can be used to de-duplicate the findings and present a minimal data set. 2) Findings can be managed and triaged in the AppMap Server UI. For example, a finding can be deferred to prevent that finding from holding up a build or pull request. If the finding occurs again in the future, the hash is used to recognize that the finding has already been found, triaged - therefore the finding is not reported as new, and does not block the build or need to be re-triaged.

Was this page helpful? thumb_up Yes thumb_down No
Thank you for your feedback!