Task: Give the system a legal entity

Table of Contents

This page documents a task in the Populate the ACME books with a realistic trade population — the remaining work story. It captures the goal, current status, acceptance, and any notes or results.

1. Goal

A party can reference a legal entity by LEI. A credit trade states an LEI the tenant can join to a row, and any family that references a legal entity uses the same one.

2. Status

Field Value
State DONE
Parent story Populate the ACME books with a realistic trade population — the remaining work
Now Nothing.
Waiting on Nothing.
Next Nothing.
Last touched 2026-10-29

3. Acceptance

  • Legal entities are readable by a party session, as world data rather than one tenant's private rows.
  • The LEI survives the path from the DQ dataset to what a party reads.
  • A credit population books on the back of it, proved by a provisioning run.

4. Plan

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

5. Measurements

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.

What Value Command Commit
       

6. Notes

7. Test Scenarios

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.

Scenario State Notes
     

8. PRs

PR Title
#4099 [agile] Reconcile the legal entity task with its story row
#4080 [refdata] Regenerate the legal entity so main compiles
#4075 [agile] Write the plan for the flip
#4074 [refdata,dq] Publish the LEI so credit can reference a legal entity

9. Review

Comment summary File Decision Notes
       

10. The measurement, first

  • ores_dq_lei_entities_artefact_tbl holds 38,213 rows, all under the system tenant ffffffff-ffff-ffff-ffff-ffffffffffff.
  • The artefact type is registered, with two target subjects: refdata.v1.ops.publish_lei_parties_from_dq and refdata.v1.ops.publish_lei_counterparties_from_dq.
  • Neither carries the LEI. ores_refdata_counterparties_tbl has a short code, a full name and a party type, and no identifier column at all, so the LEI is lost on the way to anything a party can read.

So the publication machinery exists and publishes the wrong thing for this purpose: a party gets names, and a credit trade needs an identifier.

11. The fork

Two shapes, and the choice decides where a legal entity lives.

A: a legal entity in refdata, published from DQ, as world data. A new domain table for the legal entity with the LEI as its key, a publish operation from the LEI artefact, and a read operation the synthetic service and any screen use. Names, jurisdiction, status and classifications come with it, so a counterparty can later reference it instead of carrying a name. This is the larger change and the one that makes the reference real.

B: publish the LEI artefact into each tenant inside DQ. The rows become the party's own copy and list_lei_entities answers for a party session, with no new entity. Cheaper by far, and it leaves legal entities living in a data-quality artefact rather than in the system's model: a screen cannot show them, and a counterparty still cannot reference one.

Recommendation: A, because the question that started this was what a reference means. B makes the credit population book without making the reference true.

12. Result

Legal entities are a refdata entity of their own, keyed by LEI, and the LEI reaches a party through the DQ publish. Measured on a recreated database: the tenant holds 42,388 legal entities with their LEIs, published from the GLEIF LEI artefact every tenant already receives.

Credit books on the back of it: five routed products, one trade each, every one stating LEI and a real identifier rather than the curve name the ORE import keeps.

13. What the path is

ores_dq_lei_entities_artefact_tbl -> ores_refdata_publish_legal_entities_from_dq_fn -> ores_refdata_legal_entities_tbl (tenant's own copy) -> list_legal_entities -> the synthetic scope -> a credit trade's typed reference.

The publish is registered as a third target of the existing LEI artefact, so it runs wherever the LEI dataset already publishes its parties and counterparties, and the LEI stops being lost on the way.

14. Two defects found by doing it

  • The schema manifests are hand-maintained: refdata_create.sql and dq_create.sql list every file with \ir. A generated table that is not added to them is never created, and the failure appears as a missing relation at publish time rather than as a missing file.
  • legal_name cannot be a natural key. The dataset holds thousands of entities that share a name, so the uniqueness the natural key implied made the publish fail on the first duplicate.

The legal entity landed with #4074 and the LEI publish reads the DQ artefact the tenant already holds: a provisioned tenant carries 42,388 entities, and a credit trade references one by its twenty-character LEI.

The task doc had drifted back to BACKLOG while the story row said DONE, which is why this section is written at the story's close rather than when the work shipped. The state is now DONE in both places.

Emacs 29.3 (Org mode 9.6.15)