Entity Aliases

Entity Aliases

Definition

Client-owned alias-to-canonical mapping table (e.g. “Microsoft Corp” → “Microsoft”). Empty by default. Sanctioned provenance values are generic (platform-recommended acronym rows) and client (tenant-added); core was never sanctioned, and the 14 provenance='core' rows the platform shipped were removed under id-433 (DR-140).

Per DR-140 (S545), a deterministic alias map is not the mechanism that decides two names are one thing — entity resolution (resolve_entities) is. The alias table is a curation store for client-supplied mappings, not part of the canonicalisation path.

Current state (post id-433)

• The platform ships no seed rows and there is no core seed file (core_seed_path is null by design; the previously referenced scripts/seed/baseline-entity-aliases.sql never existed).
• No platform code reads the table. The former readers — lib/entities/entity-aliases.ts, Stage-5’s alias preload, and the pipeline’s alias-cache priming — were removed by id-433.
• The table is retained as the ratified client-provenance store. Whether client aliases should feed the resolver (as pins/inputs) is a question for the id-434/id-435 resolution lane; whether the table survives at all is open to the route/app-surface review (id-441).

Relationships

• Columns: id, alias, canonical (free text, no FK), provenance, is_active. The category → provenance rename has shipped (the pre-rename state some earlier revisions of this page describe is historical).
• No declared FKs; no canonical entities table exists.
• Adjacent to entity_mentions (Layer 4) and entity_relationships (Layer 5), which are distinct CVs.

Consumers

None at present. Future: admin UI for client-defined aliases (v1.1 per Q-OQR1-13), and potentially the resolution lane (id-434/id-435) if client aliases become resolver inputs.

Notes

• Drift incident (S545/S552): Platform staging drifted undeclared from prod and seed.sql — one core row mutated (ISO Certification → iso 27001 vs → ISO 27001) plus one added client row (ISO 27001 → iso 27001). The table has no updated_at column, so the mutation was untimestamped. Resolved by the id-433 row disposition; adding updated_at was judged not worth a migration while the table’s survival is open.