46 lines
2.5 KiB
Markdown
46 lines
2.5 KiB
Markdown
# Cross-client system identity and registry method
|
|
|
|
Apply this after canonical client dossiers contain structured system rows.
|
|
|
|
## Observation first
|
|
|
|
Treat each client/system row as an observation, not automatically as a globally unique system. Preserve:
|
|
|
|
- exact observed label;
|
|
- client ID and exact client name;
|
|
- relationship and plain-language meaning;
|
|
- contractor/company with bounded role;
|
|
- direct evidence and confidence;
|
|
- canonical dossier path.
|
|
|
|
A generated registry must be traceable back to every observation and must not become a second editable evidence store.
|
|
|
|
## Identity decisions
|
|
|
|
Use conservative tiers:
|
|
|
|
1. **Exact normalized named identity** — case/whitespace/dash/Markdown differences may aggregate when the label is clearly a named product, domain, acronym, or shared service.
|
|
2. **Reviewed alias identity** — merge variant labels only when an official source, unmistakable product identity, or explicit maintained rule proves equivalence.
|
|
3. **Client-scoped generic identity** — identical phrases such as official website, institution portal, virtual exhibition, or public-service site remain separate per client.
|
|
4. **Composite/ambiguous identity** — labels joining multiple systems remain separate until research can split them without losing the stated client relationship.
|
|
|
|
Normalization is a matching aid, not evidence. Never use fuzzy similarity alone to merge records. Preserve observed labels as aliases and explain the registry classification.
|
|
|
|
## Stable generated dossiers
|
|
|
|
- Prefer hash-derived IDs/slugs from the durable identity key rather than alphabetic sequence numbers.
|
|
- Include observed aliases, distinct client count, observation count, confidence distribution, and a client-relationship table.
|
|
- Carry direct evidence through from canonical rows.
|
|
- For legacy rows without separate meaning/contractor columns, label those fields as not separately structured rather than inventing values.
|
|
- Emit machine-readable JSON and validate unique IDs/slugs, observation totals, client references, and one route per unique record.
|
|
|
|
## Continuous research loop
|
|
|
|
During each recurring research batch:
|
|
|
|
1. Improve canonical client rows with exact official system names, purpose, relationship, contractor role, date, evidence, and confidence.
|
|
2. Review new labels against the alias rules.
|
|
3. Record a merge only when equivalence is defensible; otherwise preserve separation.
|
|
4. Regenerate and compare unique-system and observation counts.
|
|
5. Investigate high-frequency ambiguous labels and missing contractors as priority research targets.
|