It’s a good idea in theory, but unfortunately in the world of single-precision floats, even fundamental rules like **AA⁻¹ = I** don’t actually hold. Every CFrame multiplication can add floating point error except in very special cases. Easy to demonstrate, just run something like this:

```
local rng=Random.new() x=0 for i=1,1000000 do local a=CFrame.fromOrientation(rng:NextNumber(),rng:NextNumber(),rng:NextNumber()) if a*a:inverse()==CFrame.new() then x=x+1 end end print(x)
```

On my computer, it holds about 6700 times out of a million, or 0.67% of the time, and that’s a pure rotation matrix. Give that CFrame a translation component like this:

```
local rng=Random.new() x=0 for i=1,1000000 do local a=CFrame.fromOrientation(rng:NextNumber(),rng:NextNumber(),rng:NextNumber()) +Vector3.new(rng:NextNumber(),rng:NextNumber(),rng:NextNumber()) if a*a:inverse()==CFrame.new() then x=x+1 end end print(x)
```

And now it’s ~360 out of a million, or as good as never. This is because if the CFrame is not a pure rotation, its inverse is not just the transpose, so inverting it is yet another source of floating point error (pretty significant this time too).

If minimizing accumulated error is the goal, the best you can do is cache the original location and always move the part from its original location, to where you want it, with a single transform (a single CFrame multiply, no inversions). But even then, a rotation can still cause the issue seen in the OP, because of rounding errors and tiny differences in the coordinates of vertices that *should* be at the same location but actually aren’t to all digits of precision.