World data versus party configuration

The database holds two kinds of data, and each kind has its own scope.

• World data describes the world as it is. Examples are currencies, calendars, index conventions (IBOR and overnight), currency pair conventions and market quotes. A real feed (for example Bloomberg) or the synthetic generator supplies it. Every party that runs against the same world must see the same facts. World data has no party_id.
• Party configuration records how a party models and prices that world. Examples are the run document, pricing engines, curve configurations, today's market, stress tests and instrument conventions (deposit, swap, OIS, FRA, CDS and the rest). Two parties can make different choices. Party configuration has party_id and a restrictive party RLS policy.

The rules:

1. A world table never has party_id.
2. Synthetic data generation writes world data only. It never writes party configuration.
3. The engine input for a run is the world data plus the configuration of the party that runs it. For example, a party's conventions.xml is the world conventions plus the instrument conventions of that party.
4. World data is per tenant for now. The scope of world data is an open question (see below). Party configuration does not depend on the answer.

Open questions for the synthetic data rewrite:

• One world for all tenants. Ideally every tenant sees one consistent world. This needs a scope above the tenant, for example a system world that tenants read.
• A sandbox world. A user who experiments in a sandbox may need synthetic data with a smaller scope, which does not change the official world. The sandbox is a candidate owner of such a world.
• A party override of a world fact. ORE lets a party define its own convention with the id of a world convention (for example its own EUR-EURIBOR-6M). If we need this, the export takes the row of the party first and the world row otherwise, and the conventions check looks in both places. We do not build this now.

Synthetic data generation stayed at tenant level because its correct scope was not clear. It replaces real feeds, which suggests a system property. But the system party must not hold configuration, and all parties must see a consistent world. At the same time, Scope the configuration documents to a party made every configuration document per party. Without a rule, the two pieces of work clash. The conventions show the clash: ORE's conventions.xml mixes world facts (index and currency pair conventions, which the seed takes from QuantLib and which synthetic feeds need) with modelling choices (the instrument conventions that build curves).

The distinction removes the clash. The open questions about scope concern world data only, so the synthetic rewrite can answer them without changes to any party table.

• Story: Model the ORE report configuration as entities — where the configuration documents became per party.
• Story: Add sandboxes and virtual books — the sandbox entity.
• projects/ores.sql/populate/refdata/refdata_ibor_index_conventions_populate.sql and refdata_overnight_index_conventions_populate.sql — world conventions seeded per tenant.
• projects/ores.sql/create/refdata/refdata_publish_from_dq_create.sql — publishes the currency pair conventions.

• Task: Scope the configuration documents to a party