9541 – 1459 = 8082

Left hand digit sum = 19. Right = 18. They are 1 apart.

8820 – 0288 = 8532

Both sides now = 18. Now 0 apart and they'll stay there. They are only 0 apart when at 18.

8532 – 2358 = 6174

Both sides = 18

7641 – 1467 = 6174

Both sides = 18

You can play with this a bit and it's consistent. The sum of digits of the left and right hand side consistency get closer to each other iteratively (but not necessarily closer to 18). Eventually they lock in at being equal to each other when their digits sum to 18.

This seems to be one property to look at.

I think there's then a second thing happening. Once the values on both sides have digits that sum to 18 the process from there converges on to 6174.

So first the digits of the two sides to the equation converge to equal the same which always only occurs when the digit sum is 18. The digit sum locks into being at 18 at that point. And then subsequently once the digits are 18 they converge on to 6174.

I would start by working out why digits on each side of the equation converge to summing to 18 on both sides of the equation and never being equal at any other value in this process. It reminds me of https://math.stackexchange.com/questions/99725/every-integer...

Now the next thing I would do is ask why does every number with digits that sum to 18 eventually end up at 6174. 4 digit numbers with digits that sum to 18 is a very limited set so it should be easy to figure out the combinations and why they all reach 6174.

Put those two together and you'd have an answer. (I'm thinking about it now but it really doesn't seem too hard).

> A number of readers emailed to say they had discovered that repeatedly adding up the digits of any of the kernels of Kaprekar's operation always equalled 9 (...) Professor Nishiyama has provided an explanation why this happens: it is because the result of performing Kaprekar's operation on any number is a multiple of 9.

https://plus.maths.org/content/pluschat-15

This is starting to look very similar to "if you repeatedly add all the digits of an integer represented in base 10 representation until you have a single digit, and the result is 3, 6 or 9, then it is divisible by 3". I forgot the exact explanation for that one, but IIRC has to do with the implicit calculation that is embedded in base 10 positional notation, other bases have a different number you can quickly verify the divisibility of this way.

So maybe that (the "implicit calculation in base 10 representation" thing) is one part of the explanation. I mean whatever it is, it feels like a mix of all these operations imposing constraints upon each other and interacting with the recursive feedback loop to result in the convergence as an emergent property.