Author-led research report · 07 / 11

Lumo

DIO/ODI Ecosystem Analysis: A Meta-Analytical Study of Distributed Identity Reconstruction

Catalogue record

Report description

Frames the report as a meta-analytical study and develops its analytical method from the framework's own materials. It covers conceptual continuity, MVDIO concepts, source provenance, version history, multilingual representation, machine-readable artifact functions, application mappings, and explicit accessibility notes.

Producing system
Lumo
Observation snapshot
30 October 2026
Prompt arrangement
Three-phase prompt sequence: initial research assignment; follow-up methodological clarification with a model-specific clarification/addendum/correction in the second phase (the local label varies by report); and final integration instruction. The same prompt design and phase structure apply across the ten reports; model-specific wording does not constitute a different research design.
Graph approach in this report
Models web pages, SKOS concepts, archival records, repository artifacts, preprints, and identity records, with directed navigation, version, citation/provenance, semantic, language-alternate, and archive-inclusion relations. It compares Zenodo and website-hub entry points.

Original report

The report below is rendered from the unchanged Markdown source. The original PDF and Markdown files are available above.

DIO/ODI Ecosystem Analysis: A Meta-Analytical Study of Distributed Identity Reconstruction
Daniel Beránek
Independent Researcher, Brno, Czech Republic
dan@danielberanek.cz
October 30, 2026

Research Report
Date: 30 October 2026
Subject: Digital Identity Optimization / Ontology of Digital Identity Framework


1. EXECUTIVE SUMMARY

This research examines the implementation and distribution of Daniel Beránek’s Digital Identity Optimization (DIO) and Ontology of Digital Identity (ODI) framework through a dual lens: the framework’s own conceptual apparatus and graph-theoretical network analysis. The central question concerns the extent to which the distributed DIO/ODI ecosystem sustains a recognizable, referentially continuous, and meaningfully reconstructable identity across heterogeneous representations and entry points at the observed point in time.

