After the identity map: what should a stable map be for?

[tt-a1i]

Evidence update — September 12

The recovered experiments help define a narrower claim: an explicit map can classify repository paths and support nested diagram reading. We have not demonstrated that a Locate receipt improves review decisions or reduces human maintenance effort. PR #367 remains a draft; this discussion is not a merge decision.

What we can now reproduce

The first-look recovery preserves 30 original model answers for 15 PRs: 10 main samples and 5 controls, one model and one trial per condition, with experimenter-authored non-blind ground truth. Without Locate, first-three-file precision was 0.767 on the main samples; with Locate it was 0.700. Across all 15, the values were 0.711 and 0.644. The displayed historical metrics reproduce, but complete original prompts and receipt-derived noise labels have not all been recovered. This was not a human-review experiment.

The historical E3 replay reconstructs the original 100 first-parent steps. Nine commits triggered ten scheduled manual ownership edits. The generated replay matches the old JSON byte for byte. This counts edits to a retrospectively authored map; it does not measure the time to design or maintain that map, or prove those edits were minimal.

There is a real provenance difference in the anchor experiment: the recovered script selects 61 anchors from 21 files, while the published report selects 67 from 23. Reusing the report's recorded coordinates and independently reading Git reproduces its full observations, including 21 anchors valid at HEAD. Both selections are retained. The missing source edit that changed the selection has not been recovered. Comparing the percentage of invalidated anchors with the percentage of commits needing map edits is not a same-denominator comparison.

The earlier description of maintenance as “cheap” and “not the binding constraint” was stronger than this evidence supports. E1's older 50-fix classification remains a historical, manually classified sample; it has not been independently repeated in this recovery.

The fixed counterexample replay keeps six original external map/sidecar files and records 75 fixed observations plus six actual CLI runs. Broad exclusions for build directories, images, fixtures or documentation can hide legitimate product inputs. Those presets are archived, not adopted as a definition of product importance. Unclaimed paths must stay visible.

What the draft actually offers

The ownership sidecar attaches authored repository-path globs to component IDs. Locate reports touched, uncovered, ambiguous and excluded paths; it does not infer runtime effects, decide review order or resolve ambiguity for the author. Diagram bundles provide manifest-bound navigation between an overview and child diagrams, with explicit stale-state handling.

These remain distinct from stronger review-assistance claims. Automatic PR comments, map generation, inferred capabilities and merge gates are not being introduced by this recovery.

The original four directions remain hypotheses:

1. PR receipts: does an explicit path classification answer a useful question beyond the title and diff-stat? The recovered model experiment has not established a benefit in choosing the first files to read.
2. Agent orientation: does clearly showing an unclaimed path change a real investigation? A mapped component must not distract from an important uncovered migration or other product file.
3. Capability comparison: would maintainers author meaningful capability rows themselves? A few historical sibling-component fixes motivate the question but do not establish demand or justify inference from code.
4. Map maintenance: how much effort does initial authorship and subsequent repair take on a real repository? The E3 edit count alone cannot answer this.

Useful feedback would be a concrete PR or repository, the files a maintainer actually needed to inspect, and what the map or receipt added or obscured. No further model or human study is scheduled here.