The default answer to "where should this data live" is whichever system you opened first. In a program that has to report on people years after they stop appearing in daily operations, that default gets expensive.
The line I have settled on is this. The CRM holds the operational record: who is enrolled, where they were placed, who supervised them, what is true right now. It is the system people work in, and its job is to stay correct, not to stay comprehensive. Analytical history lives outside it: survey responses across waves, scored measures, anything whose value is in comparison across time rather than in today's transaction. The visualization layer reads from a governed published source, never from the operational tables directly.
Three things follow from that split.
Scored results come back into the CRM as a small number of summary records, not as raw response data. Program staff need to see an outcome next to a person. They do not need the instrument, and putting it there turns the CRM into an archive nobody maintains.
The analytical store, not the CRM, is where cross-wave joins and comparability logic happen. Trying to do that inside a CRM's query language means discovering, one limitation at a time, that it was not built for it.
And the published data source is the boundary object. It is the thing that gets governed, versioned, and republished. Every view downstream inherits its definitions, which is the point.
The cost of this split is a moving part that would not otherwise exist, and a pipeline that someone has to keep running. The cost of not splitting is that every longitudinal question becomes a manual reconstruction from spreadsheets.