Product documentation · Updated 14 October 2026
Change-to-Incident Correlation Ledger
Ranks possible relationships between recent changes and follow-on incidents using transparent timing, component, label and priority evidence. Correlation is not proof of causation.
How it works
The analyzer recognizes change and incident candidates from issue types or labels. It matches incidents to preceding changes inside a 72-hour window. It uses a change's resolved timestamp, otherwise updated, otherwise created timestamp. Shared components and labels increase the score; pairs more than six hours apart require shared evidence. The highest-scoring eligible change is shown for each incident.
Reviewer test procedure
- Use an isolated project. Create a change-type issue or an issue labelled change; add label qm-review-evidence.
- After the change is created, create an incident-type issue or an issue labelled incident with the same qm-review-evidence label. Keep the change's effective timestamp before the incident's creation time and within 72 hours.
- Do not update the unresolved change after creating the incident, because updated time is its fallback effective time.
- Select the project and click Run analysis. Verify the incident row names the candidate change, hours after and shared label evidence.
- Export CSV and compare it to the table.
- Use a separate no-match project or dataset outside the 72-hour window to verify an empty result.
Requirements and installation
A Jira Cloud site, access to the selected project and permission to browse its issues are required. A Jira administrator installs the existing app from its Marketplace listing or the existing private installation link during review. Open Jira → Apps → the product name. Allow the Forge user access prompt if shown. No separate QuantMatrix account or third-party credentials are required.
Usage
- Open the app from Jira Apps.
- Select an accessible project from the dropdown.
- Click Run analysis; selecting a project alone does not run the report.
- Review the metric cards, findings table and Method section.
- Click Export CSV when findings exist. A project with no matching rows correctly leaves export disabled.
Permissions and data handling
The inspected manifest declares read:jira-work. The resolver uses Forge asUser() and respects the current user's Jira access. This implementation reads Jira data and does not edit issues. No remotes or external customer-data egress are declared in the inspected manifest. CSV exports are generated in the user's browser; handle downloaded files according to your organization's policy.
Limits and troubleshooting
The scan reads at most 100 recently updated issues and displays up to 50 finding rows. Results are evidence and heuristics, not autonomous workflow enforcement. If no projects appear, check Jira project access. If an API error appears, record the error, product name and time and contact support without sending credentials or sensitive issue content. An empty findings table is expected when no eligible data exists.
Support
Submit a support request · support@quantmatrixintelligence.com. Include the product name, version, reproduction steps and non-sensitive error details.