Findings answer questions area by area. Insights look across the whole project for the things no single question surfaces.
What it looks for
- Contradiction. Two documents that cannot both be true — an architecture diagram showing a service the deployment runbook does not mention, a headcount in the management presentation that the organization chart does not support.
- Claim against evidence. Something asserted in a pitch or management document and not supported anywhere in the material. This is the most common insight, and usually the most valuable one.
- Document against code. Where source-code analysis is in scope, what the documents describe measured against what the repository extract shows: a documented test suite that barely exists, a dependency policy nothing follows, a service owner who has not committed in a year.
- Silence in a pattern. An area where every adjacent question is answered and one is conspicuously not.
How to read an insight
Each one names both sides and cites both. The output is a question for the target rather than an accusation: management documents often disagree with the runbook because the runbook is out of date, not because anybody is being misleading. The insight tells you where to ask.
Configuring it
Settings → Insights controls which insight types run and how strict the matching is. Loosening the threshold surfaces more candidates and more noise; tightening does the reverse. Start strict.
Availability
Insights are part of the plans that include diligence insights, and appear per project once there is enough material for a cross-check to be meaningful.