---
title: "Catalog and Ledger Alignment"
description: "Understand how shared entities connect to workspace claims."
canonical: https://y2.dev/docs/ontology/explanation/catalog-alignment/
---

Ontology & Fusion

# Catalog and Ledger Alignment

Understand how shared entities connect to workspace claims.

Y2's catalog and ledger serve different purposes.

| Property     | Shared catalog                                   | Workspace ledger                                 |
| ------------ | ------------------------------------------------ | ------------------------------------------------ |
| Content      | Entities, identifiers, and relationships         | Sourced claims about research subjects           |
| Contributors | Y2 collection and research processes             | Workspace analysts and integrations              |
| Identity     | Resolved with identifier and name checks         | A shared string never merges subjects            |
| Changes      | Updated records, with reversible merge redirects | New records preserve each correction             |
| Assessment   | Relationship confidence                          | Claim confidence and evidence-based verification |
| Visibility   | Shared across Y2                                 | Workspace access                                 |

The catalog supports search, graphs, and shared context. The ledger preserves the evidence and history of workspace research.

## Anchors connect them

An **anchor** links a ledger subject to a catalog entity. It is not an identity claim or a merge. Two subjects can share one anchor. When catalog entities merge, their anchors follow the surviving entity.

| Catalog kind                                                               | Ledger class               |
| -------------------------------------------------------------------------- | -------------------------- |
| `person`                                                                   | `person`                   |
| `organization`, `vendor`                                                   | `organization`             |
| `threat_actor`                                                             | `organization` or `person` |
| `software`, `api_service`, `ai_model`                                      | `system`                   |
| `cve`, `malware_family`, `indicator`                                       | Not anchored               |
| `country`, `region`, `facility`, `vessel`, `aircraft`, `asset`, `protocol` | Not anchored               |

Threat-actor assessment remains in the catalog. Vulnerabilities, adversary behavior, places, and tracked assets are outside the ledger's passive-research subject classes.

## Relations map where the meaning matches

| Catalog relation                        | Ledger predicate            | Fusion use                |
| --------------------------------------- | --------------------------- | ------------------------- |
| `supplies`                              | `supplies`                  | Supplier or customer path |
| `subsidiary_of`                         | `subsidiary-of`             | Parent or subsidiary path |
| `operates`                              | `operates`                  | Operated-system path      |
| `part_of`                               | `affiliated-with`           | No exposure path          |
| `affects`, `targets`, `uses`            | No direct predicate mapping | Cyber exposure context    |
| `ally_of`, `adversary_of`, `located_in` | No direct mapping           | No exposure path          |
| `references`                            | No direct mapping           | No exposure path          |

## Catalog identifiers are candidates, not claims

A catalog identifier can help locate evidence. It does not supply the retrieval, excerpt, and verification state needed for a ledger claim. Y2 does not copy those identifiers into the ledger as claims.

A combined CIK-or-ticker field does not establish either identifier type. A ledger designator needs the namespace supported by its filing or exchange source.

## Why keep them separate

A shared catalog connects collected records for search and analysis. A workspace ledger preserves disagreements, uncertain identities, and earlier assessments. Anchors let fusion use both without replacing either layer's identity rules.