(off the cuff answer) Well the basic acceptance criteria should relate to the research goals, so that the exploration is focussed in some sense.
There is clearly scope for iteration here. If I was assessing an open ended exploratory project, I'd expect to see that a problem space has been defined and that some sort of question has been posed within it. Yes, it might take some time to find out what the question actually is, and the question might be to some extent retrofitted.
Once the question has been defined then you can imagine research subgoals that involve creating the required tooling / infrastructure, collecting test data, running a trial, analysing the outputs, etc. Actual software dev activities should be traced back to one of these research subgoals, or you'd have to question why they are being conducted at all.
> Acceptance criteria are hard to lock down, especially in new projects
In industry research teams it is essential to lock them down at some point and you may not get paid if you don't complete against them (accepting that a negative result might be a valid research outcome). This ability to focus was the hardest thing I had to learn when I transitioned from academic to industry research. Even in an open-ended exploratory academic context, you still do need to prove, as the GP said, that you have in some sense answered a question.
Better to have an answer that is wrong, than something that isn't an answer at all.