Task: Settle the owner of the DQ-only models

Every ores.dq artefact model is the owner of its data, or has moved to its owner.

• Each of the nine has a recorded owner decision.
• The models whose owner is elsewhere have moved, and their DQ stacks are deleted.

1. Decide each of the nine by the rule the DQ guide states: the owning model is the model of the entity the artefact stages, in the component that owns the published rows. The artefact type row settles it. A terminal row – its target_table and target_subject both null – means the staging table is the entity's only store, so DQ owns the model and it stays. A row that publishes onward means the rows are the publishing component's data in transit, and the staging shape moves to that component's model.
2. For each model that moves, set the artefact hook on the owning model and write an * Artefact columns section read off the current artefact table, so the regenerated table keeps every column, type, nullability, default and index. Carry the DQ model's * Artefact indexes over.
3. Put the report configuration binding through the same move. Its artefact type is not its own – the report_definitions dataset stages the bindings beside the definitions – but ores.reporting.report_configuration owns the rows once published.
4. Model the hand-written lei_bic table in ores.dq, beside the two GLEIF models it belongs to, then delete the hand-written create and drop scripts.
5. Delete each moved model with its DQ API, core, shell and TypeScript stack, and the registrar wiring, shell command, recipe and read permission that only it used.
6. Follow each renamed staging table through the publish functions, artefact types, drop scripts, populates, pgTAP tests and the ORE sample dataset.
7. Regenerate, build, and run the local gate and the codegen suite.

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.

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.

Each of the nine has a recorded owner decision, and the three that moved took their staging shape with them.

Six of the nine stayed in ores.dq. badge_definition, badge_severity, code_domain and coding_scheme stayed because DQ owns those registries and they are not staging. lei_entity and lei_relationship stayed because their artefact type row is terminal, which makes the staging table the entity's only store, and lei_bic joined them as a model.

Three models moved onto the model that owns their published rows: counterparty_alias onto ores.refdata.counterparty_identifier, netting_set_alias onto ores.refdata.netting_set_identifier, and synthetic_fx_spot_config onto ores.synthetic.fx_spot_generation_config. Each owning model carries the artefact hook, an * Artefact columns section stating the staging shape and the artefact indexes the DQ model carried. Their staging tables are renamed for their owning model – ores_dq_counterparty_identifiers_artefact_tbl, ores_dq_netting_set_identifiers_artefact_tbl and ores_dq_fx_spot_generation_configs_artefact_tbl – and the publish functions, artefact types, drop scripts, populates, pgTAP tests and the ORE sample dataset followed the rename.

The report configuration binding moved the same way, onto ores.reporting.report_configuration, so dq_report_configurations_artefact_create.sql is generated. Its table body is byte-identical to the hand-written file and it gains one index on report_name. The hand-written dq_lei_bic_artefact_create.sql became ores.dq.lei_bic; its table body and all four indexes are byte-identical and the generated insert function differs only in line wrapping. Its drop script and the create script's file name are unchanged.

The three moved models' DQ stacks are deleted: 48 files under ores.dq and 15 under ores.shell, with three shell recipes, the registrar wiring, the shell command registrations, and the three read permissions only those handlers checked. One permission was added, dq::lei_bic:read.

Acceptance: the decisions are recorded above and in the DQ guide, the models whose owner is elsewhere have moved, and the DQ stacks are deleted. The build is clean, the codegen suite passes 1,425 tests, and the non-heavy local gate passes 40 of 40. pgTAP passes all 52 files against a database recreated from this branch, which is the check that exercises the three table renames. ctest is 93 of 93, after the stale ores.ore test this branch also fixes (Notes). One hand-written artefact table is left, ip2country, which is the other task in this story.

The three GLEIF insert functions had no callers; the paperwork clean-up removed the flag that generated them. The DQ messaging reference did not list lei_bic; it does now.