Documentation

Findings and runs

The operations view — what has been identified across your projects, and what generated these results.

Operations aggregates findings and runs across the organisation, rather than per task. Locate it under Operations, along with Findings and Runs views.

Why an aggregate view?

A finding on one task is a minor detail. The same finding across thirty tasks, however, indicates a pattern — and it is within patterns that meaningful decisions arise.

Per-task views answer the question "Is this change acceptable?" The operations view, instead, reveals what is systematically true about our codebase and our configuration.

Findings

Every finding reported across projects, filterable by severity, project and type.

What to look for:

  • Repeated findings. The same issue appearing across multiple tasks either represents genuine technical debt requiring dedicated attention, or a check that does not align with your conventions.
  • Findings that remain unresolved. A category of findings that is consistently accepted or ignored points to a check that no longer serves a useful purpose.
  • Concentration of findings. If one project generates the majority of findings, that is where you should focus your attention.

Runs

Every verification run, complete with its associated checks and results.

A useful pattern to spot here is recurring failures at the same stage across unrelated tasks — this signals a problem with the project configuration rather than the code itself, and simply re-running tasks will not resolve it. See Build and test configuration.

Turning patterns into actionable work

A repeated finding can be turned into a task. This is precisely why we notice it: "This pattern appears in forty files" represents a specific piece of work, not a permanent state of the codebase.

Where a condition requires continuous monitoring rather than manual checking, Sentinel can detect it and initiate remediation work.

Tuning rather than tolerating

If the operations view feels overwhelming, the checks are likely miscalibrated rather than your code being exceptionally problematic.

A check that triggers on most changes merely reflects the nature of your codebase, not actual issues. Either the rule does not match your conventions, or it describes debt you have chosen to accept. In both cases, the check needs to be adjusted — see Quality policies and gates.