Note

Editorial note (2026-03-24). This log uses “validated,” “verified,” and similar terms in places where the author’s long-standing practice is to say “tested” or “checked.” The distinction matters: open systems cannot be confirmed correct by any finite set of checks — they can only be tested (see Not Validated but Tested in the adversarial stress-test report for the full argument). The AI-generated text was not corrected at the time of writing. The log is otherwise unaltered.

Phase 2I: BEST Names Architecture — Design Session Log#

Generated:

2026-03-23 by Claude Opus 4.6

This llog documents the Phase 2I design session that produced the BEST Names architecture for matheology cross-reference labels. Phase 2I is a post-processing phase inserted between Phase 2H (stress-test freeze) and Phase 3 (content deployment).

Phase 2I Purpose#

Phase 2H revealed that the .. include:: directive creates duplicate Sphinx labels when the same content appears in both a source file and an aggregation page. Phase 2I resolves this by designing a comprehensive, stable, extensible naming architecture for all cross-reference labels across the matheology section.

The architecture applies the Evolvix BEST Naming system (Brief, Explicit, Summarizing, Technical dialects) to a 7-dimensional label grammar that is collision-free and parseable by an LL(1) parser.

Design Session Overview#

The design was developed iteratively over 4 rounds of refinement in a single Claude Code session on 2026-03-23:

  1. Round 1 — Initial Architecture: Established the PoE→PoC→PoR→PoT→PoU knowledge pipeline, model-prefixed labels (pet-ax1 instead of ax1), the 7 orthogonal dimensions, and the DRY principle (single point of truth in PoR; downstream views are compiled, never assembled via .. include::).

  2. Round 2 — Detailed Refinement (~32 points): Expanded PoR from 14 to 40+ fields, defined D2 element types, D5 worldview codes, D6 POST/analytical/machine sub-namespaces, exclusion rules, extraction matrix keywords, and the compilation skill specification.

  3. Round 3 — Naming Corrections (~32 points): Renamed codes (vtrib → vind, mat → stayc, path → mento), reordered the grammar (language last), consolidated machine codes under ma* prefix, split D5 into source (s*) vs. view (v*), expanded PoR to 45 fields, and designed the stub generation policy.

  4. Round 4 — Integration and Compilation: Resolved collision questions (aa/ff/ii ISO 639-1 collisions, hu/hub rename), confirmed LL(1) parsing, finalized all registry tables, and wrote the AHA design document and prompt scripts.

Key Design Decisions#

Label Grammar#

{model}-{elementType}{itemNumber}[-{version}][-{depth}][-{view}][-{state}][-{language}]

All dimensions after the first two are optional. The fixed order ensures LL(1) parseability. Hyphens separate dimensions; no hyphens within dimension values (except compound codes like oov2).

7 Orthogonal Dimensions#

D#

Name

Examples

Purpose

D1

Model

pet, jub

Which axiom system

D2

Element

ax, th, lm, sy

What kind of element

D3

Version

oov2, v3

Which version of the content

D4

Depth

easy, expert

Audience level

D5

View/Source

vjud, stor

Religious/cultural perspective or source text

D6

State

ff, diff, stayc

Operational or analytical state

D7

Language

en, de, ar

ISO 639-1 (with 3 exceptions: aar, ful, iii)

Collision-Free Proof for D6#

D6 has three sub-namespaces:

  • Set A (POST): 2-character double-letter codes (aa, cc, dd, ff, gg, hh, jj, kk, ll, vv, ww, yy)

  • Set B (Analytical): 3+ character codes, no ma prefix (diff, net, stayc, mento, conv, bib, cit, ref, web, doi, hub, pol, his)

  • Set C (Machine): ma prefix (mab, mai, mapi, mardf, majld)

These cannot collide: Set A matches /^([a-z])\1$/, Set B matches /^[a-z]{3,}$/ without ma prefix, Set C matches /^ma[a-z]+$/. The sets are pairwise disjoint by construction.

Source vs. View Distinction#

  • View codes (v*): Broad tradition synthesis — how a worldview interprets the axioms (vjud, vchr, visl, vhin, vsec, vbud, vind, vbah, vzor, vrom, vgre, vcan, vbab, vegy)

  • Source codes (s*): Narrow text corpora with chapter+verse structure (stor, sheb, stal, sgos, sapo, squr, shad, ssan, ssut)

ISO 639-1 Collision Resolution#

Three ISO 639-1 language codes collide with POST codes:

  • aa (Afar) → use aar (ISO 639-3)

  • ff (Fulah) → use ful (ISO 639-3)

  • ii (Sichuan Yi) → use iii (ISO 639-3)

Additionally, hu (Hungarian) collides with the analytical code hu (Human Hub), resolved by renaming the latter to hub. Design rule: never assign a 2-letter code to Set B.

Deliverables#

AHA Design Document#

Written to: source/matheology/vv/jub/oov2/llog/aha-best-names-for-matheology-links.rst

Contains 16 sections: core principle, knowledge pipeline, 7 dimensions with full registries, 45 PoR fields in 6 groups, extraction matrix keywords, link stability policy, compilation skill specification, prose reference conventions, and label examples.

Prompt Scripts (9 sessions)#

Written to source/matheology/vv/jub/oov2/prompts/ in execution order. Sessions 2I-2 and 2I-7 were each split into (a) and (b) halves to fit the 200K-token context window:

  1. prompt_2I-1.rst — Label migration (ax1 → pet-ax1)

  2. prompt_2I-2a.rst — PoR field validation, Part A: fields 1–18 (Identity, Technical, Source-Text)

  3. prompt_2I-2b.rst — PoR field validation, Part B: fields 19–45 (Operational, Network, Analytical) + combined report

  4. prompt_2I-3.rst — Compilation skill definition (extraction matrix, 4 modes, stub policy)

  5. prompt_2I-4.rst — First compilation run (expert + easy views for all 25 axioms)

  6. prompt_2I-5.rst — Adversarial stress-test (collision, parsing, scalability, human-factors, contradiction attacks)

  7. prompt_2I-6.rst — Public-facing documentation (4 audience pages: easy, producer, expert, architect)

  8. prompt_2I-7a.rst — Phase 2I closing: deliverable audit

  9. prompt_2I-7b.rst — Phase 2I closing: closing llog and handoff

Token-budget optimizations applied to sessions 2I-1, 2I-4, and 2I-5: selective reads for quest.rst (~48K tokens) and the debug file (~37K tokens) using grep + targeted offset reads instead of full file reads.

Phase 3 Handoff Notes#

Phase 2I is a design phase. The prompts above define the execution plan. Phase 3 should:

  1. Execute prompt 2I-1 (migration) first — this is the prerequisite for everything else

  2. Execute prompts 2I-2a through 2I-6 in order

  3. Execute prompts 2I-7a and 2I-7b to close Phase 2I formally

  4. Begin Phase 3 content work with the BEST Names architecture in place

The adversarial stress-test (prompt 2I-5) can optionally run in parallel with earlier prompts as a design review.

TELES repair — 2026m04d04

Repaired RST syntax errors (unexpected indentation, heading level inconsistencies, or list formatting). No formal content was modified.