> ## Documentation Index > Fetch the complete documentation index at: https://docs-xcor.paloaltonetworks.com/llms.txt > Use this file to discover all available pages before exploring further. # Improve investigation quality > Rate investigation findings and give the agent the context it needs to produce better investigations over time. > [!NOTE] > > This feature isn't available to all Palo Alto Networks Cortex XCOR users and > might not be visible in your app. For information about enabling this feature in your > environment, contact [Cortex XCOR Support](/support.md). [Investigation](/investigate/investigations) quality depends on what the agent can see in your tenant. You can rate its findings to tell Cortex XCOR where it fell short. You can also develop a few configuration and documentation habits to provide more context for the agent to work with in future investigations. > [!WARNING] > > Generative AI features can produce incorrect results, hallucinate data, and deliver > inaccurate analysis. Use generative AI features with care, and independently verify > all information produced by generative AI tools before applying it. > > Certain prompts, data, or other inputs might produce irrelevant content. Don't rely on > generative AI features or responses for any uses that exceed their designed scope. ## Rate an investigation Rate a finished investigation with the Thumbs up icon **Helpful** and Thumbs down icon **Not helpful** controls at the top of the investigation. Selecting either opens a dialog where you can change your rating, add detail in **Additional feedback**, and then click **Submit**. Rate an individual claim the same way. Expand any claim under **Supporting evidence** and use the thumbs controls inside it. Claim-level ratings are more actionable than investigation-level ones, because they identify which specific inference was wrong rather than that the investigation as a whole missed. A rating is recorded once and can't be changed after you submit it. ### What to include A rating alone helps, but adding an explanation to a rating helps far more. The most valuable things to describe are: * What actually happened, in your own words, when the investigation came to the wrong conclusion. This is the single most valuable detail to provide, because it gives Cortex XCOR the correct answer to compare the failed investigation against. * Where it should have looked. Name the service, cluster, or telemetry it missed, or the filter it should have applied. * What was irrelevant. An investigation that buries a correct finding among incorrect ones is worse than a shorter, more focused investigation. * Whether you could verify the claims. If the supporting evidence didn't let you confirm a claim quickly, say so. Ratings don't automatically change the agent's behavior. Cortex XCOR reviews them to identify improvements to the feature that can benefit all users. > [!WARNING] > > For your own safety and the safety of your own users, avoid providing personally > identifiable information in feedback reports. ## Give the agent more context These practices improve investigation quality in your tenant. ### Write resolution notes When you resolve an alert, record what the cause turned out to be and what fixed it. Investigations of later alerts on the same monitor or SLO read those notes, so a note you write once can improve subsequent investigations of the same failure mode. Resolution notes are the most direct way to give the agent knowledge that exists only within your team. Write notes that name the cause in addition to the fix. Terse statements that lack context, such as "restarted the pods," provide nothing reusable to the agent. Compare to a statement such as "connection pool exhausted after the upstream timeout increase, pods restarted to clear it," which tells it where to look first next time. ### Annotate monitors Link [monitors](/investigate/alerts/monitors) to the dashboards and log queries responders actually use for them, with [annotation links](/investigate/alerts/monitors/annotation-links.md). An investigation runs those queries early, which means it starts from the same place an experienced responder would rather than discovering the relevant telemetry on its own. ### Define services Configure [services](/observe/services) and link them to their monitors, SLOs, and key telemetry. Service definitions allow an investigation to resolve which service an alert concerns and identify its upstream and downstream dependencies, which is what makes cross-service correlation possible. ### Send complete telemetry An investigation correlates across [metrics, change events, logs, and traces](/overview/types). Each signal type you send widens what it can establish: * **Change events** are the highest-value addition. Most incidents follow a change, and without deploy and feature-flag [events](/observe/enable-events), an investigation can observe that something broke but not that a deploy preceded it. * **Logs** supply the error text that connects a metric anomaly to a specific failure. * **Traces** establish which service in a request path originated a problem. Consistent naming across signal types matters as much as coverage. When the same service has a different name in metrics, logs, and traces, the agent has to infer the connection, and it sometimes can't. [Derived attributes](/investigate/system-library/attributes-catalog/derived-attributes.md) reconcile those differences without changing your instrumentation. ## Related topics - [Investigate alerts with AI investigations](/investigate/investigations.md) - [Use change events](/observe/enable-events/use-events.md) - [Read an investigation](/investigate/investigations/reports.md) - [Investigate alerts automatically](/investigate/investigations/automatic-investigations.md) - [Respond to incidents](/overview/guides/incident-response.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.