# Business Problem: Currently, when a deployment is deleted from the cluster, and a violation related to that deployment is triggered, the alert displays the following error: There was an error fetching the deployment details. This deployment may no longer exist. Deployment with id 'xyz' does not exist: not found

This error message indicates that the deployment has been removed, but it lacks critical information about the deployment, such as the pod name, namespace, and other relevant details. This makes it difficult to reproduce or investigate the violation, as key context is missing. For an attacker, this is an easy way to blur traces.

1. Use Cases:

In our opinion, a violation without associated metadata or context at the time of detection is useless because it is not traceable. Attackers can easily cover their tracks, which is highly questionable with an enterprise runtime security solution.

1. Key Functionality:

Modify the ACS system to store relevant deployment details (e.g., pod name, namespace, labels, container image etc.) at the time the violation is detected.
This information should be retained and included in the violation alert, regardless of whether the deployment still exists in the cluster.

1. Benefits:

Violations are understandable. For example, we know which container image was used to cause a violation.

1. Acceptance criteria:

All deployment details of a violation are recorded and persisted at the time of the violation. They are not changed, when the deployment is changed subsequently.

      6. User Experience: [Provide suggestions for designing the UI to optimize usability. Highlight other relevant aspects of the user experience ]
Same UI as today.