What changed since the last scan?

Each scan tells you what it found different.

One card per scan, and the card leads with the three numbers that matter: what opened, what resolved, and everything else. A scan that resolved eight findings reads as exactly that, before you expand a single row. When one change stands out, the card says which, and says precisely what the number on it means.

The whole window, grouped until you pick.

The same ledger as an aggregate: a window of 7, 30 or 90 days, every change kind counted under its category, and the rows loading when you select a kind. The tree is how a month of changes stays readable, and the counts are how a category you were not thinking about gets your attention: five site setting changes sitting next to a hundred dependency changes is a ratio worth reading in both directions. Filter by severity or table, pin a view you keep returning to, export the selection as CSV.

The three rows shown are column security grants on sim_bankengagement.sim_estimatedvalue and two other columns. Readers of the dependency analysis page have met that first column before: it is the one the worked chain derives from a public form. Here it is again, growing an access grant, which is the two surfaces answering each other: what writes a column, and who was just allowed to read it.

Not just that it changed. What it changed from.

A change row carries the subject, the target, the date detected, and the transition itself: a column security grant arrives as Read=Y, Create=N, Update=N, a privilege scope change as the move it made, Local to Global. The before and after ride on the row because “something changed on this table” starts an investigation, while “this role gained org-wide read on this column on this date” ends one.

Findings open, resolve, and sometimes come back.

A finding is a change like any other: the scan that surfaced it is on the row, the scan after the condition disappeared marks it resolved, and a condition that returns is marked regressed: resolved earlier, currently open again. Resolution is the scan observing the condition gone, not Pathix fixing anything; Pathix is read-only and remediates nothing. What the ledger adds is the history: the finding you cleared in April that reappeared in July is a different conversation than a finding you are seeing for the first time, and only one of those two stories survives in a tool that stores a status instead of a ledger.

Impact is prominence, and the product says so.

Change rows carry a number, and the temptation every tool gives in to is calling that number risk. Pathix labels it on the surface where it appears:

“Impact is the affected node's graph prominence, frozen when the change was detected. It is not a risk ranking.”

Graph prominence answers how central the changed thing is: how much writes it, reads it, sits next to it. A grant on a column half the environment touches deserves earlier eyes than the same grant on a column nothing uses, and that is all the number claims. The security verdict stays where it belongs, on findings with severities, and the two never blend into one score. Frozen at detection matters too: the number records how central the node was when the change landed, so it does not drift as the graph changes around it.

The diff has no opinion about who meant it.

Some of what the ledger records, nobody in your organization did. The platform grants privileges on its own; a solution import moves more than its release notes say; an upgrade widens a role. A diff against the last scan surfaces those exactly as it surfaces your own work, because it compares states rather than intentions. The sample window makes the point on Pathix itself: a product upgrade extended the Pathix Scanner role, and the grant shows up in the ledger like any other, impact number and all. Nothing is exempt, including us.

The backward-looking half of change safety.