Let’s bring this thread back to life. I want to share something it might be helpful, or it might not but hopefully someone will find the key.
Puzzle Keys Are Random. They’re made to be unpredictable. No amount of crunchin’ numbers or shufflin’ letters will show you a pattern ‘cause there ain’t one. The only way to crack the puzzle (all together) is to know the master random seed. Good luck with that. It could be up to 30 characters long.
A=1, B=2, etc. Is Made Up. That letter-to-number thing you’re usin’? Total guesswork. The puzzle maker never said nothin’ about it, and unless they straight-up confirmed it, you’re just chasin’ your own tail. You’re tryna force a pattern where there ain’t one.
AI Can’t Beat Randomness. Any AI "predictin’" missing values (like sayin’ Y=4) is just catchin’ lucky breaks in tiny samples. Try it on a bigger batch or different keys, and it’ll flop. Random means no steady trios or trends. Just pure chaos.
The "69" puzzle key got found early ‘cause brute-forcin’ a small range is all about luck and odds.
Swappin’ the first few digits (like turnin’ 6 into 4) might seem like a win in your tiny sample, but stats don’t lie. Every possible key’s got the same shot.
The only real ways to solve these puzzles? Brute-force it (check keys one by one or jump around) or get stupid lucky. Even that "first 25%" guess is just a shot in the dark. The key could be anywhere in the range.
Good luck, but don’t overcomplicate randomness

You forgot to mention the even/odd inverse function. The problem is still open.
Yo, you're on the right track with that batch point addition logic from JLP, especially how you're mixing in batch processing like Cyclone does. But here’s the thing. You need a compressed (even/odd) database. Or, if you wanna keep it light, whip up a database that only takes up 8 bytes. Kinda like that slick public key database from @Mcdouglas-X3. That’ll speed things up big time, givin’ you enough bandwidth to hit at least 90 bits.