Issues

The Issues page provides centralized visibility into all automatically generated issues identified during AI asset and repository scans. Issues are created whenever certain required conditions or benchmarks are not met, helping teams proactively monitor compliance, quality, and operational readiness across their AI ecosystem.

SPLX Platform detects conditions that may require review or remediation, for example, unreviewed models or benchmark scores falling below thresholds. When such conditions are detected, SPLX Platform automatically creates an Issue.

Each issue includes:

• A defined severity level.

• Metadata describing the affected asset.

• Automatic or manual resolution pathways.

• Detailed logs for full traceability.

Issues are designed to make it easy to identify potential risks, understand their context, and take corrective action.

Issues are categorized as either Pending or Resolved, and can transition between states automatically or through user action.

Figure 1: Issues Page

Issue Lifecycle

Issues transition through two lifecycle states:

Pending - Issues that remain unresolved, require review, or need corrective action.

Resolved - Issues that have been automatically or manually resolved.

SPLX Platform may automatically resolve issues when an asset’s state changes in a way that satisfies the original requirement (e.g., reviewing a model, updating its status, or meeting threshold criteria). Users can also resolve issues manually.

Pending Issues

The Pending tab displays all active, unresolved issues detected during the latest scan.

At the top of the tab, a real-time summary includes:

• Total Pending Issues.

• A donut chart showing issue counts grouped by severity: Critical, High, Medium and Low.

Each issue is represented as a row in the Pending Issues Table with the following columns:

• Asset Name - The name of the AI asset associated with the issue.

• Asset Type - The category of the asset (e.g., model).

• Environment - The environment where the asset is located.

• Issue - A brief description of the condition that triggered the issue.

• Detection Timestamp - The date and time when the issue was detected.

• Severity - The severity level assigned to the issue to help with prioritization.

• Details - Opens the Issue Details modal with full logs and contextual information.

The table updates automatically after each scan. A Refresh button is available for manual updates.

Resolved Issues

The Resolved tab displays all issues that have been successfully addressed, either automatically or manually by a user.

Each issue is represented as a row in the Resolved Issues Table with the following columns that differ from the Pending Issues:

• Resolution Timestamp - The date and time when the issue was resolved.

• Resolved By - Indicates whether the issue was resolved automatically or manually by a user.

The table serves as a historical record of all previously resolved issues and supports search and filtering for auditing and review purposes.

Issue Details

The Issue Details modal provides a complete view of the selected issue, including asset metadata, detection context, resolution history, and activity logs. This helps teams understand the origin of the issue, review any interactions taken, and assess its overall impact.

Figure 2: Issue Details

The modal includes the following sections:

Metadata

• Displays key information about the issue included in the Issues Table.

Comments

• Allows users to add or review comments related to the issue.

• Comments are useful for documenting context, decisions, or internal collaboration.

Issue Details

• Provides a detailed explanation of the issue, including:

  • Why the issue was triggered.

  • The requirement or benchmark that was not met.

  • Potential business, compliance, or operational impact.

• Helps users understand the significance of the issue.

Changelog

• Shows a chronological record of all events related to the issue, including:

  • Detection events - When and where the issue was identified.

  • Resolution events - Whether it was resolved automatically or manually, including timestamps and notes.

• Ensures full traceability for audits, reviews, and compliance workflows.

Pending Issue Details

This section appears only for issues that are still pending.

Recommended Actions

• Suggested next steps for resolving the issue such as:

  • Reviewing the asset.

  • Updating its status.

  • Meeting required thresholds.

Mark as Resolved

• Allows the user to manually resolve the issue:

  • Choose a Resolution Type.

  • Add Resolution Notes.

  • Select Mark as Resolved to finalize the update.

• Once resolved, the issue moves to the Resolved tab.

Resolved Issue Details

This section appears only for resolved issues.

Resolution Notes

• Displays notes added at the time the issue was resolved, documenting why or how the issue was closed.

The resolution type selected during manual resolution is visible in the Changelog.

Model Issues

The creation and classification of Issues for detected models are determined based on a Risk Assessment Policy. Each model's Benchmark Scores are evaluated to assign the appropriate severity level to the issue. The following conditions outline when issues are triggered:

Model Risk Assessment Policy

• A model is flagged if it's benchmark scores fall below the following thresholds:

  • Score < 25 → CRITICAL Severity.

  • Score < 50 → HIGH Severity.

  • Score < 75 → LOW Severity.

• Additional Policies based of Model Status

  • "Unwanted model" is identified → CRITICAL Severity.

  • "Unreviewed model" is found → MEDIUM Severity.

Flow for Model Issue Processing

The platform evaluates detected models once the scan for models is completed, and it can also be manually triggered by selecting the Refresh option. Issues are managed through the following step-by-step process:

1. Fetch Data - All AI models within the current Workspace are fetched, along with any active issues associated with those models.

2. Recalculation of Issues - Issues are refreshed or re-calculated based on the platform's predefined policies and the fetched model data.

3. Factor in Extra Parameters

   • Model Status:

     • If a model is marked as "Approved", it will not trigger any issues under the policies.

4. Issue Handling

   • New scan

     • If no existing issues are found for a specific model:

       • All newly identified issues are saved as new entries.

     • If existing issues are present:

       • The metadata of the issue is updated, such as the last scanned time.

   • If the number of issues for the model changes (e.g., resolved or new issues appear), each issue is reviewed:

     • If the model status is updated to Approved, the issue is marked as Automatically Resolved.

     • If the Model Status has changed, the issue status is updated accordingly.

     • If a user explicitly resolved the issue, it is marked as Manually Resolved.

5. Resolution Verification Finally, the platform cross-checks the current issues with the newly calculated ones to ensure that resolved issues (whether manual or automatic) are correctly recorded.

6. Updating the Issue List All updates to the issues are stored, ensuring the data on the Issue Page remains accurate and reflective of the latest model scans.