So, perhaps you can propose some words to use. I'm for using less common words to give a formal meaning when the common words are already meaningful to the reader or may be used casually within the explanations.

• Behavior, or what the spec is defining in the first place. This really has two depths to it. The running program is defined by its side effects and the order in which they occur. Within the program, language constructs have meaning based on what came before, so behavior can include setting up certain data structures and so on.
• Sometimes the implementor can choose between a few reasonable alternatives, like using signed or unsigned logic, or the length of something.
• The implementor must complete the specification here, and choose something that is well-behaved and repeatable and doesn't interfere with anything else. It's not wrong to do that, but the result is "implementation dependent".
• It's really bad to do that, and doing so may cause the rest of the specification to no longer hold. That's "undefined behavior".
• Containment and correction -- if "really bad" is defined in terms of the spec no longer holding, you can instead define other changes to the system, e.g. a variable is now something else, and then get back on the rails in terms of the specification holding under the modified state.