Story: Make the ACME data realistic and isolate the ORE samples

The ACME base bundle holds realistic agreements, netting sets, CSAs and portfolios for each party, and the ore_samples bundle carries only the labelled reference data the sample import needs and lands its imports in a sandbox portfolio tree.

• Agreement number and netting set code are unique per party, and a CSA has its own party.
• The ACME base bundle holds realistic agreements, netting sets, CSAs and portfolios for each party, with ACME datasets, methodology, catalogue and licence.
• The ore_samples bundle holds only the reference data the sample import needs, every item is labelled as ORE sample data, and it installs on every party.
• A sample import creates its portfolio and books inside a sandbox portfolio tree, and the import wizard and web default to that sandbox.
• The sample CSAs keep ORE's terms.

The remainder is carried in Design and seed the reports, configurations and portfolio trees each ACME party runs.

Taken with the product owner on 2026-10-10:

• Two bundles, kept apart. An ACME base bundle and an ore_samples bundle.
• The base bundle comes first. The samples bundle is retargeted after it.
• The samples bundle is the existing ore_samples, retargeted. It is not a new bundle.
• The samples bundle installs on every party. The base bundle follows each party's report definitions.
• All sample imports go to a sandbox portfolio. Their books go into the sandbox tree.
• Agreements, netting sets and CSAs are party-scoped, decided on 2026-10-10. The agreement number and the netting set code are unique per party, and the CSA gets its own party. This is a bilateral contract between one ACME legal entity and one counterparty. It also lets the samples bundle install the same codes on every party. It is the first task, ahead of the two bundle tasks.
• A netting set must belong to a party, under the usual party RLS pattern. Done in the first task. The CSA and the netting set identifier carry the party of their set, kept equal by the writers and not by a pinned key.

Known problems to design around:

• Agreement numbers and netting set codes were unique per tenant. PR #2598 review item 6 records that agreements are unique per tenant while netting sets look their agreement up per party. The first task fixes this. Its open risk is every lookup by number or code that names no party. They were not searched yet.
• The current bundle names real banks. The sample agreements name real banks by LEI. They stay sample data. Their code and description must say so.

Open, to settle in the tasks:

• Which banks each ACME legal entity faces, and which agreement type and governing law each uses.
• The CSA archetypes: variation margin, initial margin, and none. Their currencies, thresholds, minimum transfer amounts, call frequencies and overnight indices, per party.
• The ACME portfolio and book tree, and how the sandbox tree sits beside it.
• Where an imported sample's books land today. The sprint 18 import work added a "pending book". Its current behaviour was not re-read.
• The licence and catalogue for ACME-authored datasets.
• The names and codes that mark an item as sample data.

Evidence read so far: the three netting dataset scripts and their methodology text in ore_sample_netting_dataset_populate.sql and ore_sample_portfolios_dataset_populate.sql, the Sprint 26 task task_ore-sample-netting.org, the acme_demo profile steps, and the investigation of what each report needs. The database was not queried.

• Generating trades and fixings for a relative time horizon. That is the story "Seed a relative-time trade population with the market data it needs". It follows this one, because it builds on the realistic netting and portfolios.
• The backfill-identity party-RLS failure.
• Changing how the ORE import resolves names. This story changes the data it resolves against.