Generators belong to the system tenant and the system party
Table of Contents
1. Summary
A simulated feed stands in for one real-world observation. There is one value for each vendor feed, so every party and every tenant must see the same value. All collections, folders and generators therefore belong to the system tenant and the system party. No generator is party-owned or tenant-owned.
2. Detail
2.1. Ownership
- The system tenant and the system party own all generator rows.
- Row-level security lets every tenant read them and only the system tenant write them.
- A party reads a generator to find out how a simulated value is made. The simulator does not hide itself.
2.2. Who authors
A person with the generator permission in the system tenant authors collections, folders and generators. A tenant administrator has no write path. A tenant that wants different data takes a different provider or a different source.
2.3. Why not party scope
A party-scoped generator would give two parties two values for one vendor instrument. A vendor does not do that. It would also need a binding step between a generator and a party, and the system would then know that the source is simulated.
2.4. How a generator reaches a party
It does not. A generator serves the simulator's universe. The simulator publishes ticks. The service delivers them according to subscriptions and routes. See A party routes to exactly one source for each provider.
3. See also
- Market Data Architecture — the structure note that orders this cluster.
- The simulator is one adapter plus the tools that author its generators — completes: the component that runs the generators.
- A system bundle installs the catalogue and the simulator installs its own universe — completes: how the generators arrive.
- A party routes to exactly one source for each provider — answers: how a party gets simulated data without owning it.