I think I've finally put my finger on the button(s)(quite a few apparently) that may explain my project.  It's helping me to clarify my vision anyhow, so just play along okay?

I'm not building a game simulation....  I've been trying to use that term because it's what everybody else uses, and it really just doesn't fit my project at all.

There is no single starting point and there is no single ending point.  The story elements are to be primarily interaction based and not strictly tied to highly specific locations or circumstances.  The visual synchronicity of the experience is only dependent on entity proximity, which in effect makes it more of a relativistic kind of synchronicity than the absolute kind anyhow. 

All gaming entities(players,npcs,mobs,bosses..etc) will be autonomous actors in the gaming environment, regardless of what controls it.  e.g. Each NPC will essentially be their own entirely isolated behavioral code(running on a server OR client node somewhere).  This code will generate a game entity that is just as actualized in the environment as any other object or player character, it will just behave according to its "script".  All in real-time, with client controlled physics.

So, I'm building a "Multiple Entity Gaming Environment".... It's a working title..   In essence, instead of streaming data that has been aligned to a unified simulation out to many many clients, I'm streaming data about many many ongoing semi-synchronous real-time "INTERACTIONS" from game clients into a massive, fast, circular buffer.  From which, the servers shall draw conclusions and route corrective actions to multiple endpoints simultaneously, and hopefully in many cases, preemptively.

When we're worrying about things in a game becoming out of sync, it's usually in relation to some kind of fast motion or relative positioning, a gun-shot or a left hook, something that is moving/has moved/will move and the event needs to have the same outcome on multiple gaming clients.  Users in most games with this kind of action, don't generally care if their team-mate was .5 meters closer to them then they looked like they were when they helped shoot down the boss.  They only care that the shots they saw coming from that team-mates gun were hitting the mark that the team-mate was aiming at, which was hopefully the boss, if the team-mate is any good.

This may be something of a contrived example, but it more or less illustrates my point.  As long as the servers can provide the appropriate real-time adjustments to certain aspects of the entity interactions to make the synchronicity fall into a zone of acceptability, then nearly all the heavy lifting can be done by the client without running every client input into and back out of a tightly wound server controlled simulation. 

Then, how do we control anything?  The major change here is how Authority is implemented, in a standard server-simulation, the policy is trust nobody.  Here, it is trust everybody, but also verify and cross-check everything.  In this paradigm the authority is purely corrective in nature, with designs on preemptive corrective abilities(where applicable), but primarily relying on minuscule corrective actions that steer the simulation variances into a zone of acceptability. Another fairly extensive level of control comes from the decoupled nature of the system.  Since all entities are autonomous components, they can each be turned on or off at will.  So, that pretty much gives us all the control, never heard of before.  Each entity can be rewritten, debugged, uploaded and instantiated into the game.  Without a single system restart, or change to the game code(goals, I got em).   

So, since we aren't wasting all of our server horsepower on a massive interactive simulation, we can use it to play cop, crossing-guard, mail-carrier and chauffeur all at once.

We can implement heavy-handed position and relative distance checking into the entity data feeds that are being streamed INTO the servers, we can correlate those patterns with known good behaviors and known cheat behaviors/known out of bounds behaviors.  We can implement corrective actions that will steer the entities back into synchronous path(s) when necessary.  And we can allow certain entities to become out of sync for longer periods without risking the integrity of any one game-wide "simulation".  Generally speaking, entities that fall too far out of sync can either get dropped like a laggy player, or will be re-instantiated from a node of the network closer to the action, depending on it's level of importance to the current branch of the narrative/network or game conditions.

Haha, well I hope that this rambling mess helps you understand what I'm doing better.  The more I write it down the clearer it becomes to me. 

I started building this beast before I even knew what it was going to look like.