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
9. Review
| Comment summary | File | Decision | Notes |
|---|---|---|---|
10. The measurement, first
ores_dq_lei_entities_artefact_tblholds 38,213 rows, all under the system tenantffffffff-ffff-ffff-ffff-ffffffffffff.- The artefact type is registered, with two target subjects:
refdata.v1.ops.publish_lei_parties_from_dqandrefdata.v1.ops.publish_lei_counterparties_from_dq. - Neither carries the LEI.
ores_refdata_counterparties_tblhas 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.sqlanddq_create.sqllist 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_namecannot 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.