Catalog and Ledger Alignment
How Y2's shared entity catalog and your workspace's entity ledger fit together, and why they stay separate
Y2 has two ontology layers with different jobs.
| Shared catalog | Workspace ledger | |
|---|---|---|
| Holds | One entity per real-world thing, with names, aliases, external IDs, and relations | Evidenced claims about subjects your workspace researches |
| Built by | Ingestion pipelines, extraction, and enrichment across Y2 | Analysts and integrations in your workspace |
| Identity | Resolved: records that share a name or alias within a kind resolve to one entity | Never merged on a shared string; same-as stays a hypothesis |
| Changes | Updated in place; merges leave redirects | Append-only; every correction is a new line |
| Grades | A confidence on each relation | A verification state and confidence on each claim, tied to cited observations |
| Visibility | Shared across Y2 | Private to the workspace |
The catalog is a resolved projection that makes search, graphs, and fusion fast. The ledger is the claim store that makes research accountable. Neither replaces the other.
Anchors connect them
A ledger subject can be anchored to a catalog entity. The anchor is an index between the layers:
it is not a claim and not a merge. Two subjects may share one anchor, for example while a same-as
hypothesis is contested. When catalog entities merge, anchors follow the surviving entity.
Anchoring respects each layer's classes:
| Catalog kind | Ledger class |
|---|---|
person | person |
organization, vendor | organization (a vendor is an organization in a market role) |
threat_actor | organization or person; the actor assessment stays in the catalog |
software, api_service, ai_model | system |
cve, malware_family, indicator | Not anchored: vulnerability and adversary-behavior content stays in the catalog |
country, region, facility, vessel, aircraft, asset, protocol | Not anchored: places, tracked assets, and standards are not passive-research subjects |
Relations map where the meaning matches
| Catalog relation | Ledger predicate | Used by fusion as |
|---|---|---|
supplies | supplies | Supplier or customer path |
subsidiary_of | subsidiary-of | Parent or subsidiary path |
operates | operates | Operated-system path |
part_of | affiliated-with (the catalog tie carries no role) | Not a path |
affects, targets, uses | None: vulnerability and adversary behavior | Cyber exposure events |
ally_of, adversary_of, located_in | None: geopolitical assessments and geography | Not a path |
references | None: a document reference | Not a path |
Catalog identifiers are candidates, not claims
The catalog may already hold a company's Wikidata ID, ASN, website, and social profiles. Those are
useful starting points, but they arrive without the retrieval, excerpt, and verification state a
ledger claim needs, so Y2 never copies them into the ledger as claims. Record them yourself with the
page that supports them. The catalog's combined CIK-or-ticker field is never guessed into either
namespace: record a sec-cik or a ticker designator from the filing or exchange page.
Why keep them separate
Resolving identity in the catalog is the right trade-off for a shared index of well-known organizations, CVEs, and places: it keeps graphs connected and search fast. The same rule is the wrong one for research about people and less-known parties, where two records that share a name are often two different people. Keeping the ledger separate lets each layer use the identity rule that fits its job, while anchors let fusion read both.