What still belongs to a single node?
An organization, brand, product line, branch or person can be merged or split incorrectly.
02 · DIO for AI and entity data
The same entity. Different systems. Different reconstructions.
DIO brings digital identity work into entity resolution, knowledge graphs, RAG, enterprise data and knowledge products. The current offer is a technical or research pilot and co-development—not finished software.
The technical problem
Identity failure is not confined to a single attribute.
It emerges from the configuration of boundaries, aliases, attributes, relationships, sources and uncertainty. DIO asks whether different systems can use them to build compatible views of the same entity.
Which names refer to the same thing?
Abbreviations, transliterations, historical names and language variants must be connected without erasing meaningful distinctions.
Which value applies—and when?
Conflicts among sources require temporal, contextual and provenance frameworks—not arbitrary preference.
Who created, owns or represents what?
An incorrect edge can alter identity as materially as an incorrect node value.
Where did the claim originate?
Confidence in a reconstruction depends on a source’s traceability, role and currency.
What does the system know, and what is it only inferring?
Uncertainty should be visible and managed; false precision merely moves the error into the next layer.
Diagnostic taxonomy
Reconstruction Failure Modes distinguish what exactly broke down in a reconstruction.
The taxonomy follows MVDIO and organizes individual anomalies into a multi-level system. A single reconstruction may exhibit several failure modes at once.
Which referent is the system reconstructing?
Entity Substitution replaces the referent. Merge Failure merges distinct entities. Split Failure splits one entity across multiple nodes. Entity Omission omits part of a reconstruction even though it was available to the system.
Does the meaning remain coherent?
Semantic Fragmentation preserves the entity’s referential unity, but its representations no longer form a mutually compatible semantic whole.
Does the reconstruction correspond to the correct time?
Temporal Discontinuity breaks the continuity of identity. Temporal Misalignment reconstructs the correct referent in the wrong temporal state.
Does the reconstruction fit the situation?
Contextual Displacement foregrounds an aspect that may be factually supportable yet is inadequate to the particular question, role or environment.
Identity Collapse
Describes an aggregate collapse of reconstruction rather than another item within the taxonomic hierarchy.
Semantic Vulnerability ↔ Semantic Robustness
Expresses a reconstruction’s susceptibility or resilience to a shift in meaning. It sits outside the failure-mode hierarchy.
Taxonomic Note DIO/ODI Reference Vocabulary RAG × DIO mapping HEM × DIO mapping
The DIO perspective
An entity charter instead of a vague instruction to “clean the data.”
A pilot defines which entity the system is resolving, from which representations, through which relationships and at what level of confidence. Only then does it make sense to measure change.
Identification rulesboundaries · aliases
Evidence rulessource · time · role
Relationship rulestype · direction · context
Uncertainty policyconfidence · conflict · abstention
An auditable entity reconstruction
Technical or research pilot
A bounded case, explicit rules and predefined evaluation.
The goal is not to bolt DIO onto every system as another general framework. It is to test whether its operational core improves decisions in one precisely bounded entity problem.
Entity definition
Entity type, boundaries, identities of adjacent nodes, aliases and the conditions under which the system should distinguish or merge records.
Baseline
Current inputs, sources, relationships, rules, conflicts and observed error patterns.
Representation map
The relationship between what is claimed about the entity, where it originates, how it propagates and how the target system interprets it.
Intervention
Adjustment of selected rules, data links, source hierarchy, context or uncertainty handling.
Evaluation
Pre/post comparison, control cases, error analysis, transferability and a decision to repeat or narrow the work.
What can be measured
The metric must match the system’s specific decision.
Metric selection is part of the pilot. Without access to the target environment, no single set of measures can be claimed to suit every application.
Fewer incorrect merges and splits
Precision, recall or a domain-appropriate error matrix over pre-labeled cases.
Fewer conflicts across sources
The share of attributes and relationships with a documented conflict resolution and temporal context.
More conclusions with provenance
The ability to trace a claim to its origin and explain why it received a given weight.
Better downstream decisions
Whether the identity change reduces manual corrections, risk or the time needed for a specific task.
Limits of the current offer
The methodological core exists. The product form is entering evaluation.
The site presents a methodological core and a prepared technical pilot. A dashboard, API and automated monitoring are possible product forms for a setting in which the pilot documents a repeatable problem and stable decision logic.
Pilot and co-development
Problem definition, baseline, entity and evidence model, intervention and evaluation.
Diagnostics and monitoring
Repeatable checks for specific identity failures in a clearly defined environment.
API, integration or licensing
Technical integration of validated rules into the partner’s existing data infrastructure.
A suitable co-development partner
Has data, a problem and an environment where decisions can be observed.
- A specific entity use case and known error cases
- Access to relevant sources and domain experts
- Technical capacity to implement a bounded intervention
- A willingness to share negative and ambiguous results
- Clear terms for data, confidentiality and resulting rights
DIO for AI and entity data
Propose one entity problem where a more accurate decision would matter.
The first discussion should define the system, entity, error pattern, available data, possible intervention and how useful change will be recognized.