Finding
One human-readable statement about the project - the unit every narrative, recommendation, and generated document is rendered from.
Findings are assembled from templates, so the same graph always produces byte-identical text, which is what makes them safe to commit, diff, and assert on in CI. A finding states one thing, names the modules it concerns so the reader can navigate to them, and carries its evidence.
Parameters
Stable kebab-case identifier, e.g. "central-dependency". A public contract like ArchRule.id: it appears in exports and can be suppressed, so it must not change after release.
Section this finding belongs to.
How much attention it deserves. INFO findings are descriptive - most of the narrative is INFO - while WARNING and ERROR mark things worth acting on. A finding never fails a build; that is what ArchRule is for.
One short line, suitable as a heading.
One or two full sentences explaining the finding in plain language.
The measurements behind it, in the order they support the claim.
Module paths this finding concerns, most relevant first, for navigation.
The weakest tier among the finding's inputs - a claim is only as certain as its least certain ingredient.
Set only when provenance is Provenance.INFERRED or Provenance.SUGGESTED.
What to do about it, when there is a defensible answer. Null for purely descriptive findings - inventing an action for every observation is how advice becomes noise.