I’ll try a more intuitive phrasing:
You’ve probably seen a 3D colour cube at some point, like any of these: RGB cube at DuckDuckGo
Since the interpretatons of what to call “pure” red, green or blue are variable, the way the CAT model does it is to keep black where it is, but then draw a new set of 3 axes (one for each of R, G and B), at some angle to the old ones. So you get a slightly rotated cube, and the new (say) green axis is now sticking through the old one at a point that would have somewhat blue-ish green, the new red is shifted towards orange and so forth. If you keep white where it was, you’re rotating the cube around its diagonal axis (the line between black and white).
To make it more complicated:
Depending on how luminance is dealt with (I’ve no idea how the CAT tool does it, or even what the “standard” method would be), the RGB cube isn’t actually a cube but an oblong. That’s because (at equal light intensity) green is perceived as brighter than red, and blue is perceived darker than red. So the blue axis would be shorter then the red, and the green one longer. So if you rotated that thing, you get even more complicated results when working out what the prime colours from the previous RGB space should look like in the new one.
That’s also one motivation to just work in LAB space (which tries to approximate the human experience of colours, not quantities of light), and only convert to anything else RGB for display – but I personally don’t find it intuitive to work in LAB, and also way too easy to get to colours which no monitor can display, and no printer print. Another way to deal with it is to work in LHC (Luminance, hue, chrominance) space, which is a lot more intuitive than LAB, but still not as easy to me as RGB.
I think it will take some time for devs and users to come up with functions and ways of using them which allow users to get what they want, predictably, while getting the science right, too.