Hmm... Yes, AFAIK there is no way to have Orion save a copy of a config that it considers to not have changed, at least within RTCD. So, if it is writing a config that would mean that it either detected a change, or that its broken and downloading configs where it doesn't consider there to be a change. My guess is that its detecting a change, which could mean that the comparison criteria engine itself is broken in that its not filtering out lines that it should be.
Of course this doesn't address whether or not Orion is writing the configs when it downloads them, which it shouldn't be doing. The only way I can think of checking to see if this is the case, is to turn on AAA command accounting, like I mentioned in a previous message. I went back and checked and there was no indication of whether you tried this or not. If you turn this accounting on, you should be able to see every command that SW issues when it logs into your device. I'd be curious to see if it is doing a command that could be causing the config to get written, and if so, what command that is. ie: is it doing a "Write Memory" from the "SaveConfig" command name in the template, or is it doing another command that is somehow causing a config to be written.
I'm guessing you don't have anything configured on the ASA that could be causing this? Like any Cisco Call Home commands, event monitor actions, expect scripting, or I think you can even do kron jobs? There are no other monitoring systems that could be causing this? Some of this might be exposed by AAA command accounting also.
At this point I'd recommend turning on command accounting so you can really see what is going on, what Orion is actually doing on a command-by-command basis. It might reveal something that might give us an answer, or better ammunition to contact support with.