Skip to content

Feat/phase 169 gem state parents - #213

Merged
StephenAbbott merged 2 commits into
mainfrom
feat/phase-169-gem-state-parents
Sep 4, 2026
Merged

Feat/phase 169 gem state parents#213
StephenAbbott merged 2 commits into
mainfrom
feat/phase-169-gem-state-parents

Conversation

@StephenAbbott

Copy link
Copy Markdown
Owner

No description provided.

StephenAbbott and others added 2 commits September 4, 2026 21:03
GEM's ownership entities CSV types every row in BODS vocabulary — 670
`state` rows, 567 `state body` — and the subject was already typed from
it. Parents were not: `_parse_parents` reads only the subject's row,
which names a parent by ID, name and share, so every parent was emitted
as `unknownEntity`. That silently defeated the BODS *representing
state-owned enterprises* requirement, which is met by structure alone:
an SOE's entity statement must connect to one typed `state` or
`stateBody`. Nothing else in the pipeline needed changing — `risk.py`
already keys `STATE_CONTROLLED` off those two types.

`_parse_parents` now carries the parent's own `Entity Type` and country
from its own row in the entities index (`_parent_gem_row` reads the
already-built module index rather than calling `_get_indexes()`: a
parser must not trigger a data download as a side effect), and the
mapper types the stub from it and sets its jurisdiction — BODS: "the
jurisdiction is used to represent the particular state". 1,517 entities
name a state or state body in their own parent column, 347 of them with
an LEI.

Three refusals. A parent with no row of its own stays `unknownEntity`
rather than borrowing a type from the subject. A parent GEM types as a
natural person emits neither node nor edge, as for subjects. And
`controlByLegalFramework`, `formedByStatute` and the
`governmentDepartment`/`stateAgency` subtype — all named in the BODS
guidance — stay absent, because GEM publishes nothing that supports
them and asserting them would invent provenance. The interest is still
`otherInfluenceOrControl` with `beneficialOwnershipOrControl: false`:
GEM parent declarations are corporate structure data, not beneficial
ownership assertions.

Also: GEM lists a group's top entity as its own parent — 5,132 of
20,562 rows in the September 2026 snapshot, PT Pertamina (Persero)
among them — and the mapper was emitting that as a relationship whose
subject and interestedParty are the same statement. An entity owning
itself is meaningless in BODS and draws a self-loop in any BOVS
diagram. Guarded.

`STATE_CONTROLLED` hard-coded "(Wikidata-sourced)" in its summary. With
a second source able to produce the structure that is a misattribution,
so the caveat now names the producing source and its coverage limit —
Wikidata crowd-sourced, GEM energy-sector, EITI SOE by EITI country.
The narrative prompt's presence-only example follows.

Pertamina itself still will not show the Republic of Indonesia: its
parent column self-references, and the government edge lives only in
the relationships CSV, which the mapper does not read. 1,300 entities
have a state owner there (441 with an LEI) and the overlap with the
parent column is 360, so that is a separate, larger change.

10 backend tests.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SkYMcrbNGdxUXPyJ4peoFN
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SkYMcrbNGdxUXPyJ4peoFN
@StephenAbbott StephenAbbott self-assigned this Sep 4, 2026
@StephenAbbott
StephenAbbott merged commit 7645faa into main Sep 4, 2026
12 checks passed
@StephenAbbott
StephenAbbott deleted the feat/phase-169-gem-state-parents branch September 4, 2026 21:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant