What IKAG’s first capability does, and won’t do
Seven offline requests to IKAG’s first capability, in early access: what it answers, what it leaves unknown, and why a shared name never joins two records.
Overview
Seven offline requests to IKAG’s first capability, in early access: what it answers, what it leaves unknown, and why a shared name never joins two records.
Key points
- IKAG’s first capability, company legal identity, answers who a company legally is from the GLEIF and SEC EDGAR registries, with Wikidata as supporting evidence. IKAG is opening to early users and data partners first.
- Given an identifier, it returns each value with the record that states it. Given only a name, it lists the matching entities and picks none.
- It joins an LEI and an SEC CIK only when a primary record names both. Apple’s two records do not link each other, so it keeps them apart; the SPDR S&P 500 ETF Trust’s LEI record names its CIK, so those are joined.
- Anything the records do not establish, such as a company’s status in an SEC record, comes back as unknown with the reason.
IKAG’s first capability is deliberately narrow. Given a company, it answers who that company legally is: its registered name, its identifiers, where it is incorporated, its status, its registered address and its latest SEC filing, each tied to the record that states it. It draws on two primary registries, GLEIF (the global register of Legal Entity Identifiers) and SEC EDGAR, with Wikidata as supporting evidence.
IKAG is opening to early users and data partners first. Everything below comes from IKAG’s own implementation, run offline on public records captured on 7 October 2026 (GLEIF and Wikidata) and 29 August 2026 (SEC EDGAR). The developer page shows the raw output.
Seven requests, and what came back
| Asked with | What IKAG returned |
|---|---|
| Apple’s SEC CIK and Wikidata item | Apple Inc., incorporated in California, from the SEC record; Wikidata agrees on the name |
| Apple’s SEC CIK only | The same, without Wikidata’s agreement |
| Apple’s LEI only | Name, place, active status and registered address from GLEIF, last updated 3 March 2026 |
| Apple’s LEI and SEC CIK together | No identity: no primary record names both, so they were not joined |
| Apple’s Wikidata item only | No identity: community data cannot establish one alone |
| A fund’s LEI only | SPDR S&P 500 ETF Trust, a New York fund, active, with its SEC CIK linked by GLEIF itself |
| A fund’s name only | Three matching entities, one inactive; none chosen |
A name is never enough
Ask for “SPDR S&P 500 ETF Trust” by name and the LEI register returns three entities whose names match: the trust itself in New York, a Massachusetts fund with a similar name that is now inactive, and a Delaware trust whose name contains the same words. A tool that picked the first match would usually be right, and sometimes badly wrong. IKAG returns the three candidates and leaves the choice to the person or agent who asked, with an identifier.
A shared name does not join two records
Apple has an LEI, HWUPKR0MPOU8FGXBT394, and an SEC identifier, CIK 0000320193. Both records name Apple Inc. in California. But the LEI record gives a California registration number and names no SEC CIK, and the SEC record lists no LEI. Wikidata claims both identifiers belong to Apple, but Wikidata is community-edited.
So when both identifiers are given together, IKAG does not merge them on the strength of a shared name. It reports the identity as unresolved, with the reason “insufficient evidence”. That is less convenient than a confident merge, and it is the honest answer from these records.
When a record does link them
The SPDR S&P 500 ETF Trust is different. Its LEI record, 549300NZAMSJ8FXPQQ63, is registered with SEC EDGAR itself, under CIK 0000884394, and GLEIF has validated that registration. A primary record names both identifiers, so IKAG joins them as one entity, and says the link came from GLEIF.
Unknown is an answer
The SEC record says where Apple is incorporated, but not whether the company is active, and it states no official website. GLEIF holds no filings. So, depending on which identifiers you ask with, some fields come back as unknown, each with a reason such as “not observed” or “insufficient evidence”. IKAG never fills a gap with a plausible guess.
Dates come from the source
A fact is only as fresh as the source says it is. GLEIF dates each record: Apple’s was last updated on 3 March 2026, however recently IKAG fetched it. The SEC’s company facts carry no such date, so IKAG never calls them current, even straight after fetching them. The latest filing it reports, a Form 4 accepted on 27 August 2026, is the latest in the record it read, not a promise that nothing newer exists.
How you reach it
IKAG is opening to early users and data partners first. It is reached through the Model Context Protocol, a REST API and TypeScript and Python SDKs, and this site lists each one as it opens.
You can inspect the raw output.
Questions
Can I use this capability today?
IKAG is opening to early users and data partners first, and the early-access list is how you get a place.
Why not match companies by name?
Names are not unique and change over time. A name search in the global LEI register for “SPDR S&P 500 ETF Trust” returns three entities. Choosing one silently would be a guess.
Is Wikidata a reliable source?
It is useful supporting evidence and a good way to find identifiers, but anyone can edit it. IKAG uses it to corroborate values and suggest links, never to prove a legal identity on its own.
Sources
Share this article