Scriptable objects being corrupted

I have a very simple scriptable object:

[Serializable]
public class LocationData {
    public string Name;        
    public float Latitude;
    public float Longitude;
}

[Serializable]
[CreateAssetMenu(menuName = "Regions/Region")]
public class RegionInfo : ScriptableObject {
        public string Name;
        public LocationData[] Locations;
 }

[Serializable]
[CreateAssetMenu(menuName = "Regions/Regions")]
public class Regions : ScriptableObject {
    public RegionInfo[] RegionInfo;
}

I’ve created a single region (UK) and populated it with a single entry. I’ve created the regions array object and populated the 1 element with the UK region. I’ve then dragged that Regions data into a slot in my behaviour class. So far, so good.

My game has two scenes. I run the first scene which uses the region data (it’s read-only, btw, nothing writes to it). It works. I switch manually to the second scene (which doesn’t use the region data), run that, stop it, switch back to the first scene… and now my UK data is corrupt (it’s empty), and if I run the game I get a null reference exception. Any ideas?

ScriptableObjects look a lot like data structs, but they are in fact regular class objects, and as such, shared references must be treated with caution.
If you work with the original scriptableobject reference in unity, in play mode, any changes made to the reference object will be permanently serialized to disk - this does not happen in standalone builds, so be aware, you should copy the original scriptableobject into a new instance at runtime if you wish to avoid this undesirable default behaviour (which I repeat, only happens inside unity editor).
New instances of existing objects are empty - the data from the original is not automatically loaded into new instances, you need to handle that yourself (eg with a copy constructor).
My suspicion is that you are kludging the original (shared) object at some point, overwriting it with an empty copy - I don’t see any code that initializes your arrays, so it’s highly likely that is where the null reference is coming from - console debug information on that error would reveal the execution path that lead to the null ref, making it pretty easy to track down.