Product · Observed Use vs Installed
Five words that keep the numbers honest
Installed, observed used, not observed in the selected window, unattributable, coverage insufficient. The vocabulary is the product — because the easy version of this feature is the one that lies.
The vocabulary
Every asset lands in exactly one of these
Most tools in this space have two states: used and unused. The second one is a guess wearing a fact's clothes. These five are what is left when you remove the guessing.
Installed
Proven from configuration. The strongest claim available from a single machine, and the only one an audit can make on its own.
Observed used
Seen running inside a window with enough coverage to mean something. Evidence, with a confidence attached.
Not observed in the selected window
Did not run while we were watching, and we were watching enough to say that. Still not the same as unused.
Unattributable
Ran, but could not be defensibly connected to a repository, actor, or window. Counted, never quietly dropped.
Coverage insufficient
We do not have enough observed days to say either way. A fact about our data, not about your setup.
Attribution
Every link carries how it was made
A session-to-delivery link without a stated method is an assertion. With one, it is evidence you can check.
High
Exact repository plus branch, HEAD, or commit — or a provider-native stable identifier. The only tier that enters named developer comparisons by default.
Medium
Repository, actor, branch, and a bounded time-window match. Visible in coverage and data-health views, kept out of named comparisons.
Low and unknown
An actor and time heuristic, or no defensible match at all. Reported as what it is rather than rounded up into the total.
How it works
Thirty days, then a comparison worth having
The window exists because the answer needs it. A shorter one produces a faster claim and a worse one.
- 01
Observe
Session-boundary hooks report which assets ran, against which repository, with what coverage — for up to thirty rolling days.
- 02
Classify
Each asset resolves to one of the five states, per developer and per repository, with coverage stated alongside rather than assumed.
- 03
Compare, with the caveats attached
Differences between developers and repositories become visible — carrying their confidence, so a weak signal cannot be read as a strong one.
Coverage
What this will never conclude
These are constraints on the product, not settings you can turn off. They are why the measurement is worth trusting.
No causal claim
The product may show that setup and delivery differ. It will not claim the setup caused the delivery result.
No best setup
No developer or configuration is declared best. The strongest evidence available compares the same developer before and after a change — and even then it reports confidence, not certainty.
No single score
Quality, speed, and cost are not collapsed into one number about a person. There is no leaderboard and no ranking.
Where it stops
No payloads are read. A tool the collectors cannot defensibly match is counted as unattributable rather than guessed into a category.
Related
Each surface feeds the next: what the scan finds becomes a finding, and a finding becomes a reversible change.
FAQs about Observed Use vs Installed
Why will you not say an asset is unused?
Because absence of telemetry is not proof of disuse. It might mean the tool did not run, or that our coverage was too thin to see it, or that the session could not be attributed. Those are different facts with different fixes, and collapsing them into "unused" would make the product convenient and wrong.
When can you say something is unused?
Only when a deterministic configuration fact proves it — not when telemetry is silent. That is a narrow case, and it is the only one.
What does "coverage insufficient" mean?
That we do not have enough observed days to make a claim either way. It is a statement about our data, not about your asset, and the interface renders it in a way that cannot be confused for a finding against the tool.
What is "unattributable"?
Work we saw but cannot defensibly connect to a repository, actor, or window. It is counted and shown rather than hidden, because a number that quietly drops what it could not classify is a number that flatters itself.
How is confidence decided?
High means an exact repository plus branch, HEAD, or commit match, or a provider-native stable identifier. Medium means a bounded repository, actor, branch, and time-window match. Low means an actor and time heuristic only. Unknown means no defensible match. Only high enters named comparisons by default.
Is this a token dashboard?
No. Token and context figures exist here as evidence for security and standardization decisions, and they are labelled as estimates where they are estimated. The product does not lead with spend, and there is no employee score.
See what your fleet is actually running
The scan runs locally and reports in your terminal. No account, no upload.
keeprails scan