You didn't actually specify the logic of the rung, just the example addresses.
If the first two references are in series it guarantees (assuming that the bit is not referenced as an output anywhere else in the program or by any means of messaging including an HMI) that the bit remains OFF. If the first two are in parallel then (again given the above parenthetical assumptions) the bit should remain ON.
So you have a few things to verify. The logic, the lack of any other output reference (including full word addressing (e.g B3:0)), the lank of any HMI reference and finally the lack of any messaging from another PLC directed toward this bit or word.
I have bits in a program which, I hope, are clear by documentation that they are affected by messaging from another PLC. Without that (someone uploading without the original source) it could be very confusing. I don't know how to resolve that (lack of comments).
Noting your comment about the state of the bit on switching from program to run, the typical behavior of the pre-scan should be that the bit would be evaluated as if the rung were false. The pre-scan should have reset this bit so that, from the start of the first REAL scan up until this rung is executed, the bit would be OFF. But from there on it would be in accordance with the logic. You shouldn't have seen its state except in accord with the logic.
). I would hope that this commonly used method of creating an ALW_OFF bit should make that bit STAY off!... 
