# Open Accounting–Labor Data Linkage Hub

## Public-Safe Methodology and Validation Protocol

**Version:** 0.1.0  
**Maturity:** Prototype  
**Release date:** 2026-08-21  
**Author:** Hongye Chris Yang

## 1. Purpose and current evidence ceiling

The hub is designed to make two research-data linkage objects inspectable:

1. Lightcast company entity × year ↔ CRSP/Compustat Merged public-firm link history;
2. Lightcast company entity × year ↔ Revelio company entity, with organizational level recorded where available and authorized.

The current public release documents the measurement design, generic code, synthetic examples, error taxonomy, release controls, and validation requirements. It does not contain a production mapping, licensed source rows, proprietary identifiers, an adjudicated production benchmark, or benchmark-supported estimates of precision, recall, coverage, unresolved cases, collisions, or temporal consistency.

The intended U.S. annual scope for 2010–2025 is a design target. It is not a statement of observed released coverage.

## 2. Why this is a research measurement problem

Employer names are not stable corporate identifiers. A source employer can differ from a target firm because of punctuation, legal suffixes, abbreviations, historical names, brands, operating subsidiaries, ultimate parents, mergers, acquisitions, spin-offs, duplicated source entities, and common-name collisions. The economically relevant relationship can also vary by year.

A final merge therefore embeds substantive choices about entity eligibility, organizational level, temporal validity, ambiguity, and unresolved cases. The public contribution is to make those choices explicit, versioned, and evaluable instead of representing the process as an unqualified name match.

## 3. Decision units, candidate rows, and release rows

The research decision, the candidate-audit table, and the accepted-link release are different objects. Version 0.1.0 keeps them separate so that retained alternatives cannot be mistaken for accepted links.

### 3.1 Lightcast ↔ CCM

- **Source:** Lightcast company entity represented by an original employer name and authorized matching fields.
- **Accepted target identity:** a Compustat firm identity keyed by GVKEY. Time-valid CCM security links, including PERMNO where authorized, remain in a separate downstream bridge rather than defining the firm identity.
- **Decision unit:** one source entity × calendar year, with non-overlapping intra-year intervals only when a documented corporate event changes the accepted firm.
- **Candidate-audit row:** one source entity × calendar year × candidate GVKEY.
- **Accepted-release row:** one source entity × validity interval × accepted GVKEY; the GVKEY–PERMNO bridge is a separate time-valid table.
- **Cardinality:** at most one co-valid accepted GVKEY per source decision. Multiple accepted targets are allowed only across non-overlapping event intervals. Multiple source entities may map to the same GVKEY and are diagnosed rather than silently collapsed.

### 3.2 Lightcast ↔ Revelio

- **Source:** Lightcast company entity represented by an original employer name and authorized matching fields.
- **Accepted target identity:** a Revelio company identifier with an explicit target level—operating company, ultimate parent, or another documented level.
- **Decision unit:** one source entity × calendar year, with non-overlapping intra-year intervals only when a documented corporate event changes the accepted company or target level.
- **Candidate-audit row:** one source entity × calendar year × candidate Revelio company, retaining target level and competing alternatives.
- **Accepted-release row:** one source entity × validity interval × accepted Revelio company × target level; unresolved and no-candidate outcomes remain in the separate decision table.
- **Cardinality:** at most one co-valid accepted organizational interpretation per source decision. Non-overlapping event intervals and many-to-one mappings are retained; unresolved co-valid one-to-many cases are not forced to a winner.

## 4. Required record structure

The generic public schema separates source entities, target entities, candidate-audit rows, and final decision rows. A candidate row cannot carry a final decision state. A production adapter should preserve:

- original and normalized names;
- source-controlled identifiers;
- year and target-validity interval;
- authorized hostname or URL and geography fields;
- explicit `match`, `conflict`, or `missing` states for geography and temporal evidence;
- candidate-generation reasons;
- score components rather than only a total score;
- candidate rank and margin over the next candidate;
- explicit target level and a separate parent attribute where applicable;
- a distinct decision record with accepted, rejected, unresolved, or no-candidate status;
- confidence tier, reviewer reason, error category, and accepted-target validity interval;
- release version and input provenance.

The schema deliberately avoids private bucket locations, credentials, signed URLs, and proprietary source-field values.

## 5. Matching stages

### 5.1 Normalization

Create a separate normalized name while retaining the original source string. The reference implementation applies deterministic Unicode normalization, removes combining marks, standardizes case and punctuation, expands the ampersand token, removes a bounded list of common legal suffixes, and collapses whitespace.

Normalization must not silently collapse organizational levels or historical identities. Release-specific rules should be documented and tested.

### 5.2 Candidate generation

Candidate generation precedes scoring. The public demonstration creates a candidate when at least one transparent block is satisfied:

- exact normalized name;
- exact authorized domain;
- minimum token overlap.

A production implementation may add authorized identifiers, geography blocks, historical-name dictionaries, or industry fields. Every candidate retains the reason it entered the set. A no-candidate case is analytically different from a generated candidate that is later rejected.

### 5.3 Exact and deterministic rules

Exact or rule-based acceptance requires explicit evidence. The release-specific rule, fields used, temporal validity, and competing alternatives should remain in the audit record. Coverage is not a sufficient acceptance criterion.

### 5.4 Transparent fuzzy scoring

The reference implementation decomposes an illustrative score into name, domain, country, and temporal components. Country and temporal evidence are tri-state: `match`, `conflict`, or `missing`. Missing evidence receives no positive agreement credit. The demonstration weights and classes are not production thresholds and have not been validated against the private linkage.

