Librarian Party & Counterparty Publication Design

Add missing dependencies to lei_dataset_dependency_populate.sql:

The counterparty-depends-on-parties dependency is declared now even though counterparty publication is deferred to Phase 2. This ensures the dependency resolver orders them correctly when both are eventually active.

Add an optional column to ores_dq_dataset_bundle_members_tbl:

ALTER TABLE ores_dq_dataset_bundle_members_tbl
ADD COLUMN optional boolean NOT NULL DEFAULT false;

Mark the following datasets as optional in the base bundle:

All other bundle members remain optional = false (required).

Extend publish_bundle_request to carry:

• opted_in_datasets: list of optional dataset codes the user has enabled
• dataset_params: map of dataset code to JSON params (e.g. {"gleif.lei_parties.small": {"root_lei": "529900T8BM49AURSDO55"}})

The publication service skips optional datasets not present in opted_in_datasets. Required datasets are always published.

publication_service::publish_bundle() changes:

1. After resolving topological sort, partition datasets into required and optional.
2. Required datasets publish unconditionally.
3. Optional datasets publish only if present in opted_in_datasets.
4. For parameterised datasets (those with publication_params_schema on their artefact type), look up params from dataset_params map and pass as p_params to the SQL function.

Transform the publish wizard into a multi-step flow:

Counterparties appear in the optional datasets list but are disabled/greyed out with a tooltip: "Coming soon – requires party-scoped counterparty migration." This previews the future capability without breaking the wizard.

Add party_id column to:

• ores_refdata_counterparties_tbl
• ores_refdata_counterparty_identifiers_tbl
• ores_refdata_counterparty_contact_informations_tbl

ALTER TABLE ores_refdata_counterparties_tbl
ADD COLUMN party_id uuid NOT NULL;

Add soft FK validation for party_id in the insert trigger (must reference a valid active party in the same tenant).

Update counterparty_domain_entity.json (and identifier/contact models) to include the party_id column. Regenerate:

• Domain type (C++ struct)
• Repository (SQL queries include party_id)
• Mapper (wire party_id to/from database)
• Table I/O
• Protocol serialization

lei_counterparties_publish_fn gains a target_party_ids parameter (from p_params). For each target party:

• Insert the full counterparty set with that party's party_id
• Preserve hierarchy via parent_counterparty_id
• Insert counterparty identifiers

The artefact type for lei_counterparties gains a publication_params_schema:

{
  "type": "object",
  "properties": {
    "target_party_ids": {
      "type": "array",
      "items": { "type": "string", "format": "uuid" },
      "description": "Party UUIDs to populate counterparties into",
      "minItems": 1
    }
  },
  "required": ["target_party_ids"]
}

The counterparties step in the publish wizard becomes active:

1. Shows the party tree (just imported from LEI in the previous step, or pre-existing in the tenant).
2. User selects which parties should receive the counterparty set via checkboxes.
3. Selected party UUIDs are passed as target_party_ids parameter.

Once party_id is on counterparties, add the party isolation RLS policy:

CREATE POLICY party_isolation ON ores_refdata_counterparties_tbl
  USING (
    party_id = ANY(current_setting('app.visible_party_ids')::uuid[])
  );

This depends on the broader party-level RLS infrastructure (session variables, with_party() context, login flow changes) which is a separate body of work described in the multi-party architecture document.

LEI counterparty hierarchy (IS_DIRECTLY_CONSOLIDATED_BY) is preserved via parent_counterparty_id. This supports group-level exposure reporting: "what is my exposure to group A?" can be answered by traversing the counterparty tree.

The existing lei_counterparties_publish_fn already resolves and inserts this hierarchy. Phase 2 only adds party_id scoping; the hierarchy logic is unchanged.