Task: Publish the ORE sample netting agreements, sets and CSAs

A provisioned party holds a netting set for every NettingSetId the ORE samples use, each under an ISDA agreement with the bank its counterparty maps onto, with the CSA ORE defines for it and the ORE alias the import resolves.

• DQ artefact types and publish functions for netting agreements, netting sets, CSAs (with eligible currencies) and netting set aliases; the publish resolves the party from the params, counterparties by LEI and sets by code.
• Four ORE datasets with a dedicated methodology, catalogue, subject area, synthetic nature, licence and dependencies, published by a party-scoped bundle in the party provisioning plan.
• After provisioning ACME, all 19 ORE netting set ids resolve to netting sets of the ACME party.
• Build, ctest, pgTAP and the local check set pass.

Follow the counterparty alias pattern: stage in DQ, publish through the generic publish-from-DQ handler, and deliver through a bundle.

• Four DQ staging models, each with the artefact staging only profile: netting_agreement (by number, counterparty by LEI), netting_set (by code, agreement by number), csa (by netting set code, eligible currencies as a comma separated list) and netting_set_alias (by name, set by code).
• Four publish functions. Agreements and sets are party-scoped: the party is the one the publish parameters name, else the tenant's root party, through a shared helper. A set opened under an agreement takes the agreement's counterparty, which the pinned key requires. Every publish only inserts and skips what the tenant holds or cannot resolve.
• The paperwork: the methodology ORE Sample Netting Synthesis, the subject area Netting and Collateral, the ORE catalogue, origin Derived, nature Synthetic, the Modified BSD License of the ORE examples, and the dependency chain GLEIF counterparties, agreements, sets, then CSAs (also on iso.currencies) and aliases.
• The bundle ore_sample_netting is party-scoped. Only the acme_demo profile's provision_party step names it, so production profiles get no demonstration data. The system tenant gets the same data in populate.
• The data: one agreement per bank (ISDA 2002, FBF for the French banks), one set per NettingSetId the sample trades use, ORE's most common CSA terms for each id ORE defines, and the NettingSetId as each set's ORE alias.

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

Inventory of the ORE sample trades: NettingSetId, the CounterParty its trades name, and the trade count. Trades with no NettingSetId (73) are left to the import task.

ORE defines netting sets for CPTY_A (23 variants), CPTY_B (8), CPTY_C (3), CPTY_D, CPTY_A_full, CPTY_B_full, CPTY, Dummy1 and Dummy4. Dummy1 and Dummy4 carry no CSA details.

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

ACME's root party, Acme Corporation Plc, now holds a netting set for every NettingSetId the ORE sample trades use: 19 sets under 8 master agreements with the banks the sample counterparties map onto, the 7 CSAs ORE defines, and the NettingSetId as each set's ORE alias. Each set's counterparty is the one its trades name. The data is four DQ datasets with their own methodology, subject area, licence and dependencies, published per party by the ore_sample_netting bundle, and to the system tenant in populate.