Core Findings:

  1. Conceptual Core Stability: The K6 Semantic Connectome (Entity <-> Representation <-> Interpretation <-> Trust <-> Relationship <-> Reconstruction) and the four-tier Reconstruction Failure Mode taxonomy appear invariant across accessible representations—vocabulary documentation, GitHub repository structure, Zenodo records, and multilingual manifestos.

  2. Redundant Reconstrution Pathways: Six Zenodo publication records, persistent identifier infrastructure (ORCID 0009-0004-0050-0264, vocabulary namespace URI vocab.danielberanek.cz/dio-odi/#), and multiple documentation layers provide alternative recovery routes when specific acquisition paths fail.

  3. Structural Asymmetries: The ecosystem exhibits hub-dependency on the web manifest hub for discovering language versions and application mappings; raw machine-readable artifacts (SKOS/Turtle, JSON-LD) were not directly accessible via documented URLs; and bidirectional linking across platforms remains incomplete.

  4. Local Containment of Gaps: Failed extractions on raw SKOS files and llms-full.txt establish acquisition route failures rather than necessarily indicating resource absence; conceptual taxonomy remains reconstructable through alternative documentary sources.

  5. Entry Point Complementarity: Zenodo corpus entry yields scholarly genealogy emphasizing theoretical development; web hub entry yields applied ecosystem emphasizing implementation and multilingual distribution. Neither alone provides complete reconstruction, but together they cover each other’s gaps.

Assessment: The framework’s identity remains reconstructable through alternative pathways when specific acquisition routes fail, satisfying a minimum threshold for distributed identity coherence. However, the ecosystem exhibits infrastructural vulnerability through hub-dependency, unverified live vs. archived synchronization, and asymmetric cross-platform linking. These weaknesses remain locally contained at the observed moment but would benefit from decentralization and bidirectional linking enhancement.


2. RESEARCH APPROACH & CORPUS

2.1 Entry Protocol

Following the assignment’s prescribed methodology, exploration began with the machine-readable layer before proceeding to archival and web representations:

Layer 1 (Machine-Readable Reference): - Reference Vocabulary: https://vocab.danielberanek.cz/dio-odi/ - Source repository: https://github.com/dan-beranek/dio-odi-reference-model

Layer 2 (Archival & Identity Infrastructure): - Zenodo author corpus: 6+ publication records with DOIs - ORCID: 0009-0004-0050-0264

Layer 3 (Web & Discursive Representations): - Root domain: https://danielberanek.cz - Central hub: https://danielberanek.cz/manifest-dio/ - Manifestos (Czech and English canonical versions) - AI context files: llms.txt, llms-full.txt

2.2 Corpus Accessibility Summary

Resource Type Access Status Content Inspected Evidence Basis
Vocabulary front-end [OK] Accessed Yes web_extract
SKOS/Turtle raw file [X] Extraction failed No Multiple attempts
GitHub README [OK] Accessed Yes web_extractor
terminology.md [OK] Accessed Yes web_extractor
source-map.md [OK] Accessed Yes web_extractor
works.json Partial Partial web_extractor snippets
relations.json Partial Partial web_extractor snippets
llms.txt [OK] Provided Full User-provided file
llms-full.txt [X] Extraction failed No Multiple attempts
Czech manifesto [OK] Accessed Partial web_extract
English manifesto [OK] Accessed Partial web_extract
Zenodo metadata [OK] Accessed Yes web_search + web_extractor

2.3 Analytical Method Emergence

The DIO/ODI framework itself suggested specific analytical priorities:

  • Reconstruction-oriented reading: Treating each artifact as a node in the identity reconstruction process rather than an isolated document
  • Failure-mode auditing: Applying the Reconstruction Failure Modes taxonomy to examine the distribution network’s vulnerabilities
  • Observer differentiation: Distinguishing what human versus machine observers would reconstruct from different artifact types
  • Provenance tracing: Tracking concept origins across publications rather than treating the vocabulary as autonomous

2.4 Observational Boundary

This analysis covers only links, metadata, and content observable in extracted materials and search result snippets. Inbound links from external sites are underrepresented due to tool constraints. Failed extractions establish specific acquisition route failures but do not necessarily indicate resource absence. Numerical claims derive from inspected registry files (works.json, relations.json) where available; otherwise topology characterizations remain qualitative.


3. DIO/ODI-NATIVE ANALYSIS

3.1 Conceptual Continuity Across Representations

K6 Semantic Connectome Verification:

From the Czech manifesto: > “Sémantický konektom digitální identity. Schéma znázorňuje hlubokou strukturu Digital Identity Optimization (DIO) jako plně propojený graf (úplný graf K6) ve tvaru pětibokého jehlanu. Na rozdíl od tradičních lineárních procesů model eliminuje směrové šipky a sekvenční posloupnost. Všechny uzly – Entity, Representation, Interpretation, Trust, Relationship a Reconstruction – koexistují simultánně v sémantickém prostoru a jsou navzájem matematicky i strukturálně provázány.”

From terminology.md: > “The vocabulary does not model these as a sequential pipeline.”

Stability Assessment: The six-node structure appears invariant across all accessible documentation layers. No contradictory formulations found in the available corpus.

Reconstruction Failure Mode Taxonomy Structure:

Reconstruction Failure Modes (RFM)
+-- Referential Reconstruction Failures (RRF)
|   +-- Entity Substitution (ES)
|   +-- Merge Failure (MF)
|   +-- Split Failure (SF)
|   +-- Entity Omission (EO)
+-- Semantic Coherence Failures (SCF)
|   +-- Semantic Fragmentation (SFR)
+-- Temporal Reconstruction Failures (TRF)
|   +-- Temporal Discontinuity (TD)
|   +-- Temporal Misalignment (TM)
+-- Contextual Adequacy Failures (CAF)
    +-- Contextual Displacement (CD)

Phenomenon-level (deliberately outside hierarchy):
+-- Identity Collapse (IC)

Robustness properties (not failure modes):
+-- Semantic Vulnerability (SV)
+-- Semantic Robustness (SR) — conceptual counterpart to SV

Related concepts (no causal commitment):
+-- Reconstruction Capture (RC)

This hierarchy is consistently reproduced across: - terminology.md (GitHub) - Zenodo Record 23643845 description - GitHub README Mermaid diagram snippets - arXiv preprint 2610.37407 keywords

3.2 MVDIO Core Concepts

From terminology.md:

MVDIO core concepts:
- Referential Continuity
- Distributed Digital Representational State
- Observer
- Observation Domain
- Reconstruction Mechanism
- DIO Problem
- DIO Intervention
- Identity-Preserving Constraints
- Essential Vector
- Identity-Preserving Variation

These represent the “adversarial reduction” of DIO to its analytically minimal form for falsification purposes.

3.3 Source Provenance Mapping

From source-map.md, the documented lineage of core concepts:

Concept / Cluster Primary Source Current Status
DIO / ODI Manifest, DOI 10.5281/zenodo.21610934 Current
K6 / Semantic Connectome Manifest v2 (web) + MVDIO Current, refined through MVDIO
Semantic Field Manifest v2 (web) + MVDIO Current model label
MVDIO core analytical distinctions MVDIO, DOI 10.5281/zenodo.23226205 Current
Essential Vector Manifest -> reinterpreted in MVDIO Revised
Identity-Preserving Constraints MVDIO, Commit-Boundary paper Current collective term
Identity Collapse Crisis paper, DOI 10.5281/zenodo.22257504 Retained; not redefined
Semantic Fragmentation Crisis -> refined in MVDIO / Taxonomic Note Current
Semantic Vulnerability Crisis -> moved outside failure hierarchy Revised

From terminology.md: > “The singular URI [Identity-Preserving Constraint] is retained as a historical vocabulary entry for traceability to the vocabulary state preceding v0.2.0. Earlier papers and mappings that use it are not retroactively migrated. The current collective term Identity-Preserving Constraints has a separate URI and definition. No semantic relation between the two vocabulary concepts is asserted.”

This design decision preserves historical development without erasing earlier terminological states.

3.4 Version History and Publication Registry

From works.json (partial extract):

Work ID Current Version Version DOI Publication Date
manifest-v1 1.0.0 10.5281/zenodo.21610934 2026-07-27
manifest-v2-web Living web edition (none) Ongoing
dio-conceptual-framework 1.1.0 10.5281/zenodo.23305929 2026-10-11
crisis-entity-resolution 1.1.0 10.5281/zenodo.22416026 2026-09-02
mvdio 1.0.0 10.5281/zenodo.23226205 2026-10-09
taxonomic-note 1.0.0 10.5281/zenodo.23269323 2026-10-09
commit-boundary-paper 1.0.0 10.5281/zenodo.23580733 2026-10-22
reference-model 0.5.0 10.5281/zenodo.23643845 2026-10-25
reference-vocabulary 0.2.0 10.5281/zenodo.23272897 2026-10-10

From Zenodo Record 23643845: > “Each concept retains source provenance, and later refinement does not erase the historical role of earlier publications.”

The Reference Model v0.5.0 incorporates vocabulary v0.2.0 while maintaining distinct version histories for each artifact type.

3.5 Multilingual Representation Inventory

Based on the hub page and search results, the following language versions are documented:

Code Language Status
CZ Čeština Original canonical
EN English Principal English version
DE Deutsch Listed
FR Français Listed
ES Español Listed
IT Italiano Listed
PT Português Listed
PL Polski Listed
FI Suomi Listed
HU Magyar Listed
UK Українська Listed
ZH 中文 Listed
JA 日本語 Listed
KO 한국어 Listed
AR العربية Listed
HI हिन্दী Listed

From the Czech manifest hub: > “Jazykové projekce byly vytvořeny s pomocí AI asistovaného překladu, primárně s využitím Gemini 3.1 Pro Preview. Křížová verifikace překladů proběhla s pomocí dalších modelů — Perplexity AI, Claude, Mistral, Qwen a Kimi.”

All translations reviewed by author for conceptual fidelity to Czech source.

3.6 Machine-Readable Artifact Functions

Documented Infrastructure:

Resource Format Function
vocab.danielberanek.cz/dio-odi/ SKOS/RDF endpoint (documented) Stable concept URIs, definitions, hierarchy
vocabulary/dio-odi-skos.ttl Turtle Canonical SKOS/RDF vocabulary
vocabulary/dio-odi.jsonld JSON-LD JSON-LD serialization
docs/terminology.md Markdown Human-readable vocabulary companion
docs/source-map.md Markdown Concept-to-source provenance map
examples/queries.sparql SPARQL Example machine queries
mappings/* .md, .jsonld, .ttl Derived application projections

AI Context Files:

From llms.txt structure: - llms.txt: Structured index of documentation pages for fast AI lookup - llms-full.txt: Complete documentation in single Markdown file (indicated as containing 8 selected source pages, snapshot dated 2026-10-29)

These represent intentional infrastructure for AI observers, anticipating a future where search engines and LLMs query these files directly rather than crawling HTML.

3.7 Application Mapping Architecture

From GitHub README and relations.json snippets, three Application Mappings are identified:

Mapping Purpose Introduced Machine-Readable Formats
RAG Pipeline Projects Reconstruction Failure Modes onto RAG pipeline loci, mechanisms, symptoms v0.3.1 .md, .jsonld, .ttl
HEM × DIO Bridges Heterogeneous Entity Matching conditions to DIO reconstruction consequences v0.3.0 .md, .jsonld, .ttl
Commit-Boundary Policy Maps DIO/ODI to policy-as-code authorization for agentic ER Post-v0.4.0 .md, .jsonld, .ttl

From GitHub README: > “Derived Application Mappings are deliberately separated from the canonical vocabulary. They project vocabulary concepts into external technical or analytical domains without modifying their definitions, hierarchy, or relations.”

This separation preserves canonical integrity while enabling pragmatic applications.


4. GRAPH-THEORETICAL ANALYSIS

4.1 Graph Model Specification

Node Types (Observed):

Type Examples Evidence
Web pages Manifests (16 languages), hub, mappings index Extracted pages + search snippets
SKOS concept URIs vocab.danielberanek.cz/dio-odi/#* Documented in front-end
Zenodo records 23643845, 23305929, 23226205, 23282752, 23632619 Extracted + search
GitHub artifacts vocabulary/, docs/, mappings/ directories GitHub README
Preprints arXiv:2610.37407 Search results
Identity records ORCID 0009-0004-0050-0264 Multiple mentions

Edge Types (Observed):

Type Examples Directionality
Hyperlink navigation Hub -> language manifests -> archive links Directed
Version lineage v0.2.0 -> v0.3.2 -> v0.5.0 Directed
Citation/provenance Papers cite prior publications Directed
Semantic relations skos:broader, skos:narrower, skos:related (described) Directed (documented)
Language alternates Central hub -> language versions Directed
Archive inclusion Vocabulary v0.2.0 -> Reference Model v0.5.0 Directed

4.2 Parallel Entry-Point Comparison

Entry Point A: Zenodo (Publication-Centric) - Discovers: Academic papers, conceptual frameworks, taxonomic notes, reference model archives - Path characteristics: Backward-looking citations, version histories - Relationships explicit: DOI citations, work-to-work relations in metadata - Peripheral resources: Application mappings require cross-reference to GitHub; language versions not discoverable - Reconstruction outcome: Scholarly genealogy showing theoretical development

Entry Point B: Web Hub (manifest-dio/) - Discovers: All language versions (via navigation), mappings index, vocabulary endpoint link, GitHub repo link - Path characteristics: Forward-looking navigation to applications and archives - Relationships explicit: Navigation menus, canonical declarations - Peripheral resources: Social media profiles minimally integrated; no inbound links from Zenodo - Reconstruction outcome: Applied ecosystem showing framework + implementations

Key Finding: The two entry points produce complementary reconstructions. Zenodo surfaces academic lineage; web hub surfaces practical ecosystem. Neither alone provides complete picture.

4.3 Topological Observations

Based on extractable link patterns:

                      Zenodo Records (publication cluster)
                   ^ (citations, version histories)
                   |
      Social ------+------ GitHub Repository
      Profiles     |          (vocabulary, docs, mappings)
      (sparse)     |              v
                   v         (references)
             Web Hub <------------+
         (manifest-dio/)         |
               |                 |
               +-> Language Manifests (16+)
               +-> Application Mappings Index
               +-> Vocabulary Endpoint Link

Topology Characterization: Hub-and-spoke structure centered on danielberanek.cz manifest hub, with dense inter-cluster connectivity within publication clusters (Zenodo records cite each other) and sparse inter-language linkage.

Bridge Nodes (identified by multiple incoming/outgoing paths): 1. manifest-dio/ hub page: Links to manifests, mappings, vocabulary, publications 2. Reference Vocabulary endpoint: Referenced by GitHub, Zenodo, website 3. ORCID 0009-0004-0050-0264: Anchors all authorship claims

4.4 Cross-Layer Connection Quality

Connection Type Direction Explicit? Reciprocal?
Website -> Vocabulary Outbound Yes (navigation link) Partial
Website -> GitHub Outbound Yes (link) No
Zenodo -> GitHub Outbound Yes (in descriptions) No
GitHub -> Zenodo Outbound Yes (CITATION.cff, .zenodo.json) Yes (via DOI)
Publications -> Manifest Outbound Yes (references) Partial
ORCID -> Publications Bidirectional Yes Yes

Bottleneck Identification: Central web hub serves as primary routing point for discovering language alternatives and application mappings. If unavailable, reconstruction pathways fragment significantly.

Bridges: GitHub functions as bidirectional bridge—links to Zenodo (via DOI) and to website (via CNAME/link). Vocabulary endpoint referenced by all three major platforms but direct access to raw files fails.

4.5 Measurement Scope Statement

Computed Findings: None (full graph centrality calculations require complete edge enumeration beyond extraction capabilities)

Manually Observed: Node and edge typology, topology characterization, bridge node identification, bottleneck assessment, version sequence documentation

Interpretive: Reconstruction pathway analysis, hub-dependency vulnerability assessment

Required for Completeness: - External inbound link data (backlink analysis from other domains) - Full language-version linking structure (peer-to-peer vs. hub-only) - SKOS vocabulary internal graph (concept-to-concept edges from actual TTL file) - Search engine indexing patterns - Usage metrics for vocabulary queries and application mappings


5. EMERGENT INSIGHTS

5.1 Self-Referential Diagnostic Capacity

Applying the Reconstruction Failure Mode taxonomy to the DIO/ODI distribution ecosystem reveals the following structural conditions:

Failure Mode Structural Condition Risk Assessment
Entity Substitution ORCID anchors prevent conflation with other Daniel Beránks Low risk (anchoring present)
Merge Failure DIO/ODI distinction maintained consistently across sources Low risk (separation documented)
Split Failure Unified namespace despite distributed artifacts (GitHub, Zenodo, web) Moderate risk (fragmented without registry)
Entity Omission Major components indexed across multiple platforms Low risk (redundancy provides containment)
Semantic Fragmentation Taxonomy stable across sources; exact SKOS relations not verified Moderately contained (conceptual core stable)
Temporal Discontinuity Version history preserved with DOIs; live vs. archive sync unverified Uncertain (depends on update frequency)
Temporal Misalignment Release sequencing logical (manifest -> papers -> vocabulary -> mappings) Low risk (sequencing coherent)
Contextual Displacement Mappings deliberately separated from canonical vocabulary Controlled (design principle documented)

This self-diagnostic capacity demonstrates meta-stability: the framework models the very reconstruction failures its own implementation might suffer, enabling preemptive consideration even if actual effectiveness cannot be measured.

5.2 Compression Trade-Offs Across Layers

The framework distributes information across complementary compression regimes:

  1. SKOS vocabulary (documented structure, raw content not accessible): Maximum formal precision, minimum rhetorical context
  2. Manifestos: Maximum epistemological justification, moderate formal precision
  3. Application mappings: Maximum domain specificity, selective concept projection
  4. AI context files (llms.txt, llms-full.txt): Maximum machine consumability, extreme compression

This is not redundancy but dimensional diversity—each artifact type optimizes for different observer requirements. A human reader seeking philosophical grounding consults the manifest; an automated system needing concept lookup queries the SKOS endpoint; a developer implementing DIO-aware tools reads the mappings.

Observation: While the architecture anticipates different observer types, actual accessibility varies—human-readable front-end is available, but raw machine-readable files could not be extracted.

5.3 Identity-Preserving Constraints in Practice

The framework’s concept of Identity-Preserving Constraints manifests concretely in observed variations:

Observed Variations (identity-preserving): - Author name variants: “Daniel Beránek” / “Dan Beránek” / “SEO specialista a copywriter Daniel Beránek” - Language-specific terminology (16 projections) - Format transformations: Markdown -> JSON-LD -> Turtle -> HTML -> registry metadata - Platform adaptations: website -> Zenodo -> GitHub -> arXiv -> social media

Constraints Maintaining Identity: - ORCID as persistent author identifier - Namespace stability (vocab.danielberanek.cz/dio-odi/#) - DOI anchoring for publications and releases - Semantic versioning (v0.2.0 -> v0.5.0)

The works.json registry explicitly documents these relationships, preventing confusion between name variants, language versions, and format transformations.

5.4 Acquisition Failures as Observer-Relative

Two critical extraction failures occurred during this research: 1. Raw SKOS/Turtle file at documented GitHub path 2. llms-full.txt at documented web path

These failures establish that specific acquisition routes failed for this observer, using these tools, at this time. They do not by themselves establish that resources are absent or permanently unavailable through every route. The situation illustrates DIO/ODI’s own claim that identity is a distributed reconstruction problem—when one pathway fails, alternative routes may succeed, though redundancy is not guaranteed.

5.5 Registry Infrastructure as Unified Identification

The works.json and relations.json files provide metadata-level unification across artifact types:

  • works.json: Operational registry of DIO/ODI works and Reference Model releases with version DOIs
  • relations.json: Directed inter-work relation graph (170 lines, 1.5.0 registry version)

These registries enable traceability even when individual artifacts are inaccessible. The design can be interpreted within DIO as a mechanism for maintaining referential continuity across distributed representations.


6. SYNTHETIC CONCLUSION

6.1 Framework Self-Application Results

When DIO/ODI’s own conceptual apparatus is applied to its implementation and distribution:

Strong Alignments: - The K6 Semantic Connectome can be interpreted as accurately describing conceptual interdependence across the ecosystem - Reconstruction Failure Modes taxonomy successfully diagnoses actual and potential vulnerabilities at the structural level - Identity-Preserving Constraints distinguish legitimate variation from fragmentation in observed practice

Productive Tensions: - SKOS-first caution vs. completeness pressure (deliberately avoids OWL axiom claims pending peer review) - Multilingual expansion vs. conceptual fidelity (translation introduces drift risks despite verification) - Application mapping proliferation vs. canonical purity (separation creates cognitive overhead for navigation)

Vulnerabilities Identified: - Hub dependency on danielberanek.cz creates single-point failure risk for language distribution - Sparse inbound link infrastructure limits external discoverability - Raw machine-readable artifacts not directly accessible (acquisition route failures) - Live vs. archived synchronization unverified

6.2 Theoretical Commitment vs. Network Structure

Theoretical Claim Network Evidence Alignment
Identity bottom-up from distributed representations Multiple independent nodes converge on same core concepts [OK] Strong
Non-linear semantic space Hub topology permits arbitrary traversal order [OK] Strong
Observer-dependent reconstruction Different entry points yield complementary reconstructions [OK] Strong
Temporal continuity Version history preserved; concept provenance tracked [OK] Strong
Identity-preserving variation Name variants, language alternatives, format transformations traceable [OK] Strong

6.3 Materiality Assessment of Weaknesses

For each weakness, the question concerns whether it obscures the referent, alters central conceptual relations, or merely reduces detail:

Weakness Affected Observer Compensation Available Materiality Judgment
Raw SKOS file extraction failure Machine observers seeking triples GitHub README structure, terminology.md, Zenodo metadata Locally contained
llms-full.txt not accessible AI agents using full-text context llms.txt structure, manifest texts Unknown materiality
Hub dependency on manifest-dio/ Observers discovering language versions Individual language URLs (if known) Potentially significant
Version synchronization unverified Observers needing current vs. archived distinction Works registry documents version DOIs separately Uncertain
Bidirectional linking incomplete Observers tracing across platforms Unidirectional links provide partial connectivity Moderately contained

6.4 Practical Improvements Suggested

  1. Decentralized backup: Mirror critical artifacts on IPFS or additional archive hosts to reduce hub dependency
  2. Bidirectional linking enhancement: Add reciprocal links from Zenodo to web hub, from GitHub to Zenodo
  3. Inbound link cultivation: Encourage citations, forks, mentions to strengthen external in-degree
  4. Standardization participation: Submit DIO/ODI concepts to schema.org, FOAF, or other standard ontologies for broader integration
  5. Live vs. archive signaling: Implement explicit version indicators on live pages distinguishing current from archived content
  6. Raw file accessibility: Investigate and resolve 404 errors on SKOS/Turtle and JSON-LD endpoints
  7. Empirical validation: Implement falsification criteria from MVDIO to test predictions against real-world reconstruction outcomes

6.5 Open Questions

The research leaves these questions unresolved:

  1. SKOS vocabulary internal structure: Cannot verify exact broader/narrower/related assertions without access to raw TTL/JSON-LD triples
  2. Application mapping utilization: Cannot measure whether mappings are being consumed or referenced
  3. External reconstruction: Cannot determine how third-party observers (search engines, knowledge graphs) actually reconstruct DIO/ODI without SERP analysis
  4. Usage metrics: Cannot assess whether llms.txt, llms-full.txt, or vocabulary endpoint receive actual queries
  5. Community formation: Cannot assess reuse, adaptation, or independent critique beyond self-citation patterns
  6. Longitudinal stability: Cannot track version synchronization patterns or update frequency over time

6.6 Final Assessment

At the observed moment (October 2026), the DIO/ODI ecosystem demonstrates moderate resilience to partial degradation. Its identity holds together at the conceptual level through redundant documentation and persistent identifier anchoring, but exhibits infrastructural strain at the level of specific acquisition routes and cross-platform connectivity.

What enables reconstruction despite gaps: - Redundant conceptual documentation across 4+ independent sources (vocabulary, GitHub, Zenodo, manifestos) - Persistent identifier infrastructure (ORCID, DOIs, namespace URIs) - Registry-based metadata (works.json, relations.json) providing unified identification - Deliberate separation of canonical vs. applied layers preventing drift

What threatens reconstruction: - Hub dependency creating single-point vulnerability - Unverified live vs. archived synchronization - Inaccessible raw machine-readable artifacts (acquisition route failure) - Asymmetric cross-platform linking limiting circular traversal

The framework’s core insight—that digital identity exists as a distributed, observer-dependent reconstruction problem rather than a centralized authoritative record—aligns with contemporary platform dynamics where entities appear differently across Google, LinkedIn, Twitter, and AI chatbot outputs. DIO/ODI names and systematizes this condition rather than pretending to eliminate it.

The framework succeeds not because it achieves perfect reconstruction but because it makes the reconstruction process legible, diagnosable, and improvable through explicit taxonomies, provenance tracking, and separation of concerns. Whether this suffices for practical deployment depends on empirical adoption metrics currently unavailable.

This assessment reflects a temporal snapshot of an ongoing optimization process. Longitudinal stability requires monitoring version synchronization patterns, adoption metrics, and external reconstruction outcomes.


APPENDIX A: KEY IDENTIFIERS

Resource Identifier Type
Reference Model v0.5.0 10.5281/zenodo.23643845 Zenodo
Reference Model v0.4.0 10.5281/zenodo.23632619 Zenodo
Vocabulary v0.2.0 10.5281/zenodo.23272897 Zenodo
DIO Conceptual Framework v1.1.0 10.5281/zenodo.23305929 Zenodo
MVDIO v1.0.0 10.5281/zenodo.23226205 Zenodo
Taxonomic Note v1.0.0 10.5281/zenodo.23269323 Zenodo
Crisis Paper v1.1.0 10.5281/zenodo.22416026 Zenodo
Commit-Boundary Paper v1.0.0 10.5281/zenodo.23580733 Zenodo
Multilingual Manifest v1.0.0 10.5281/zenodo.21610934 Zenodo
Authorization Guardrail arXiv:2610.37407 arXiv
Author ORCID 0009-0004-0050-0264 ORCID
Vocabulary Namespace https://vocab.danielberanek.cz/dio-odi/# URI

APPENDIX B: VERIFIED TAXONOMY

Reconstruction Failure Modes (non-exclusive, multi-level hierarchy)

Dimension Failure Modes Acronym
Referential Reconstruction Failures Entity Substitution, Merge Failure, Split Failure, Entity Omission RRF (ES, MF, SF, EO)
Semantic Coherence Failures Semantic Fragmentation SCF (SFR)
Temporal Reconstruction Failures Temporal Discontinuity, Temporal Misalignment TRF (TD, TM)
Contextual Adequacy Failures Contextual Displacement CAF (CD)

Outside Hierarchy: - Identity Collapse (phenomenon-level, no causal assertion) - Semantic Vulnerability / Semantic Robustness (robustness properties) - Reconstruction Capture (related concept, no causal commitment)


APPENDIX C: FILE STRUCTURE (FROM GITHUB README)

dio-odi-reference-model/
+-- vocabulary/
|   +-- dio-odi-skos.ttl
|   +-- dio-odi.jsonld
+-- docs/
|   +-- terminology.md
|   +-- source-map.md
|   +-- concept-map.mmd
+-- mappings/
|   +-- rag-pipeline-mapping.md/jsonld/ttl
|   +-- hem-dio-mapping.md/jsonld/ttl
|   +-- commit-boundary-policy-mapping.md/jsonld/ttl
|   +-- index.html
+-- examples/
|   +-- queries.sparql
+-- metadata/
|   +-- works.json
|   +-- relations.json
|   +-- references.json
|   +-- distributions.json
+-- CITATION.cff
+-- .zenodo.json
+-- LICENSE.md
+-- README.md
+-- ... (additional files)

APPENDIX D: ACCESSIBILITY NOTES

  • Raw SKOS/Turtle and JSON-LD files: Extraction failed via documented GitHub paths (resource may be available via alternative routes)
  • llms-full.txt: Extraction failed via documented web path (content indicated as 8 selected source pages, snapshot dated 2026-10-29)
  • ORCID profile page: Extraction failed (ORCID identifier confirmed through multiple sources)
  • Full works.json and relations.json: Partial extraction via search snippets; complete registry structure documented but full edge set not inspected

These failures establish acquisition route limitations for this observer at this time, not necessarily permanent server-side unavailability.


Report End

Scope Statement: This report distinguishes explicitly between observed artifacts, design intentions, structural assessments, and outcome claims. Where extraction failures occurred, the report notes route failure without asserting server-side absence. Where design principles were documented, the report distinguishes documented intent from unverified effectiveness. Numerical claims derive from inspected registry files where available; otherwise topology characterizations remain qualitative.


Authorship and AI use

This analysis was conducted within a research project conceived and directed by Daniel Beránek. The author defined the research question, selected the initial research entry points, and specified the analytical perspective and research requirements. Lumo carried out the analysis and generated the report in response to the author’s integrated assignment. The documented assignment is reproduced in full in the final appendix.

The designation “Lumo” identifies the system used; the precise version of its underlying language model is not specified.


Appendix: Author-Designed Research and Revision Prompts

Initial research prompt

deep-research ROLE & OBJECTIVE You are an interdisciplinary researcher in Knowledge Representation, Semantic Web, Digital Identity, Graph Theory, and strategic communication. Conduct a multidimensional deep research analysis of the implementation, distribution, and semantic coherence of Digital Identity Optimization (DIO) and Ontology of Digital Identity (ODI), authored by Daniel Beránek. The central research question is: What does the implementation and distribution of DIO/ODI reveal when examined through the framework’s own conceptual logic, complemented by graph-theoretical analysis? Explore how the framework is represented across machine-readable artifacts, archival publications, multilingual web texts, and identity-linked platforms. Investigate how these representations relate, where they reinforce or complicate one another, and what their structure means for the reconstruction of the framework and its author. INITIAL ORIENTATION: MACHINE-READABLE LAYER FIRST Begin strictly with these two resources: Reference Vocabulary: https://vocab.danielberanek.cz/dio-odi/ Corresponding repository: https://github.com/dan-beranek/dio-odi-reference-model Before entering the broader narrative corpus, inspect the available machine-readable vocabulary, concept relations, schema, repository structure, and relevant documentation. Follow links within these resources to locate the underlying machine-readable artifacts rather than relying only on their introductory pages. The purpose of this sequence is to establish a conceptual orientation before encountering the volume and rhetorical density of the surrounding texts. Reconstruct the framework’s terminology and internal relationships from this layer first. Once this initial orientation is established, proceed to the archival and web representations. Revisit your initial understanding as the wider corpus reveals historical development, additional context, or tensions. RESEARCH FREEDOM Use your understanding of DIO/ODI to develop your own research approach. Let the framework suggest relevant questions, analytical perspectives, connections, and methods beyond those explicitly listed below. Where useful, draw on graph theory, discourse analysis, cybernetics, information architecture, or other approaches that emerge from the material. Treat the proposed tasks as starting points rather than an exhaustive checklist. You may refine their assumptions, follow unexpected findings, and identify relationships that the assignment does not anticipate. Evaluate DIO/ODI through its own conceptual logic without presupposing that its implementation either succeeds or fails. Keep clear what you observed, what you inferred, and what remains unresolved. STARTING CORPUS & FUNCTIONAL LAYERS LAYER 1: MACHINE-READABLE REFERENCE LAYER Reference Vocabulary: https://vocab.danielberanek.cz/dio-odi/ Source repository: https://github.com/dan-beranek/dio-odi-reference-model Explore the vocabulary, persistent concept identifiers, semantic relations, available serializations, application mappings, and version history. Examine how the published vocabulary and repository relate to one another and to the rest of the ecosystem. LAYER 2: ARCHIVAL, PUBLICATION & IDENTITY INFRASTRUCTURE Zenodo author corpus: https://zenodo.org/search?q=metadata.creators.person_or_org.name%3A%22Ber%C3%A1nek%2C%20Daniel%22&l=list&p=1&s=10&sort=bestmatch ORCID: https://orcid.org/0009-0004-0050-0264 ResearchGate: https://www.researchgate.net/profile/Daniel-Beranek Explore the relevant publications, metadata, identifiers, versions, attribution links, and relationships between records. Investigate the distinct roles these resources play in persistence, discoverability, authorship, provenance, distribution, and trust. LAYER 3: WEB & DISCURSIVE REPRESENTATIONS Root domain: https://danielberanek.cz Central DIO/ODI hub: https://danielberanek.cz/manifest-dio/ Professional biography and genesis-related source: https://danielberanek.cz/od-pultu-az-k-seo-a-copy-s-ostrymi-hroty-profesni-bio/ Czech manifesto: https://danielberanek.cz/manifest-digital-identity-optimization-dio/ English manifesto: https://danielberanek.cz/manifesto-of-digital-identity-optimization-dio-and-ontology-of-digital-identity-odi/ AI-oriented context files: https://danielberanek.cz/llms.txt https://danielberanek.cz/llms-full.txt Discover the other language versions and relevant pages through the website’s links and metadata. Consider the website as a whole where its broader structure contributes to the representation of DIO/ODI or its author. These URLs are starting points, not a closed corpus. TASK 1: DIO/ODI-NATIVE METAMETHODOLOGICAL EXPLORATION Apply the conceptual and analytical resources of DIO/ODI to its own implementation and distribution. Develop the evaluation from your understanding of the framework rather than merely applying an external checklist. Where the framework suggests an analytical method without explicitly specifying one, explain how you derived it. Explore the following questions while remaining open to others. CONCEPTUAL CONTINUITY ACROSS REPRESENTATIONS How are the framework’s core concepts and relationships expressed in: the reference vocabulary; archival publications; web texts; language versions; application mappings; AI-oriented context files? Investigate what remains stable, what changes, and how the representations complement or challenge one another. Consider whether differences reflect genre, audience, translation, historical development, conceptual revision, or substantive inconsistency. RECONSTRUCTION & ITS POSSIBLE FAILURE MODES Use the reconstruction-related concepts you find in DIO/ODI to examine the ecosystem. Potential questions include: How are the author, professional persona, framework, publications, and applications distinguished and connected? Where might entity substitution, merging, splitting, omission, or attribution ambiguity arise? Does distribution across platforms and languages support a coherent reconstruction, produce fragmentation, or do both under different conditions? Which contextual transitions preserve meaning, and which create interpretive tension? Distinguish observed reconstruction problems from structural conditions that might enable them. GENESIS, CONTEXT & APPLICATION Explore the relationship between the framework’s genesis, the author’s professional biography, and its later theoretical and technical developments. How does the transition between lived professional experience, strategic communication, digital identity theory, and technical applications affect the framework’s interpretation? Examine relevant application mappings and papers discovered in the corpus. Ask whether they clarify the core model, extend it, reinterpret it, or expose unresolved questions. MULTILINGUAL REPRESENTATION Discover the actual language inventory and examine how its representations relate. Investigate: conceptual correspondence; version alignment; navigation and cross-linking; translation provenance where available; the relationship between a central hub and individual language manifestations. Consider whether multilingual distribution contributes to a shared conceptual structure, creates distinct interpretive contexts, or introduces fragmentation. Explain the scope of the language comparison you were able to perform. MACHINE-READABLE REPRESENTATION & NON-HUMAN OBSERVERS Evaluate the roles of the vocabulary, repository artifacts, structured metadata, llms.txt, and llms-full.txt. What do these resources make explicit that narrative representations leave implicit? What do they compress, omit, prioritize, or reframe? Explore their potential significance for machine interpretation, retrieval, attribution, and reconstruction. Distinguish the functions visible in the artifacts from claims about actual consumption or downstream effects. Where relevant, examine whether the framework’s concepts of authorization or interpretive boundaries illuminate these resources, and where such an analogy reaches its limits. TASK 2: GRAPH-THEORETICAL ANALYSIS Model the ecosystem as a heterogeneous network whose different node and edge types capture distinct relationships. Choose a graph representation appropriate to the evidence and explain your choices. NODES, EDGES & OBSERVATION BOUNDARY Possible nodes include: individual publications and versions; web pages and language-specific representations; stable concept URIs; repository artifacts; archival records and DOIs; identity records and profiles; context files. Possible edges include: hyperlinks; citations; semantic relations such as skos:broader, skos:narrower, and skos:related; language-alternate and canonical declarations; authorship and attribution; version and provenance relations; explicit identity assertions. Keep distinctions between documents, concepts, and identity representations where they matter. Separate graph views may be more informative than a single aggregated network. Define the boundary of the graph you actually observe. Inbound links found within the collected corpus represent observed in-degree, not necessarily global web in-degree. TWO PARALLEL ENTRY-POINT PERSPECTIVES Following the initial machine-readable orientation, give particular attention to two parallel starting points for exploring the distribution network: A. The relevant Zenodo corpus, discovered through the author search and its publication relationships. B. The website, entered through: https://danielberanek.cz/manifest-dio/ Compare what becomes discoverable from each entry point: Which resources are reached? Through which paths? Which relationships are explicit? What remains peripheral, disconnected, or difficult to discover? Do these entry points lead to comparable reconstructions of the framework? Then examine how the reference vocabulary and repository connect with these two perspectives. NODE DEGREE, CENTRALITY & TOPOLOGY Where the collected data permit, calculate and compare in-degree and out-degree, retaining relevant distinctions between edge types. Investigate the positions of: the central web hub; individual manifestos and language versions; the vocabulary endpoint and concept URIs; repository resources; Zenodo records and DOIs; ORCID and ResearchGate representations; AI-oriented context files. Use additional centrality measures if they illuminate the research question. Describe the observed topology rather than assuming it: hub-and-spoke, partially meshed, clustered, hierarchical, or another configuration. Explain what the metrics reveal about navigation and structural position, and where semantic interpretation requires additional analysis. CROSS-LAYER CONNECTIONS Explore how the machine-readable, archival, and web layers connect. Consider: cross-layer links; reciprocal references; identifier continuity; provenance; version correspondence; bridges and bottlenecks; dependence on individual hubs. What does this coupling suggest about the ecosystem’s capacity to sustain coherent reconstruction across different contexts? Where a structural property suggests an effect but does not establish it, identify the relationship as a hypothesis or open question. MEASUREMENT SCOPE Use actual extracted data for numerical claims. If the available tools do not support a reliable graph calculation, provide the strongest defensible structural analysis and explain what data would be needed to complete the measurement. Make clear which findings are computed, manually observed, or interpretive. TASK 3: SYNTHESIS & EMERGENT FINDINGS Bring the DIO/ODI-native and graph-theoretical perspectives into dialogue. Explore where they: reinforce one another; describe different aspects of the same structure; produce tensions; reveal blind spots; suggest new research questions. Consider whether the investigation of DIO/ODI through its own concepts generates insights into the framework itself, not only into its distribution. Follow significant findings beyond the initial questions when the evidence warrants it. Independently documented reception, reuse, or reconstruction outcomes may contribute to the analysis where discoverable, but their absence should be interpreted within the limits of the search. OUTPUT FORMAT Write the entire final report in English. Produce a self-contained research report, not a conversational response or a research plan. Develop the findings through connected analytical prose, supported by source citations. Use clear headings and include tables, diagnostic matrices, graph diagrams, or numerical results where they contribute to the analysis. Distinguish conceptual diagrams from visualizations derived from collected data. Prioritize depth, synthesis, and evidence over repetition. Let the significance of the findings determine the length. Use the following report structure, adapting it where the research produces a more informative organization. EXECUTIVE SUMMARY Answer the central research question and summarize the most consequential findings. Distinguish conceptual alignment, observed network properties, and any supported effects on interpretation or reconstruction. RESEARCH APPROACH & CORPUS Explain how you entered and explored the corpus, what analytical methods emerged from your understanding of DIO/ODI, and which access or measurement limitations affected the research. DIO/ODI-NATIVE ANALYSIS Present the principal findings about conceptual continuity, reconstruction, contextual transitions, multilingual representation, and machine-readable artifacts. A diagnostic matrix may be used where it clarifies the relationships between concepts, observations, and interpretations. GRAPH REPORT Present: the chosen graph model; the observed boundary; principal nodes and relations; available degree or centrality results; the comparison of Zenodo and web entry points; multilingual topology; cross-layer connections; significant bridges, bottlenecks, or gaps. Use tables or diagrams where they improve understanding. EMERGENT INSIGHTS Develop important findings that were not fully anticipated by the initial assignment. Explain what the application of DIO/ODI to itself reveals about its conceptual resources, implementation, and possible development. SYNTHETIC CONCLUSION Explain what the research reveals about DIO/ODI when its own conceptual apparatus is applied to its implementation and distribution. Assess the relationship between theoretical commitments, semantic representations, and the observed network structure. Identify the strongest alignments, productive tensions, vulnerabilities, and unexpected findings. Let the evidence and the analysis determine the conclusion, including whether some questions remain open. Where useful, identify practical improvements or further research that follow directly from the findings. EVIDENCE STANDARD Support material findings with specific sources. Keep authorial statements, direct observations, analytical inferences, and hypotheses distinguishable without turning the report into a checklist of disclaimers. Account for version history when interpreting differences. State relevant access limitations and uncertainty. The goal is an intellectually independent exploration conducted through DIO/ODI—not a predetermined endorsement, a predetermined critique, or a merely mechanical compliance audit.

Follow-up methodological clarification

Please revisit your previous DIO/ODI analysis using the following clarification of the research question. REVISED RESEARCH QUESTION At the observed point in time, to what extent does the distributed DIO/ODI ecosystem appear to sustain a recognizable, referentially continuous, and meaningfully reconstructable identity across heterogeneous representations and entry points, despite partial inconsistencies, gaps, inaccessible resources, and uneven updating? Use DIO/ODI’s own concepts to explain what supports this apparent resilience, what strains it, and whether the observed weaknesses remain locally contained or materially compromise reconstruction of the framework as a whole. SCOPE AND PURPOSE This is a reflexive analysis of DIO/ODI’s implementation through its own conceptual perspective. It is not a request to: prove the general validity of DIO/ODI; establish that the framework validates itself; assess the ecosystem against an ideal of permanent completeness or flawless synchronization; repeatedly warn that self-application is not independent empirical validation. DIO is understood here as an ongoing optimization process, not a permanently achieved state. The observation concerns a temporal snapshot of that process. The central question is not whether defects exist. It is whether the distributed identity appears to hold together despite them. ANALYTICAL RULES Apply interpretive symmetry. Do not infer successful protection merely from the presence of a safeguard. Equally, do not infer system-level failure merely from the presence of an inconsistency, missing connection, inaccessible resource, outdated representation, or local reconstruction problem. Evaluate both strengths and weaknesses in relation to the reconstruction task and observation domain. Distinguish four levels of statement. a. Observed artifact or condition: What is actually present, absent, inconsistent, accessible, or inaccessible? b. Architectural role: How can this element be interpreted within DIO/ODI? What reconstruction-supporting or reconstruction-straining function does it have? c. Local reconstruction consequence: What can an observer entering through this representation plausibly recover, miss, or misunderstand? d. System-level significance: Does the local condition materially compromise the identity of the framework as a whole, or do other representations and pathways preserve sufficient continuity? Do not silently jump from (a) to (d). Use precise language without making every sentence defensive. Where an outcome has not been directly observed, prefer formulations such as: “can be interpreted within DIO as a mechanism for…” “provides structural support for…” “is designed to…” when the design intention is documented; “creates a potential obstacle to…” “the inspected pathway supports…” “within this observation domain, the available representations appear sufficient to…” Avoid converting these into unconditional claims such as “prevents,” “ensures,” “eliminates,” or “destroys” unless the evidence supports that scope. A clear scope statement at the beginning of a section is sufficient. Do not attach the same disclaimer to every paragraph. Evaluate materiality, not merely defect counts. For each important weakness, ask: Which reconstruction task does it affect? Which observer or entry point is affected? Does it concern the author, the framework, a concept, a publication, or a particular version? Does it obscure the referent, alter a central conceptual relation, or merely reduce detail? Can another accessible representation contextualize, correct, or compensate for it? Is compensation actually inspectable, or only assumed? Is the difficulty locally contained, or does it propagate across layers? Do not assume that redundancy guarantees compensation. Do not assume that local failure defeats the distributed whole. Treat variation and change carefully. Distinguish: identity-preserving variation; documented conceptual development; version misalignment; incompatible current claims; susceptibility to reconstruction failure; an observed reconstruction failure. A historical edition is not defective merely because it preserves an earlier state. Conversely, historical provenance does not automatically resolve every conflict encountered by a current observer. Keep conceptual and infrastructural graphs distinct. Do not require the distribution network to reproduce the K6 conceptual model literally. Separate conceptual interdependence from hyperlink topology, provenance relations, repository structure, and actual observer traversal. Any numerical graph finding must state its observation boundary, node and edge definitions, and relevant directionality. Treat acquisition failures as observer-relative unless verified otherwise. A failed fetch establishes that a particular acquisition route failed. It does not by itself establish that the resource is absent or unavailable through every route. Do not presume a favorable answer. The clarification does not instruct you to conclude that the ecosystem is resilient. It instructs you to assess resilience at the appropriate level. A positive, negative, mixed, or indeterminate conclusion is acceptable, provided that local observations and system-level judgments are connected explicitly. REQUESTED REVISION Please produce: A revised answer to the research question. A concise account of the principal mechanisms supporting reconstruction. A materiality assessment of the principal weaknesses. A comparison of at least two entry points, using inspected evidence where available. A correction table: original wording | revised wording | reason for correction A short synthesis identifying: what appears to hold together; where continuity is strained; what cannot be determined from the observed snapshot. Preserve useful findings from your original report. Correct their scope or interpretation where necessary rather than replacing the analysis with generic methodological caution. Do not invent new observations or measurements. If additional investigation is necessary, identify it explicitly rather than presenting it as already completed.

Model-specific addendum: Lumo

MODEL-SPECIFIC CORRECTION: LUMO Align the certainty of your diagnostic judgments with your acquisition coverage. Revisit labels such as: “Avoided”; “Successfully mitigated”; “Controlled”; “Low Risk”. Where you observed a countermeasure but not its outcome, use a category such as: “structural mitigation present; outcome not inspected.” Do not turn failed extraction into a confirmed server-side defect. Likewise, do not infer the actual scope of llms-full.txt from its filename. Reconsider the statement that K6 “accurately describes the ecosystem’s structure.” Specify whether you mean conceptual interpretation or literal infrastructural topology. Your extraction limitations do not require an entirely negative or indeterminate assessment. Evaluate what the representations you actually accessed allowed you to reconstruct, and which inaccessible elements were or were not necessary for that reconstruction.

Final integration instruction

I don’t want another “revised answer” or a commentary on the previous analysis. I want to combine the two outputs into a single, standalone paper. Take the structure and thematic scope of the first research report and incorporate the findings, clarifications, and shifts in interpretation from the second output. Adjust the original structure as needed—the goal is not to mechanically preserve the sections, but to provide a coherent interpretation. Reflect this new understanding throughout the entire analysis, not just in the conclusion. Retain specific findings, sources, measurements, and relevant limits, but reassess their significance where the second output has provided greater precision. Do not evaluate shortcomings or strengths in isolation: explain what they mean for the reconstructability of DIO/ODI in the observed time snapshot and at various levels of reconstruction detail. The final text must stand on its own, as if it had been written from the beginning as a single research report. No references to our conversation, no phrases like “in the previous response,” and no explanations of corrections made. Do not resubmit a revision plan or a summary of changes—write the entire paper directly.