Originally I thought you meant to scan a database of corners-only to aid in the search for solutions where corners were unsolved in the original cube. I think I understand what you really meant now. So, what you do is, generate face moves only from the cube from a solved position, store the corner orientations along with how far they are from the solved position, and these are like "roadmaps" to your distance from being solved. Is that correct?Corners will help prune the *search* a lot. You spend most of the time
in any standard IDA* search right at the outer limits of your pruning table.
Your search tree includes many move sequences that disturb the corners.
Let's say you are eight moves into a search, with a target depth of 15,
and the table says you are eight moves away from a corner solution. You
know then that you can prune your search immediately and backtrack.
No need to consider any further subnodes.
I would think at some point, you would duplicate a configuration, even though you are a different distance from the solution.
Or did someone already map every corner config possible to a "turns-from-solved" number?