[Question] Clarify purpose and interpretation of cross-repo co-change dashboard

[joptimus]

Problem

I am trying to understand the intended purpose of the workspace dashboard's cross-repo co-change page and how users are expected to interpret it.

In a multi-repo workspace, the top results can look like strong file-to-file relationships, but several of the highest-ranked pairs do not appear to have any direct interaction, dependency, import, API contract, or obvious semantic relationship. That makes it hard to tell whether the page is surfacing useful coupling or just correlated commit timing.

Anonymized examples from a 5-repo workspace:

Source	Target	Strength
backend-service/src/notifications.rs	web-api/.github/workflows/deploy.yml	42.3
backend-service/src/domain/manager.rs	web-api/.github/workflows/deploy.yml	42.3
backend-service/src/simulation/runner.rs	web-api/.github/workflows/deploy.yml	42.3
backend-service/src/domain/manager.rs	web-api/src/workers/health-check.worker.js	39.8
marketing-site/src/app/map/useScene.ts	routing-engine/engine/src/spatial.rs	37
desktop-client/.github/workflows/build.yml	web-api/src/sockets/auth.socket.js	35
desktop-client/Assets/Localization/en.json	web-api/src/services/docking.service.js	31.3
desktop-client/Assets/UI/Panels/InventoryPanel.prefab	web-api/src/workers/city.worker.js	29.9
desktop-client/Assets/Localization/de.json	web-api/src/services/docking.service.js	29.4

These examples are anonymized, but the pattern is real: workflow files, localization files, prefab/assets, and unrelated backend/frontend implementation files can rank near the top.

Question

What is this page intended to answer?

• Is it meant to show actual cross-repo technical coupling?
• Is it meant to show same-author work bursts across repos?
• Is it meant as a weak historical hint that still needs manual inspection?
• How should users distinguish meaningful cross-repo coupling from incidental commit-time correlation?

Expected Behavior

If this page is intended to show technical coupling, I would expect high-ranked pairs to have some supporting evidence such as shared API contracts, imports, package dependencies, route/topic usage, generated clients, matching symbols, or linked commits.

If this page is intended to show temporal commit correlation, I would expect the UI copy to make that explicit, and possibly show the supporting evidence:

• frequency / number of matched commit pairs
• authors involved
• time windows / last matching date
• example commits that created the relationship
• whether the relationship is supported by any structural dependency signal

Actual Behavior

The page currently presents these as "Files across repositories that frequently change together - implicit coupling detected from git history" with a "Strength" score. As a user, that reads like a relationship or dependency signal, but the top examples can be unrelated files that happened to change near each other.

The Strength values are also difficult to interpret. Values such as 42.3 look like a normalized confidence or score, but it is not clear what scale they use or what threshold should be considered meaningful.

Possible Improvements

Some ideas, depending on the intended product direction:

• Rename/reframe the page if it is about temporal work patterns rather than technical coupling.
• Aggregate by repo pair first, then drill into file pairs.
• Filter or down-rank noisy files such as workflows, lockfiles, generated files, docs, localization blobs, and binary/asset metadata.
• Show why each row exists, including matched commits and time gaps.
• Separate raw frequency from normalized strength.
• Combine co-change history with structural signals before calling something "coupling".

Mostly I am looking for guidance: what is the intended mental model for this page, and how should users use it without overreading noisy correlations?

[RaghavChamadiya]

Thanks for the detailed writeup. Your read is correct, and the examples are a fair indictment.

Intended mental model (today): the page surfaces temporal, same-author co-commit bursts across repos, that is, files the same author touched in different repos within a 24h window, exponentially decayed by age. It is not technical coupling. There is no structural corroboration (imports, API contracts, package deps, shared symbols) folded into the score, even though we do compute those separately as the contract/package-dep graph edges. So your third framing, "a weak historical hint that still needs manual inspection," is the accurate one, and the current copy ("implicit coupling detected from git history") overstates it.

On strength: it is a raw decay-weighted accumulation (sum of exp(-age_days/180) over matched file-pairs), not a normalized 0-1 confidence. 42.3 has no fixed ceiling, which is the same root cause behind #430. That fix clamped the rendering, but the underlying number still is not user-interpretable.

Why the noise is real, not coincidental: two compounding gaps.

1. Cross-repo co-change runs on raw git log --name-only and (unlike intra-repo) applies no exclusion filtering, so workflows, lockfiles, localization blobs, prefabs/assets, and generated files all participate.
2. We cross-product every file in commit A with every file in commit B with no commit-size normalization. A release/CI commit touching deploy.yml gets paired against everything in the other repo's nearby commit at full weight, which is exactly why one deploy.yml lands at identical strength against several unrelated files.

This is worth fixing, not just documenting. Planned direction:

• Reframe the copy to say plainly this is same-author temporal correlation, not coupling.
• Filter noisy paths (workflows, lockfiles, generated/minified, localization, binary/asset metadata) before pairing.
• Down-weight by commit size (inverse to file count, in the spirit of tf-idf) so large/release commits stop dominating.
• Aggregate by repo-pair first, drill into file pairs, and surface the evidence (authors, matched-commit count, last date; frequency and last-date are already in the model).
• Optionally promote pairs that also have a structural signal (contract/package-dep edge).

I will track the filtering, commit-size normalization, and copy changes here.

[RaghavChamadiya]

Opened #480 with the first part: noise-file filtering (workflows, lockfiles, generated, localization, asset metadata) and commit-size normalization (weight /= sqrt(files_a * files_b)) so large release commits stop dominating. The UI copy reframe and evidence surfacing will follow.