Safety means no undefined behavaior. It does not mean free of bugs, or security issues, or free from crashes. It simply means every operation has well specified semantics.
Typically you would start with [0] and it's derivations for specific domains.
The core idea is "The fundamental concept is that any safety-related system must work correctly or fail in a predictable (safe) way."
The interesting question is what to do in corner cases you did not specify explicitly. Typically it is still considered "safe" if you don't do what you would have specified in hindsight, but fall into the defined failure reaction. You also try to make security problems take that path.
Checking that the system does what is specified is called "verification" and the domain of functional safety. Checkin that this is what you actually meant (it actually solves the user's problem) is called "validation" and especially for vehicles called SOTIF [1].
The point being made here is that you can be infinitely specific and still run into unexpected failures. If you're going to claim there is a way out of that you are either very young of just straight up lying.
We're talking about Erlang here which, to my knowledge, is the only mainstream-ish general-purpose programming language that was developed to solve an actual business problem. To be that guy that quotes a relatively well-known quip that maybe you've already heard, the unofficial tagline was: "Remember in the 90s when your phone company would call you up and say that you can't use your phone for a few hours for 'planned maintenance'? Of course you don't... and that's tanks to Erlang."
That was accomplished because you can just specify the happy path, deal with well-known exceptions (are they really "exceptional" at this point?), and otherwise just turn it off and on again, as we all do. And, not to start a flame war, but it's a dynamically typed language to boot!