Improving The Protocol5 Justaniota IOTA 1 Converter Follow-Up Analysis - Source Excerpt 06 - Risk and mitigation map

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

Summary

This source excerpt begins near Risk and mitigation map 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

' ' ' mermaid
gantt
    title Proposed implementation timeline
    dateFormat  YYYY-MM-DD
    section Phase 1
    Schema and provenance layer        :a1, 2026-05-11, 14d
    SVG parsing and primitive graph    :a2, after a1, 14d
    SQL multi-vector integration       :a3, after a1, 21d
    section Phase 2
    SigLIP 2 integration               :b1, 2026-06-22, 21d
    SVGformer structural encoder       :b2, 2026-06-29, 21d
    Ontology reranker and parser       :b3, 2026-07-13, 28d
    Evaluation harness                 :b4, 2026-07-20, 21d
    section Phase 3
    Human validation tools             :c1, 2026-08-17, 21d
    Active learning and diagnostics    :c2, 2026-08-24, 28d
    Production optimization            :c3, 2026-09-07, 21d
' ' ' 

### Risk and mitigation map

| Risk | Why it is real | Mitigation |
|---|---|---|
| **Ontology overconstraint** | A rigid ontology can reject semantically plausible outputs | Use ontology first as a soft reranker, then as a hard validator only at the public-output stage |
| **Sparse or biased glyph data** | SVGformer benefits from adequate data, and rare glyphs are inherently sparse | Use DeepSVG-backed augmentation, synthetic perturbation, and active learning on high-entropy cases citeturn13view4turn13view5 |
| **SQL feature ceilings** | SQL vectors cap at 1998 dimensions; vector-indexing and approximate search are still subject to preview constraints | Store multiple vector columns, use exact search after filters when possible, and migrate filtered ANN to Qdrant only if needed citeturn14view0turn15view1turn14view1turn14view2 |
| **Security or compliance mismatch** | SQL Server vector columns are not supported with Always Encrypted | If encrypted query scenarios emerge, isolate vector retrieval in a separate trusted service boundary or encrypt surrounding payloads instead of the vector column itself citeturn14view0 |
| **Public-boundary drift** | Teams may be tempted to treat internal SVGs as the new public authority | Keep final rendering limited to approved public symbols or public sequences, consistent with Protocol5’s rules citeturn1view0turn12view0 |
| **Misreading attention signals** | Saliency can be useful but is not a proof of semantic validity | Treat attention metadata as diagnostics only; gate production decisions by ontology, retrieval, and human benchmarks |

### Recommended choices

The highest-confidence recommendation is:

- **Primary vision-language encoder:** **SigLIP 2**  
- **Primary structural encoder:** **SVGformer**  
- **Auxiliary visual branch:** **DINOv2**  
- **Primary serving store in Phase 1–2:** **SQL Server native vectors with multiple vector columns and late fusion**  
- **Scale-out filtered ANN option:** **Qdrant**  
- **Offline benchmark and tuning lab:** **Faiss**

This combination best matches the problem and the existing Protocol5 stack. SigLIP 2 is the strongest fit for multilingual image-text retrieval with better localization and dense features; SVGformer is the best direct fit for SVG-native semantics; DINOv2 is the safest auxiliary image backbone; and SQL Server vectors fit the current Protocol5 facade, repository, and ADO.NET shape better than a full early storage migration would. Qdrant is the right second step if ontology-heavy filtered search outgrows SQL ergonomics, and Faiss remains the most useful offline evaluation substrate rather than a serving layer. citeturn16view0turn13view4turn13view2turn13view7turn13view8turn13view9turn14view2turn13view12

The main open questions are operational, not conceptual: how large the first curated glyph inventory should be, how aggressive the latency target must be for the public UI, and whether internal non-rendered SVG assets are formally acceptable as semantic evidence so long as public rendering remains Unicode-only. None of those questions change the central conclusion. The current Protocol5 converter is already a strong **public-symbol approximate conversion surface**. The next step is to give it a **real glyph semantics kernel** underneath that surface. citeturn1view0turn12view0