Good question, @chikoon . The dummy JSON files are meant to serve two related client-server purposes at once:

1. They document the API contract by example: "This is the sort of JSON client-side code  can expect to see." So it gives the client-side coders an idea of data types, key names, etc.

2. They give working data structures that can be directly plugged into client-side code *without* a working server implementation. That way we can see what things look like in the browser before waiting for server-side implementation to finish, or without having access to a real-live external service like Oracle or Bear Facts.

For example, when I changed the My Classes API contract last week, I edited the dummy JSON for my/classes and uncommented this line:
https://github.com/ets-berkeley-edu/calcentral/blob/master/app/assets/javascripts/angular/controllers/widgets/myClassesController.js#L88
and commented the line below. Voila! I could see how my revised feed affected the browser before making any server-side changes.

So what should we do if a single feed returns very different looking things under different conditions, or if it's not at all clear how a feed will communicate a certain condition? We can't put comments or conditional logic in JSON, so the only way to document these things is to create another JSON file.

In the case of "no status available", if a feed without a reg status just had nil values for those keys, we probably wouldn't have bothered making an extra file. But what the server-side delivers is actually pretty counterintuitive. We say nonsense about needing to establish a California residency, for example. So the extra JSON lets client-side devs check that they're handling this goofball structure correctly.