Perspective / Delivery
Why issue tracking belongs inside the operating system
An issue is rarely isolated. It emerges from delivered work, affects people and commitments, passes through validation, and changes what an organization can safely release.
Issue trackers became indispensable because teams needed a durable place to describe problems and coordinate work. But the issue record often remains detached from the business decision, project milestone, release, evidence, and operational consequence around it.
A ticket is part of a larger operating history.
A defect may affect a funded initiative. A quality finding may block a release. A service issue may require evidence, communication, and a change in ownership. When those relationships live in separate systems, the ticket can be closed while the organization remains exposed.
The objective is not a better list of tickets. It is continuity from discovery through resolution and release.
Relay is the issue tracking, quality assurance, and release-management capability within Nova. Its role is to keep defects, decisions, validation, and delivery history connected to Projects, governed evidence in Vault, permission context from Identity, and operational controls from Core as those capabilities develop.
Quality assurance should change the state of work.
Validation is more than a comment stating that something was tested. It should be clear what was evaluated, against which expectation, by whom, with what result, and whether the outcome is sufficient for release. Failed validation should change what can happen next.
This creates an accountable handoff between delivery and release without forcing teams to reconstruct evidence later.
Release management closes the loop.
A release brings together approved scope, resolved issues, quality evidence, operational readiness, and ownership. The release record should explain not only what changed, but why the organization believed it was ready.
Issue tracking belongs inside the operating system because delivery quality is an organizational concern. Connecting it to the rest of the operating context turns the ticket from an isolated task into part of a reviewable outcome.