Skip to main content
A project with 400 findings is not necessarily worse than one with 40. It may simply be larger. Quality Signals answer a different question from the health score. Rather than “how good is this code”, they answer “what should be addressed first”, by ranking the recurring problems in a scan by density rather than raw count. They are not a second score. Code Health remains the only headline number.

​
Each signal keeps its real units

Converting everything into a single abstract figure would obscure what is actually happening, so nothing is normalised away:

​
Why density rather than totals

Count-based signals are normalised per 1,000 lines of code before ranking. Without that step a large repository would always rank worse than a small one purely on size, which tells you nothing useful. The Present, Elevated and High labels describe that density. They are not a grade. Type debt is omitted entirely on projects containing no TypeScript or JavaScript, rather than displayed as zero.

​
Using the panel

Expand Quality Signals in the Workspace or Folder view for the ranked list, then select a signal to open the findings behind it. From the terminal, iris check <directory> prints the top three with their real values. Single-file checks do not print them, since one file does not constitute a distribution.

​
There is no Quality Signals gate

Quality Signals cannot fail a build. Enforcement uses explicit named limits instead: gateMaxDuplicateBlocks, gateMaxSecuritySmells, gateMaxSuppressions and gateMaxNamingViolations. This is deliberate. When a gate fails it should name the specific standard that was exceeded and by how much, rather than reporting that a blended metric moved. A composite score gives no indication of what to change.