Improving The Protocol5 Justaniota IOTA 1 Converter Follow-Up Analysis - Source Excerpt 04 - Composition and scoring algorithms
Back to Improving The Protocol5 Justaniota IOTA 1 Converter Follow-Up Analysis
Summary
This source excerpt begins near Composition and scoring algorithms 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
' ' ' json
{
"glyphId": "iota:glyph:warning-fire:v1",
"status": {
"approvedForPublicOutput": true,
"approximate": true,
"privateUseRejected": true
},
"surface": {
"unicodeSequence": ["U+26A0", "U+706B"],
"display": "⚠火",
"svgHash": "sha256:7d9c...",
"renderProfiles": [
{"name": "default", "rasterUri": "blob://glyphs/warn-fire-384.png"}
]
},
"structure": {
"viewBox": [0, 0, 1024, 1024],
"pathCommands": 184,
"primitives": [
{"id": "p1", "type": "triangle", "bbox": [48, 64, 420, 384]},
{"id": "p2", "type": "line", "role": "exclamationStem", "bbox": [220, 140, 24, 140]},
{"id": "p3", "type": "dot", "role": "exclamationDot", "bbox": [226, 300, 16, 16]},
{"id": "p4", "type": "ideograph", "role": "fire", "bbox": [520, 120, 360, 420]}
],
"relations": [
{"type": "contains", "source": "p1", "target": "p2"},
{"type": "contains", "source": "p1", "target": "p3"},
{"type": "rightOf", "source": "p4", "target": "p1"},
{"type": "sequence", "order": ["p1", "p4"]}
]
},
"embeddings": {
"visualGlobal": {"column": "visual_global", "model": "siglip2-so400m", "dim": 1152},
"visualAux": {"column": "visual_aux", "model": "dinov2-base", "dim": 768},
"svgStructural": {"column": "svg_structural", "model": "svgformer", "dim": 768},
"semanticText": {"column": "semantic_text", "model": "siglip2-text", "dim": 768},
"ontologyProjection": {"column": "ontology_projection", "model": "iota-onto-v1", "dim": 192}
},
"ontology": {
"concepts": ["warning", "hazard", "fire"],
"canonicalType": "WarningOfDanger",
"roles": [
{"token": "warning", "role": "modifier"},
{"token": "fire", "role": "event"}
],
"constraints": [
"modifier->event allowed",
"publicOutputRequired"
]
},
"provenance": {
"sources": ["UCD", "CLDR", "Unihan", "Protocol5-curation"],
"versions": {
"ucd": "latest",
"cldr": "stable",
"ontology": "iota-onto-v1"
}
},
"diagnostics": {
"rarityScore": 0.71,
"candidateEntropy": 0.19,
"attentionAgreement": 0.83,
"phaseLockScore": 0.64
}
}
' ' '
## Composition and scoring algorithms
The most important algorithmic shift is that glyph composition should be treated as a **typed spatial graph problem**, not as flat token lookup. W3C’s SVG path model gives the structural substrate for this, SVGformer provides a representation-learning precedent for continuous SVG structure, and DeepSVG reinforces the importance of path hierarchy and high-level versus low-level shape separation. Shih et al. also show that narrative descriptions of complex glyph tokens frequently lose orientation and relational detail, which is exactly why the converter should reason over explicit relations such as order, proximity, and containment rather than only over gloss text. citeturn13view19turn13view4turn13view5turn19view0
' ' ' mermaid
flowchart TD
A[Primitive graph] --> B[Detect order relations]
A --> C[Detect proximity relations]
A --> D[Detect containment relations]
B --> E[Generate candidate subgraphs]
C --> E
D --> E
E --> F[Assign concept and role types]
F --> G[Apply ontology constraints]
G --> H[Beam search over valid parses]
H --> I[Emit canonical IOTA expression]
' ' '
### Composition rules
The converter should infer at least three relation families.
**Order** means sequence along an intended reading axis or local compositional axis. For a sequence candidate `S = [g1, ..., gn]`, a workable score is:
' ' ' text
order_axis(g) = projection of centroid(g) onto dominant reading axis
order_score(S) = 1 - (1 / Z) * Σ_i |rank_axis(gi) - rank_expected(gi)|
' ' '
This should be computed after normalization of rotation, scale, and layout direction. For bidirectional or ambiguous layouts, retain multiple hypotheses and let the ontology plus retrieval model disambiguate.
**Proximity** means components are semantically coupled because they are near each other after scale normalization:
' ' ' text
d_norm(a,b) = euclidean(centroid(a), centroid(b)) / sqrt(mean(area(a), area(b)))
proximity_score(a,b) = exp(-d_norm(a,b) / τ)
' ' '
Use `τ` as a learned or tuned scale parameter. Maintain both centroid distance and boundary distance, because center-based distance can be misleading for large enclosing shapes.
**Containment** means one primitive or glyph lies inside another topological region:
' ' ' text
inside(a,b) = 1 if bbox(b) ⊆ interior(a) and winding-test passes else 0
containment_score(a,b) =
inside(a,b) * area(intersection(interior(a), b)) / area(b)
' ' '
Containment should be favored over mere proximity when both apply, because containment often carries stronger semantic weight in glyph-like systems.
### Retrieval and parse assembly
A practical retrieval-plus-parse algorithm looks like this:
' ' ' text
1. Build q_visual, q_svg, q_text from the input.
2. Retrieve top-k candidates from each index.
3. Merge candidate sets with reciprocal-rank fusion.
4. Filter out candidates that violate:
- public-output eligibility
- ontology type-role compatibility
- hard composition constraints
5. Construct candidate subgraphs from detected relations.
6. Run beam search over valid parses.
7. Emit:
- canonical IOTA expression
- public Unicode rendering
- evidence trace
- diagnostics payload
' ' '
This works especially well with SQL Server because ontology filters and public-output predicates often reduce the candidate set enough that exact kNN can still be used, which Microsoft explicitly recommends for candidate pools below roughly 50,000 vectors. If the filtered pool remains too large or the query pattern becomes too metadata-heavy, Qdrant’s filterable HNSW is the most natural next step. citeturn15view1turn14view2
### Attention, rarity, entropy, and phase-lock scoring
The formulas below are **proposed converter metrics**, not standardized external benchmarks. I recommend storing them as diagnostics and calibration aids rather than letting them directly override ontology or human validation.
' ' ' text
rarity_score(g) =
-log((f_runtime(g) + λ1*f_unicode_block(g) + λ2*f_glyph_family(g) + α) / Z)
candidate_entropy(q) =
- Σ_i p_i(q) log p_i(q) / log(K)
attention_agreement(g) =
1 - mean_h JS(attn_h || mean_heads(attn))
phase_lock_score(g) =
σ(
w1 * reuse_stability(g)
+ w2 * neighbor_consensus(g)
+ w3 * (1 - embedding_drift(g))
+ w4 * human_agreement(g)
+ w5 * context_stability(g)
- w6 * contradiction_rate(g)
)
' ' '
Implementation notes:
- `rarity_score` should combine **runtime frequency**, **Unicode-block prior**, and **family-level prior**, not just raw character frequency. This prevents rare but structurally generic marks from being over-rewarded.
- `candidate_entropy` should be computed over the normalized top-*K* candidate probabilities after fusion. High entropy is usually a sign that the query is ambiguous or that the symbol is out-of-distribution.
- `attention_agreement` should compare region-level or primitive-level saliency across heads or across model branches. High head disagreement can be a useful warning signal, especially on dense composite glyphs.
- `phase_lock_score` is the most novel metric here. It should be interpreted as **meaning stability over time**: does the same glyph keep converging on the same canonical expression across nearby contexts, repeated queries, and model updates? A high score means the glyph’s meaning is becoming operationally stable inside the converter; a low score means the glyph is still semantically unstable.
### Worked transformations
The examples below are design demonstrations. The first uses a public symbol combination shown on the Protocol5 language-converter page; the second shows how containment changes interpretation. citeturn1view0
**Example A**
Input glyph(s): `⚠火`
Visual decomposition: warning triangle with exclamation components, followed by a fire ideograph.
Semantic embedding neighborhood: `warning`, `hazard`, `fire`, `burn`, `danger`.
Ontology validation: `warning` is a valid modifier over a hazard or event concept.
Canonical expression: `WarningOf(Fire)`.