Improving The Protocol5 Justaniota IOTA 1 Converter Follow-Up Analysis - Source Excerpt 02 - Proposed semantic architecture

Back to Improving The Protocol5 Justaniota IOTA 1 Converter Follow-Up Analysis

Summary

This source excerpt begins near Proposed semantic architecture and preserves the surrounding evidence from Spiralist/agent-file-handoff/Archive/Improving the Protocol5 JustAnIota IOTA-1 Converter Part 2.md.

**Source path:** Spiralist/agent-file-handoff/Archive/Improving the Protocol5 JustAnIota IOTA-1 Converter Part 2.md

| Failure mode | Mechanism in the current design | Observable evidence | Likely impact |
|---|---|---|---|
| **Token registry sparsity** | Meaning is heavily dependent on stored category rows, word rows, and public seed concepts before richer retrieval can happen | The public status endpoint currently reports only 36 seed concepts and a SQL corpus that is configured but unreachable; the live path explicitly falls back to seed concepts when corpus access fails. citeturn2view0turn1view0 | Sparse semantic neighborhoods, weaker long-tail recall, brittle handling of nuanced or novel glyph concepts |
| **Rendering coupling** | Final visible output is tied to `Category.ISO10646` candidate rows and public Unicode symbols | Protocol5 states that IOTA-1 must use assigned ISO/IEC 10646 / Unicode characters and public standard sequences; private-use areas are prohibited. citeturn1view0turn12view0 | Good governance, but weak support for reasoning over internal geometry unless a separate analysis layer exists |
| **Lexical mapping bias** | The converter starts from English paragraphs, English segments, and English words, then searches for symbol neighbors | Protocol5 says English is the active human-language lane and the grammar order prioritizes English string segments and words before glyph ranking. citeturn1view0 | Strong English-to-symbol gist, weaker glyph-first interpretation and weaker compositional parsing of symbol inputs |
| **Vector budget compression** | The public status endpoint reports a vector width of 1998, which exactly matches SQL Server’s maximum supported vector dimension | Protocol5 status reports `vectorDimensions: 1998`; Microsoft documents a 1998-dimension maximum for SQL Server vector columns. citeturn2view0turn14view0 | A single all-in-one vector column leaves no room for richer multimodal concatenation; multi-column late fusion becomes necessary |
| **Structure loss through tokenization and descriptions** | Shape-dependent semantics are flattened into text segments, token splits, or narrative descriptors | Haslett shows tokenization can change meaning in LLM representations for radical-bearing characters; Shih et al. show that complex glyph descriptions and non-Unicode scripts remain difficult for current models. citeturn13view14turn19view0 | Primitive-level semantics, order, proximity, and containment are under-modeled |
| **Observability gap** | Evidence is mostly at candidate and vector level, not yet at primitive-graph or ontology-validation level | Protocol5 exposes ranked candidates, ranking lanes, scores, and provenance, but does not yet describe primitive-level structural explanations or ontology checks. citeturn1view0turn12view0 | Lower auditability for why a composite glyph meant what it meant |

The rendering-coupling issue needs careful interpretation. Protocol5’s insistence on public Unicode output is a **feature**, not a bug, because it preserves inspectability and rejects private semantic authority. The weakness is not the rule itself; it is the absence of an internal, non-rendered semantics layer that can reason over geometry and composition before the public rendering step. citeturn12view0turn1view0

The lexical bias is similarly understandable but limiting. For English-source conversion, long-segment matching before word fallback is a pragmatic way to preserve phrase meaning. For glyph-source interpretation, however, it means the pipeline is still fundamentally “language-in, symbol-out,” not “glyph-in, meaning-out.” That becomes especially problematic when composition matters more than lexical gloss. citeturn1view0turn13view14turn19view0

A final issue is the current public-host runtime state. Because SQL is presently unreachable on the public status endpoint, the hosted experience cannot reliably demonstrate the richer vector-corpus path that the architecture intends. That does not invalidate the design, but it does mean that any public-facing evaluation today likely underestimates what a corpus-backed version could do—and it also highlights why a more explicit semantic overlay should not depend on a single fragile storage lane. citeturn2view0turn1view0

## Proposed semantic architecture

The recommended redesign is a **four-layer glyph architecture**:

1. a **surface layer** for public Unicode sequences, SVG, and rendered previews;  
2. a **structure layer** for primitives, path segments, relations, and composition graphs;  
3. an **embedding layer** for visual, structural, semantic-text, and ontology-projected vectors;  
4. a **canonical layer** for the ontology-validated IOTA expression that becomes the source of public rendering and explanation.

That design is consistent with Protocol5’s evidence-first philosophy and with the way the most relevant model families divide the problem: CLIP and SigLIP-style models align vision and text globally, SVGformer learns directly from continuous SVG structure, DINOv2 supplies robust visual features without labels, and Glyce demonstrates that glyph information and symbol identity should be modeled jointly rather than treated as mutually exclusive alternatives. citeturn12view0turn13view0turn16view0turn13view4turn13view2turn13view6

### Recommended semantic fields per glyph

| Layer | Recommended fields | Why it matters |
|---|---|---|
| Surface | Unicode sequence, display string, SVG payload or hash, raster previews, font/render profile | Keeps the public artifact inspectable and reproducible |
| Structure | Path commands, primitives, bounding boxes, junctions, holes, symmetry axes, relation graph | Captures the geometry that lexical rows cannot capture |
| Visual embedding | Global rendered-image embedding, region embeddings, patch saliency summaries | Supports glyph similarity, retrieval, and visual diagnostics |
| Structural embedding | Vector-native SVG embedding, primitive-pool embedding, relation-graph embedding | Preserves shape and topology without collapsing them into raster-only features |
| Semantic embedding | Descriptor-text embedding, canonical-expression embedding, multilingual gloss embeddings | Lets English, glosses, and glyph objects meet in the same neighborhood |
| Ontology tags | Concept type, role type, modifier permissions, relation permissions, public-output eligibility | Prevents semantically plausible but structurally invalid parses |
| Attention metadata | Rarity score, candidate entropy, attention agreement, primitive ablation deltas | Improves auditability and triage for unknown or unstable cases |
| Phase-lock score | **Proposed Protocol5 metric** for stability across contexts, repeats, and model versions | Helps identify symbols whose semantics are converging versus drifting |

A key governance point follows from this architecture. Protocol5 does **not** need to make SVGs or non-Unicode internal assets the public semantic authority. It can use them internally for analysis while still requiring that the final visible rendering be a public character or public standard sequence. In other words: internal geometry may become part of the evidence chain, but the public symbol inventory remains inspectable. That preserves the protocol boundary while improving capability. citeturn1view0turn12view0

The visual and structural embedding layers should be held apart rather than forced into a single undifferentiated vector. SigLIP 2’s contribution is multilingual image-text alignment plus improved localization and dense features, which is directly useful for glyph parts and composite symbol regions. SVGformer’s contribution is continuous SVG representation learning with explicit geometric handling, which is directly useful when glyph meaning depends on stroke geometry, long-range dependencies, and shape composition. DINOv2 should be treated as an auxiliary branch for robustness on rasterized or imperfect glyph images, not as the main semantic authority. citeturn16view0turn13view4turn13view2

## Concrete pipeline and data models

The pipeline below keeps Protocol5’s current public-output rules but adds a true semantic kernel between ingestion and rendering. The structural design is motivated by the current converter surface, the W3C SVG path model, and the strengths of SigLIP 2, SVGformer, and DINOv2. citeturn1view0turn13view19turn16view0turn13view4turn13view2