A production score should be calibrated and evaluated against adjudicated evidence. A model score is not a label or a final decision, and model output is not ground truth.

### 5.5 Corporate structure

Parent, subsidiary, brand, and operating-company relationships should be recorded rather than erased. The target level must be explicit; the mere presence of a parent identifier does not make a candidate an ultimate-parent match. A parent-level link may be appropriate for one research question and inappropriate for another, so the output preserves target level, alternatives, parent attributes, and adjudication reason.

### 5.6 Temporal consistency

Target validity intervals, historical names, mergers, acquisitions, spin-offs, and adjacent-year continuity should be checked directly. A strong name score does not make a stale link valid.

### 5.7 Manual adjudication and unresolved cases

Review instructions should require a reviewer to examine the candidate set, source and target evidence, organizational level, time, and conflicts. Outcomes should include accepted, rejected, no candidate, and unresolved. An unresolved case is a valid measurement outcome and should not be forced into the nearest candidate to increase match rate.

## 6. Confidence tiers

A production release should define evidence-backed tiers such as:

- **Exact / identifier-supported:** a release-specific deterministic identifier rule satisfies a frozen production contract;
- **Rule-based:** multiple non-fuzzy fields satisfy a documented acceptance rule;
- **Fuzzy accepted after review:** a reviewer accepts a candidate based on documented evidence;
- **Unresolved:** evidence does not distinguish the leading alternatives;
- **No candidate:** candidate generation does not retain a plausible target.

The current prototype does not implement a production identifier rule or assign production cases to these tiers.

## 7. Error taxonomy

The shared taxonomy covers:

- legal-name variation;
- abbreviation and token loss;
- parent-versus-subsidiary mismatch;
- merger, acquisition, and spin-off timing;
- historical name change;
- stale temporal link;
- duplicate source entity;
- common-name collision;
- many-to-one concentration;
- one-to-many ambiguity;
- geography or domain conflict;
- source-field missingness.

Adjudication should record the reason for each false positive, false negative, rejection, and unresolved decision.

## 8. Benchmark architecture

### 8.1 Development / adjudication set

The development set supports rule refinement and error analysis. It cannot provide an out-of-sample reliability estimate when its labels influenced the final rules.

### 8.2 Frozen holdout

The holdout is selected before final tuning, stratified across material confidence and error classes, and evaluated without changing the rules. It is the primary out-of-sample evidence object.

### 8.3 Metrics

A benchmark should report, where the denominator is supported:

- accepted-link precision and false-match rate;
- candidate-generation recall among cases with independently known links;
- top-1 and top-k candidate coverage;
- unresolved and no-candidate rates;
- many-to-one and one-to-many rates;
- temporal consistency and stale-link rate;
- metrics by confidence tier, rule, year, industry, firm size, and material error class when sample support permits.

A partial candidate-recall estimate must not be labeled overall recall.

### 8.4 Maturity gates

**Prototype** applies when source authority, method, or validation evidence is incomplete.

**Public beta** requires at least 150 adjudicated source decisions for the linkage, at least 50 cases frozen before final tuning, representation of material confidence and error classes, and second review for at least 20% of the holdout or a visible single-reviewer limitation. It must publish holdout precision with uncertainty by material tier, unresolved and no-candidate rates on a reconciled denominator, and any candidate-generation recall estimate only on independently known-link cases.

**Validated release** requires at least 300 adjudicated source decisions, at least 100 frozen holdout cases, representation of all material error classes, resolved reviewer disagreements, tier-specific evaluation, versioned checksums, a reproducible evaluation command, and fresh reconciliation of all public metrics. Before the holdout is unblinded, each public reliability claim must also have an intended-use-specific acceptance criterion. The holdout result and its uncertainty must satisfy that criterion, and no material tier or error class may contradict the claimed use without a visible limitation or a less mature label.

These counts and performance conditions are release requirements, not current results. Version 0.1.0 has not set or passed a production acceptance criterion.

## 9. Public and restricted artifacts

### Public-safe release

- methodology and field contract;
- generic reference implementation;
- synthetic examples with reserved identifiers and domains;
- aggregate diagnostics only when supported by released evidence;
- error taxonomy and benchmark definitions;
- version, changelog, citation metadata, license, file sizes, media types, and checksums.

### Restricted by default

- row-level Lightcast or Revelio records;
- private production crosswalks;
- proprietary identifiers or source values without verified redistribution authority;
- credentials, signed private URLs, private storage locations, and internal absolute paths;
- unpublished or coauthor-controlled outputs;
- unsupported reliability or coverage claims.

Possession or private storage of licensed records does not establish public redistribution authority.

## 10. Reproduction workflow

1. Obtain and document licenses for all source data.
2. Map authorized fields into the generic public schema.
3. Freeze the eligible source and target populations and temporal scope.
4. Run deterministic normalization and candidate generation.
5. Preserve candidate reasons, alternatives, and feature components.
6. Apply documented release-specific rules and retain unresolved cases.
7. Construct an adjudicated development set and a separately frozen holdout.
8. Evaluate metrics only on supported denominators.
9. Generate aggregate public outputs and a checksum manifest from an allowlist.
10. Scan the release for restricted fields, private paths, credentials, and non-synthetic row-level records before publication.

## 11. Citation

Yang, Hongye Chris. 2026. *Open Accounting–Labor Data Linkage Hub: Public-Safe Entity-Linkage Methods and Validation Protocol*, version 0.1.0.