It also occurs to me that this circles back to the (lack of) biasing a query problem.
So the best case scenario here is that in terms of what I’m doing my final query with, I will have a “real” target transient and a “predicted” target attack that I can feed into the system. So great in that I can query a longer span of time for a better match, but if I equally weigh them, I can end up losing some of the nuance of the “real” input by the limitations of the quantization inherent to having discrete points in the KDTree representing the transient attacks.
A more ideal solution would be to do the process outlined above, but then use the predicted target attack to only bias or influence the query (like 70/30, or 60/40, would have to test to see what works best).