.. Migration note (2026m04d04): Claude copied this file during VV-to-HELL migration. Old path: ``vv/jub/oov2/llog/2I-adversarial-stress-test.rst`` (as given by LLoL) New path: ``hell/ll/jub/b/45/jub_ll_2026m03d23_2I-adversarial-stress-test.rst`` (as chosen by Claude) Category: JUB OOv2 log .. meta:: :description: Systematic adversarial attack on the BEST Names architecture, reporting HELD or BREACH for each weakness found, with a foundational note on testing. :keywords: BEST Names, adversarial stress-test, HELD, BREACH, Phase 2I-5, naming architecture, Popper, Dijkstra, open systems, JUB OOv2, Claude Opus, llog :author: Yah, Yas, everyone, LLoL as Laurence Loewe of Laodicea, ClaudeOp46Max, Anthropic, and Spirit of Boolean Truth :og:card:title: BEST Names Stress-Test
Adversarial Attack Results :og:card:description: Every attack vector against the BEST Names architecture tested and reported as HELD or BREACH, plus the epistemological case for testing over validating. .. SOCIAL-CARD-QUALITY-COMPARE --- OO (default effort) vs PP (max effort), 2026-03-26 OO :description: Adversarial stress-test of the BEST Names architecture, systematically attacking for weakness, ambiguity, and collision failures. OO :keywords: matheology, JUB, OOv2, Phase 2I-5, BEST Names, adversarial, stress-test, HELD, BREACH, naming architecture, llog OO :og:card:title: Phase 2I-5: BEST Names Stress-Test OO :og:card:description: Systematic adversarial attack on the BEST Names architecture, reporting HELD or BREACH for each weakness found with severity and evidence. PP :description: Systematic adversarial attack on the BEST Names architecture, reporting HELD or BREACH for each weakness found, with a foundational note on testing. PP :keywords: BEST Names, adversarial stress-test, HELD, BREACH, Phase 2I-5, naming architecture, Popper, Dijkstra, open systems, JUB OOv2, Claude Opus, llog PP :og:card:title: BEST Names Stress-Test
Adversarial Attack Results PP :og:card:description: Every attack vector against the BEST Names architecture tested and reported as HELD or BREACH, plus the epistemological case for testing over validating. .. SOCIAL-CARD-REVIEW --- generated by Claude Opus 4.6, 2026-03-26 dv_ClaOp46_PP_2026m03d26 --- max-effort rewrite, read full page. :description: 148 chars | :og:card:title: 44 chars (excl
) - [ ] PP title more compelling than OO title - [ ] PP description more accurate than OO description - [ ] Description hooks without misleading - [ ] Keywords specific to this page's actual content - [ ] No language rule violations - [ ] Character counts verified ********************************************************************* Phase 2I-5: Adversarial Stress-Test of BEST Names Architecture ********************************************************************* Generated 2026-03-23 by Claude Opus 4.6 during Phase 2I-5. This document records a systematic adversarial attack on the BEST Names architecture defined in :doc:`/matheology/hell/ll/jub/b/48/jub_ll_2026m03d25_aha-best-names-for-links`. The attacker's role is to find every weakness, ambiguity, collision, and scalability failure. For each attack, the result is **HELD** (system withstood this particular attack after genuine effort to break it) or **BREACH** (a specific constructive counterexample was found), with severity, confidence, and specific evidence. .. contents:: On this page :depth: 2 :local: ---- .. _not-tested-not-validated: Not Validated but Tested ========================== A note on language: this document says **tested**, not "validated," to describe what the stress-test achieved. This is a deliberate choice rooted in the epistemology of open systems. An open system --- one that can fail in ways not yet imagined, extended by future contributors not yet born, and deployed in contexts not yet foreseen --- cannot be *validated* in any complete sense. It can only be *tested*. The distinction matters: "validated" suggests closure ("the checking is done; further questions are unnecessary"), whereas "tested" invites continuation ("here is what was checked; what else might break?"). Karl Popper established this asymmetry as foundational to scientific method: a theory can be *falsified* by a single counterexample but never *verified* by any finite number of confirming observations (Popper 1959, *The Logic of Scientific Discovery*). Applied to system design: a stress-test that finds no flaws proves only that *these particular attacks* failed to break the system --- not that the system is unbreakable. Edsger Dijkstra made the same point about software: "Program testing can be used to show the presence of bugs, but never to show their absence" (Dijkstra 1970, *Notes on Structured Programming*, EWD249). Nassim Taleb generalized it: absence of evidence (no flaw found) is not evidence of absence (no flaw exists), and the consequences of undiscovered flaws in complex systems can be catastrophic precisely because overconfidence in "validation" suppresses the vigilance that testing demands (Taleb 2007, *The Black Swan*, Chapter 5). David Hume's problem of induction provides the deeper philosophical foundation: no finite set of observations entails a universal conclusion (Hume 1748, *An Enquiry Concerning Human Understanding*, Section IV). Even in systems engineering, where "validation" has a formal definition (IEEE 1012: "confirmation that the system fulfills its intended use"), practitioners acknowledge that validation is an ongoing process, never a completed event. The V-model's "validation" phase is better understood as "the most thorough testing performed to date." In short, calling a result "validated" is a subtle invitation to stop asking probing questions --- the exact opposite of what rigorous testing requires. Calling a result "tested" keeps the door open. The quality of any assurance is only as good as the quality of the attacks that were thrown at the system. That quality may be considerable when testers knew what they were doing --- and negligible when they did not. Either way, the focus belongs on the testing, not on its passing. **Practical consequence for this document:** Every HELD below means "this attack failed to break the system." It does NOT mean "the system cannot be broken by a more creative attack." Every BREACH means "a specific constructive counterexample was found." The quality of this stress-test is measured by the ingenuity of the attacks, not by the count of HELDs. **Terminology:** This document uses **HELD** (the system held under this attack) and **BREACH** (the attack found a way through) instead of the conventional PASS/FAIL. The standard PASS/FAIL has an ambiguous subject: does "PASS" mean the system passed or the attack passed? Since this document is structured around attacks, readers naturally parse "Result: PASS" as "the attack passed (succeeded)" --- the opposite of the intended meaning. HELD and BREACH are unambiguous regardless of perspective: a fortification either held or it was breached. **References:** - Dijkstra, E. W. (1970). *Notes on Structured Programming* (EWD249). T.H. Eindhoven. - Hume, D. (1748). *An Enquiry Concerning Human Understanding*. Section IV. - Popper, K. R. (1959). *The Logic of Scientific Discovery*. Hutchinson. (Original: *Logik der Forschung*, 1934.) - Taleb, N. N. (2007). *The Black Swan: The Impact of the Highly Improbable*. Random House. Chapter 5: "Confirmation Shmonfirmation!" ---- Methodology =========== **Documents examined:** - AHA design document (full, ~1300 lines) --- the primary target - PET axioms ``pet/axioms.rst`` (14 labels: ``pet-ax1`` -- ``pet-ax4`` confirmed live, ``pet-ax5`` -- ``pet-ax14`` in file) - JUB axioms ``jub/axioms.rst`` (11 labels: ``jub-ax15`` -- ``jub-ax25``) - JUB theorems ``jub/theorems.rst`` (7 labels: ``jub-th5`` -- ``jub-th11``) - JUB quest ``jub/quest.rst`` (42 labels: ``jub-con1`` -- ``jub-con3r7``, ``jub-pro1`` -- ``jub-pro3r7``) - Axioms index ``axioms/index.rst`` (live ``.. include::`` usage) **Missing documents (noted, tested against design spec instead):** - ``2I-por-field-testing.rst`` --- does not exist - ``skill-compile-matheology.rst`` --- does not exist - ``compiled/axioms/expert.rst``, ``compiled/axioms/easy.rst`` --- do not exist **Attack protocol:** Each attack must include (a) specific labels, codes, or scenarios, (b) parsing steps where applicable, (c) constructive counterexamples for FAILs. "This might be a problem" is not an attack. **ISO 639-1 verification:** Exhaustive double-letter check performed against two independent sources (GitHub Gist compiled from Wikipedia; DataHub language-codes dataset). All 183 ISO 639-1 codes examined. ---- Step 1 --- Collision Attacks ============================ Attack 1.1: D1 x D2 Prefix Collision ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** Can any D1 model code equal any D2 element type code? **Evidence:** D1 codes: ``pet`` (3), ``jub`` (3), ``4be`` (3), ``all`` (3). D2 codes: ``ax`` (2), ``th`` (2), ``lm`` (2), ``cr`` (2), ``cj`` (2), ``as`` (2), ``df`` (2), ``sy`` (2), ``rl`` (2), ``sc`` (2), ``mo`` (2), ``lg`` (2), ``fn`` (2), ``con`` (3), ``pro`` (3), ``q`` (1), ``eg`` (2), ``n`` (1), ``proof`` (5), ``limit`` (5), ``evx`` (3), ``ref`` (3), ``ex`` (2). Intersection: empty. **Structural argument:** Even if a D1 code happened to equal a D2 code (e.g., model ``ax``), the hyphen separator between D1 and D2 prevents syntactic collision: ``ax-ax5`` unambiguously parses as model=ax, element=ax5. **Result:** HELD (high confidence). Attack 1.2: D2 Bare vs. Specific Element ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** Does ``pet-ax`` (collection page) collide with ``pet-ax0`` or any specific-element label? **Evidence:** ``pet-ax`` and ``pet-ax0`` are distinct strings. The grammar splits at the letter/digit boundary: ``ax`` (letters only = collection) vs. ``ax0`` (letters + digit = specific). For all D2 types including single-instance types (``mo1``, ``lg1``), the bare code is always distinguishable from any digit-suffixed variant. **Tested edge case:** ``pet-n`` (notes collection) vs. ``pet-n1`` (note 1). Distinct strings. No collision. **Result:** HELD (high confidence). Attack 1.3: Cross-Dimension Collision (pet-ax5-de) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** Is ``pet-ax5-de`` ambiguous between D4 depth="de" and D7 language="de"? **Parse trace for ``pet-ax5-de``:** 1. D1: ``pet`` --- model registry match. 2. D2: ``ax5`` --- element match (type=ax, number=5). 3. Token ``de`` at dimension-scan position: - D3: ``de`` not in version registry {oov1, oov2, ppv1}. Skip. - D4: ``de`` not in depth registry {prod, easy, math, mab, mai, mapi, mardf, majld}. Skip. - D5: ``de`` does not match ``v`` + 3 or ``s`` + 3 pattern. Skip. - D6: ``de`` is 2 letters, not doubled (``d`` != ``e``). Not Set A. Length < 3: not Set B. Skip. - D7: ``de`` is valid ISO 639-1 (German). Match. 4. End of label. Unambiguous. **Specific attack: ``de`` is unambiguously D7** because no current D3, D4, D5, or D6 code is a 2-letter non-doubled string. However, the design does not STATE this as a formal invariant. If a future D4 depth code were 2 letters (e.g., ``de`` for "deep"), the parser would match it as D4 (which has priority), silently changing the meaning of existing labels. **Result:** BREACH (Minor). The label ``pet-ax5-de`` is currently unambiguous, but the collision freedom depends on an unstated invariant: *D3, D4, and D6 Set B codes must never be 2-letter non-doubled strings.* This invariant holds for all current codes but is not documented. **Severity:** Minor. **Confidence in current safety:** High. **Confidence in future safety without the invariant:** Low. Attack 1.4: D5 View/Source Internal Collision ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** Can any ``v*`` code equal any ``s*`` code? Can any D5 code collide with D4, D6, or D7? **View-Source:** Since ``v`` != ``s``, no ``v*`` code can equal any ``s*`` code. HELD (trivially, by first character). **D5 vs. D4:** Current D4 codes: ``prod``, ``easy``, ``math``, ``mab``, ``mai``, ``mapi``, ``mardf``, ``majld``. None start with ``v`` or ``s``. But no formal rule prohibits a future D4 code starting with ``v`` or ``s``. If D4 code ``vpro`` (hypothetical) were added, the parser would match it at D4 (checked before D5), shadowing the D5 namespace for that token. **D5 vs. D6/D7:** D5 codes are exactly 4 characters. D6 Set A is 2 chars, D7 is 2--3 chars. No collision by length for Set A/D7. D6 Set B is 3+ chars. A D6 Set B code starting with ``v`` or ``s`` and being exactly 4 characters would structurally resemble a D5 code. Currently no such D6 code exists, but no rule prevents it. **Result:** BREACH (Minor). No formal rule prevents D4 codes from starting with ``v``/``s``, which would shadow D5 view/source codes. **Severity:** Minor. **Proposed invariant:** *D4 depth codes MUST NOT begin with ``v`` or ``s``.* Attack 1.5: D6 Set A / Set B Boundary ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** Verify the claim that Set A (2-letter doubled) and Set B (3+ letter) cannot collide. **Proof verification:** - Set A is defined by regex ``^([a-z])\1$``: exactly 2 identical letters. Length = 2. - Set B is defined as 3+ lowercase letters, not matching Set A or Set C. Length >= 3. - Length 2 != length >= 3. Sets are disjoint. **Attack on ``ma*`` prefix:** The proof references "Set C" (machine codes, ``^ma`` prefix) as living in D4, not D6. Verified: the parser matches ``ma*`` tokens at D4 position (checked before D6). A ``ma*`` token at D6 position would be classified as Set B (length 3+, not doubled), which is correct but could be confusing if a machine code name were also meaningful as a D6 analytical code. **Result:** HELD (high confidence). Set A and Set B are disjoint by length. The Set C reference is a proof annotation, not a real D6 namespace. Attack 1.6: D7 Language vs. D6 POST --- EXHAUSTIVE CHECK ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** The design acknowledges 3 ISO 639-1 / D6 Set A collisions (``aa``, ``ff``, ``ii``). Are there others? Check ALL ISO 639-1 codes against ALL D6 Set A codes. **Method:** Extracted all 183 ISO 639-1 two-letter codes from two independent reference sources. Filtered for codes where both characters are identical (i.e., codes that match D6 Set A pattern ``^([a-z])\1$``). **Complete list of double-letter ISO 639-1 codes (8 total):** .. list-table:: :header-rows: 1 :widths: 8 18 15 18 41 * - ISO - Language - Speakers - D6 Status - AHA Acknowledged? * - ``aa`` - Afar - ~1.5M - Assigned (AnyAim) - YES * - ``ee`` - Ewe - ~7M - Unassigned - NO * - ``ff`` - Fulah - ~25M - Assigned (FeedbackFlow) - YES * - ``ii`` - Sichuan Yi - ~2M - Unassigned - YES * - ``kk`` - Kazakh - ~13M - **Assigned (KnownKiller)** - **NO** * - ``nn`` - Norwegian Nynorsk - ~0.6M - Unassigned - NO * - ``ss`` - Swati - ~2.3M - Unassigned - NO * - ``tt`` - Tatar - ~5.2M - Unassigned - NO **Critical finding:** The design lists 3 collisions; there are actually 8. Five were missed: ``ee`` (Ewe), ``kk`` (Kazakh), ``nn`` (Norwegian Nynorsk), ``ss`` (Swati), ``tt`` (Tatar). **Most severe miss:** ``kk`` (Kazakh, ~13 million speakers) is ALREADY ASSIGNED as D6 KnownKiller. This is not a hypothetical future collision --- it is a LIVE collision with an active D6 code. If a contributor writes ``pet-ax5-kk`` intending Kazakh language, the parser silently returns D6 KnownKiller. No error. No warning. **Result:** BREACH (Critical). The D7/D6 collision analysis is incomplete. 5 additional ISO 639-1 collisions exist, including 1 live collision (``kk``) with an already-assigned D6 code for a language with 13 million speakers. **Severity:** Critical. **Required fix:** Add ``ee``, ``kk``, ``nn``, ``ss``, ``tt`` to the collision list. All 8 languages must use ISO 639-3 forms: ``aar``, ``ewe``, ``ful``, ``iii``, ``kaz``, ``nno``, ``ssw``, ``tat``. Attack 1.7: Future Model Codes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** If a new model is named ``ax``, ``th``, or ``all``, what breaks? **``all``:** Already reserved as a system keyword (``all-ax-conv`` = cross-model compilation). Governance would reject this registration. HELD. **``ax``:** The label ``ax-ax5`` parses unambiguously (model=ax, element=ax5) due to the hyphen separator. But "ax" means both "the model" and "axiom" depending on context. The design states: "D2 codes MUST NOT equal any D1 model code." But the REVERSE is not stated: no rule prevents a new D1 model code from equaling an existing D2 element type code. **Concrete scenario:** A new research group proposes model code ``as`` (Abrahamic Synthesis). ``as`` is already a D2 code for "Assumption." Labels like ``as-as1`` (model=as, assumption 1) would be syntactically valid but maximally confusing. **Result:** BREACH (Minor). The D1/D2 non-collision constraint is unidirectional. D2 must not equal D1, but D1 is not required to avoid D2. Governance is the only protection. **Severity:** Minor. **Proposed fix:** State bidirectional constraint: *D1 codes MUST NOT equal any D2 code AND D2 codes MUST NOT equal any D1 code.* Attack 1.8: Quest Label Grammar Gap ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** The migration maps ``con-a-2-1`` to ``jub-con2r1``. Does the ``r`` round separator fit the grammar? **Grammar definition:** ``{model}-{elementType}{itemNumber}[...]`` The design says "Element type codes are always followed by a digit for specific elements." The item number for ``jub-con2r1`` is ``2r1``, which contains the letter ``r`` --- not purely numeric. **Parse trace for ``jub-con2r1``:** 1. D1: ``jub`` --- match. 2. D2 token: ``con2r1``. Split at letter/digit boundary: letters = ``con``, digits = ``2``, remainder = ``r1``. 3. The parser extracted type=``con``, number=``2``. But ``r1`` remains unconsumed within the D2 token. No hyphen separates ``2`` from ``r1``. 4. Parse fails: ``r1`` is not a valid dimension segment (no leading hyphen, mixed letters and digits). **Same failure for:** ``jub-pro3r7``, ``jub-con2r10``, ``jub-con3r5``, and all 28+ round-numbered quest labels in the live codebase. **Note:** Sphinx itself does not parse labels --- it treats them as opaque strings. The labels WORK in Sphinx. But the BEST Names grammar, as formally defined in the AHA document, cannot parse them. **Additional concern:** The ``r`` within D2 contradicts the design rule "Hyphen ``-`` is the sole dimension separator." While ``r`` is not a dimension separator (it is within D2), it functions as a sub-element separator, creating a two-level structure ``{conNumber}r{roundNumber}`` that the grammar does not document. **Result:** BREACH (Major). The quest label pattern ``{elementType}{N}r{M}`` is not accommodated by the AHA grammar. 28+ live labels in the codebase violate the grammar definition. **Severity:** Major. **Proposed grammar extension:** ``{elementType}{itemNumber}[r{roundNumber}]`` where ``roundNumber`` is a digit string, applicable only to D2 types ``con`` and ``pro``. ---- Step 2 --- Parsing Attacks ========================== Attack 2.1: Ambiguous Tokenization (Full 7-Dimension Label) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** Can an LL(1) parser unambiguously identify each dimension in ``pet-ax5-oov2-easy-vjud-net-de``? **Parse trace (all 12 example labels from AHA Section 16):** .. list-table:: :header-rows: 1 :widths: 36 8 8 8 8 8 8 8 6 * - Label - D1 - D2 - D3 - D4 - D5 - D6 - D7 - OK? * - ``pet-ax5`` - pet - ax5 - -- - -- - -- - -- - -- - Y * - ``pet-ax5-oov2`` - pet - ax5 - oov2 - -- - -- - -- - -- - Y * - ``pet-ax5-easy`` - pet - ax5 - -- - easy - -- - -- - -- - Y * - ``pet-ax5-oov2-easy`` - pet - ax5 - oov2 - easy - -- - -- - -- - Y * - ``pet-ax5-prod-vjud`` - pet - ax5 - -- - prod - vjud - -- - -- - Y * - ``pet-ax5-oov2-easy-vjud-net-de`` - pet - ax5 - oov2 - easy - vjud - net - de - Y * - ``pet-ax-net`` - pet - ax - -- - -- - -- - net - -- - Y * - ``jub-th8-stayc`` - jub - th8 - -- - -- - -- - stayc - -- - Y * - ``all-ax-conv`` - all - ax - -- - -- - -- - conv - -- - Y * - ``all-ax-hub`` - all - ax - -- - -- - -- - hub - -- - Y * - ``pet-ax-ff`` - pet - ax - -- - -- - -- - ff - -- - Y * - ``pet-mo1`` - pet - mo1 - -- - -- - -- - -- - -- - Y **All 12 example labels parse correctly.** The parser operates as follows: after D1 (lookup) and D2 (letter/digit split), each remaining hyphen-separated token is tested against dimensions in fixed order: D3 (version lookup), D4 (depth lookup), D5 (``v``/``s`` + 3 pattern), D6 (Set A: doubled 2-letter; Set B: 3+ letter), D7 (2--3 letter ISO code). First match wins. **Additional test --- quest labels (NOT in example table):** - ``jub-con2r1``: D2 parse fails (``r1`` unconsumed). See Attack 1.8. - ``jub-pro3r7``: Same failure. **LL(1) classification:** The grammar is technically LL(1) with a symbol table (registry lookups for D3 and D4). Pure LL(1) without lookahead tables is not achievable because D3, D4, and D6 Set B all accept multi-character lowercase strings with no distinguishing structural pattern. **Result:** HELD (high confidence) for the 12 documented examples. BREACH for quest labels (already reported as Attack 1.8). Attack 2.2: Unknown Tokens (D6 Set B Catch-All) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** What happens when the parser encounters an unregistered code? **Concrete scenario:** ``pet-ax5-xyz`` **Parse trace:** 1. D1: ``pet``. D2: ``ax5``. 2. Token ``xyz``: - D3: not in version registry. Skip. - D4: not in depth registry. Skip. - D5: starts with ``x``, not ``v``/``s``. Skip. - D6: 3 letters, not doubled → **Set B structural match.** Accepted. 3. ``xyz`` is silently parsed as D6 state code. No error. No warning. **Worse scenario:** ``pet-ax5-oov3`` (mistyped version code) 1. D3: ``oov3`` not in version registry {oov1, oov2, ppv1}. Skip. 2. D4: not in depth registry. Skip. 3. D5: starts with ``o``, not ``v``/``s``. Skip. 4. D6: 4 letters, not doubled → Set B structural match. **Accepted as D6.** A misspelled version code ``oov3`` is silently absorbed as a D6 state code. The contributor intended D3 but got D6 with no error. **Same problem for:** ``pet-ax5-easyx`` (typo of ``easy``), ``pet-ax5-prод`` (Cyrillic ``о`` in ASCII context), or any 3+ letter string that does not match D3, D4, or D5. **Root cause:** D6 Set B is defined STRUCTURALLY (any 3+ lowercase letters that are not doubled) rather than by REGISTRY (a closed list of valid codes). This makes D6 a catch-all that absorbs anything the earlier dimensions reject. **Result:** BREACH (Major). The D6 Set B namespace is structurally open, causing the parser to silently accept typos and unregistered codes as D6 state codes. No error detection is possible for tokens that are 3+ lowercase letters. **Severity:** Major. **Proposed fix:** D6 Set B must be a CLOSED registry (lookup-based), not a structural pattern. Any token not matching a registered D3, D4, D5, D6, or D7 code should produce a parse error. Attack 2.3: Dimension Ordering Enforcement ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** Can someone write ``pet-ax5-de-easy`` (D7 before D4) and have it silently resolve incorrectly? **Parse trace for ``pet-ax5-de-easy``:** 1. D1: ``pet``. D2: ``ax5``. 2. Token ``de``: D3 fail, D4 fail, D5 fail, D6 fail (2 letters, not doubled, length < 3), D7: 2-letter ISO match (German). 3. Token ``easy``: D7 was matched (language is always last). Any remaining tokens are invalid. **Parse error: unexpected token after language code.** **Reverse test:** ``pet-ax5-net-easy`` 1. D1: ``pet``. D2: ``ax5``. 2. Token ``net``: D3 fail, D4 fail, D5 fail, D6 Set B match. 3. Token ``easy``: D7 expected. ``easy`` is 4 letters, not a valid ISO code. **Parse error.** **Positive test:** ``pet-ax5-easy-net`` (correct order) 1. Token ``easy``: D3 fail, D4 match (depth). Token ``net``: D6 Set B match. Success. **Conclusion:** The fixed dimension order IS enforced by the sequential parser. Misordered labels produce parse errors, not silent misparsing. **Result:** HELD (medium confidence). Ordering is enforced by parser precedence. Error messages may be unhelpful (see Attack 4.5). Attack 2.4: Digit Ambiguity in D2 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** Is the boundary between element type code and item number unambiguous for ``pet-ax55``, ``pet-ax555``, ``pet-proof1``? **Tokenization rule:** The D2 token is split at the letter/digit boundary: all leading lowercase letters form the type code, all trailing digits form the item number. - ``ax55`` → type=``ax``, number=55. Unambiguous. - ``ax555`` → type=``ax``, number=555. Unambiguous. - ``proof1`` → type=``proof``, number=1. Unambiguous. - ``pro1`` → type=``pro``, number=1. Distinct from ``proof1``. **Potential vulnerability:** The letter/digit split works because ALL current D2 type codes are letter-only ``[a-z]+``. The design says codes are "2--5 character lowercase" but does not explicitly exclude digits from type codes. If a D2 code like ``h2o`` were registered, the letter/digit split would fail: ``h2o5`` → type=``h``, number=``2``, remainder=``o5`` → parse error. **Also relevant:** D1 model code ``4be`` starts with a digit. D1 and D2 are separated by a hyphen, so D1 digits do not affect D2 parsing. But this shows the system already uses digits in codes at D1 level. **Result:** BREACH (Minor). The design does not explicitly state that D2 type codes must be letter-only ``[a-z]+``. The letter/digit boundary tokenization depends on this invariant. **Severity:** Minor. **Proposed fix:** Add explicit rule: *D2 element type codes MUST contain only lowercase ASCII letters [a-z]. Digits are reserved for item numbers.* Attack 2.5: Hyphen in Version Codes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** What if a future version code contains a hyphen, e.g., ``oo-v2``? **Parse trace for ``pet-ax5-oo-v2-easy``:** 1. D1: ``pet``. D2: ``ax5``. 2. Token ``oo``: D3 fail (not in registry). D4 fail. D5 fail. D6: 2 identical letters → **Set A match** (even though ``oo`` is unassigned, the structural pattern matches). Consumed as D6. 3. Token ``v2``: D5 pattern requires ``v`` + 3 letters, but ``v2`` is only 2 characters and contains a digit. Fail. D6: 2 chars, not doubled (``v`` != ``2``). Fail. D7: contains digit. Fail. **Parse error.** **Conclusion:** A hyphenated version code splits into separate tokens, each misclassified. The design's "hyphen as sole separator" rule implicitly prohibits hyphens within dimension values, but this is not stated as a formal constraint. **Result:** HELD (medium confidence). The sole-separator rule implicitly handles this. No current or planned version code contains a hyphen. **Recommendation:** Add explicit rule: *No dimension value may contain a hyphen. Compound names must use concatenation (e.g., ``oov2`` not ``oo-v2``).* ---- Step 3 --- Scalability Attacks ============================== Attack 3.1: 1000 Axioms Across 20 Models ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** Does the label grammar and Sphinx infrastructure handle 1000 axioms across 20 models? **Quantitative assessment:** - Label length (worst case): ``model4-element8-version5-depth5-view4-state6-lang3`` + 6 hyphens = 41 characters. No Sphinx label length limit. - Base labels: 1000 elements x 20 models = 20,000. - With stub policy (1% utilization of combinatorial space): ~200,000 labels. - Sphinx label storage: Python dict, O(1) lookup. 200K entries = trivial. - Cross-reference resolution: O(N) at build time, ~200K refs = seconds. **Result:** HELD (high confidence). Attack 3.2: 100 Languages ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** At 100 languages, does the suffix approach still work? **Assessment:** - ISO 639-1 has ~183 codes; ISO 639-3 has ~7800. 100 languages is within ISO 639-1 capacity. - D7 suffix adds 1 token per label. No structural issue. - Build time: each language is an independent Sphinx build. 100 builds x ~30s = ~50 min sequential; parallelizable. - D7/D6 collisions: only 8 double-letter ISO 639-1 codes (Attack 1.6). 100 languages does not increase the collision count. **Result:** HELD (medium confidence). Build time is the practical limit, not the naming system. Attack 3.3: 50 Worldviews ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** At 50+ views, does the D5 space remain navigable? **Assessment:** - D5 ``v`` + 3 letters = 17,576 possible codes. 50 views = 0.28%. - D5 ``s`` + 3 letters = 17,576 possible codes. 50 sources = 0.28%. - The ``hub`` D6 code provides human disambiguation. - Structural capacity: no concern for naming. **Human navigability** is the real limit: 50 worldviews in a dropdown or index page is manageable with grouping (e.g., "Abrahamic", "Dharmic", "Ancient"). **Result:** HELD (high confidence) for the naming system. Human-factors limits are separate. Attack 3.4: Version Accumulation (50 Versions) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** After 50 versions, does the VV archive become unmanageable? **Assessment:** - Label capacity: ``pet-ax5-oov50`` --- valid, no structural issue. - Archive size: ~500 pages x 50 versions = 25,000 archived pages. Manageable for Sphinx. - The ``diff`` D6 code supports version-to-version delta views. - The Jubilee recompile policy (Section 13.6 of AHA) addresses link rot in old versions. **Risk:** Version codes are currently 4 characters (``oov1``, ``ppv1``). At version 50+, codes might need 5+ characters (``oov50``). No structural limit on version code length. **Result:** HELD (medium confidence). Archiving needs automation at scale but the naming system accommodates it. Attack 3.5: Combinatorial Explosion ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** 25 axioms x 5 depths x 23 views x 14 states x 10 languages = 402,500 possible pages. How does the system know which combinations are meaningful? **Current system capacity:** - Elements: 116 (14 PET axioms + 11 JUB axioms + 7 JUB theorems + 84 quest items). - Full combinatorial space: 116 x 3 versions x 10 depths x 23 D5 x 40 D6 x 10 languages = ~32 million. - Actual labels in codebase: ~116 (PoR labels only). - Utilization: 0.00036%. **100-year projection:** - 10,000 elements x 100 versions x 10 depths x 80 D5 x 76 D6 x 200 languages = ~1.2 trillion possible combinations. - At 0.01% utilization: ~122 million pages. This exceeds a single Sphinx build (RAM, file count). - At realistic utilization (PoR + 3 depths + 5 views + 2 states + 10 languages = ~300 pages per element): 10,000 x 300 = 3 million pages. Challenging but feasible with partitioned builds. **The stub policy** (Section 14.2 of AHA: "Generate stubs = No") prevents empty pages. The extraction matrix determines which combinations have content. But the extraction matrix itself must be maintained --- deciding which of 1.2 trillion combinations are meaningful is a content-management problem, not a naming-system problem. **Result:** HELD (low confidence). The naming system handles any combination. The content-management decision ("which combinations are meaningful?") is the real bottleneck at scale, and the extraction matrix is the mechanism. Its tractability at 100-year scale is unproven. Attack 3.6: Build Time ^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** At what point does Sphinx build time become prohibitive? **Assessment:** - Sphinx incremental builds: O(changed documents). Day-to-day development is fast regardless of total size. - Full rebuild: O(N documents + M cross-references). At 3M pages, full rebuild could exceed 1 hour. - Partitioned builds (per model, per language) reduce this to manageable chunks. **Result:** HELD (medium confidence). Incremental builds handle development. Full Jubilee rebuilds may take hours at 100-year scale, but this is expected for a comprehensive reconciliation. ---- Step 4 --- Human-Factors Attacks ================================ Attack 4.1: Label Memorability ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** Can a human remember ``pet-ax5-oov2-easy-vjud-net-de``? **Assessment:** No --- 35 characters across 7 dimensions. But the design provides shorter forms for common use: - ``pet-ax5`` (7 chars) for the canonical PoR. - "Pet ax5_A5" in prose (6 chars). - "ax5_A5" subsequently (2 chars). The full 7-dimension label is for maximally specific cross-references, not human memorization. This is analogous to a URL --- humans remember "wikipedia.org" not the full path. **Result:** HELD (medium confidence). The design provides appropriate shorthand for human use. Attack 4.2: Prose Reference Confusion ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** Is "Pet ax5_A5 and Jub ax5_A5" confusing? **Assessment:** Currently impossible --- PET has ax1_A1--ax14_A14, JUB has ax15_A15--ax25_A25. No number overlap. But with future model 4Be potentially starting from ax1_A1, "Pet ax1_A1 and 4Be ax1_A1" would be needed. The prose convention (model + element for first mention) handles this. **Stress test:** A paragraph discussing PET ax5_A5, JUB ax15_A15, and 4Be ax5_A5 simultaneously. "Pet ax5_A5 and 4Be ax5_A5 both assert containment, but..." --- this is clear with model prefixes. **Result:** HELD (medium confidence). Attack 4.3: Beginner Onboarding ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** How many documents must a new contributor read to understand the naming system? **Assessment:** 1. CLAUDE.md (project basics) --- ~100 lines. 2. AHA design document (full architecture) --- ~1300 lines. 3. The 40+ PoR field registry (Section 11 of AHA) --- within AHA. The AHA document is comprehensive but monolithic. A contributor who just wants to add a label must read the full 7-dimension system, the collision proofs, the compilation skill, etc. **Result:** BREACH (Cosmetic). No quick-start guide exists. The AHA document is authoritative but not beginner-friendly. A 1-page cheat sheet with the label grammar, the 12 examples, and "common patterns" would reduce onboarding friction significantly. **Severity:** Cosmetic. Attack 4.4: Worldview Sensitivity ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** Are any D5 codes potentially offensive or inappropriate? **Codes reviewed against Library of Congress Subject Headings, comparative religion scholarship conventions, and cultural sensitivity norms:** - ``visl`` (Islam): ``isl`` is a standard academic abbreviation. No issue. - ``vjud`` (Judaism): ``jud`` is the Latin root (Judaeus). Standard. - ``vchr`` (Christianity): ``chr`` is standard (Christ-). - ``vhin`` (Hinduism): ``hin`` is standard. - ``vbud`` (Buddhism): ``bud`` is standard (Buddha-). - ``vsec`` (Secular): No issue. - ``vind`` (Indigenous): "ind" could be confused with "India"/"Indian." In comparative religion, "Indigenous" is the preferred umbrella term. The abbreviation is defensible but compresses enormous diversity into a single category. The design acknowledges this: "diverse, documented per tradition." - ``vbah`` (Baha'i), ``vzor`` (Zoroastrian): Standard abbreviations. - ``vcan`` (Ancient Canaanite): In biblical archaeology, "Canaanite religion" is common usage. Some scholars prefer "West Semitic religion" as more neutral. The abbreviation is within current academic usage. **External standard alignment:** No ISO standard or LCSH abbreviation system for religions exists. The D5 codes are a bespoke system, consistent with domain-specific taxonomies in library science. **Result:** HELD (low confidence). No codes are actively offensive. ``vind`` is the most reductive; ``vcan`` could draw scholarly objection. Neither rises to the level of a design flaw. Attack 4.5: Error Messages ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** When a ``:ref:`` fails, does Sphinx provide helpful diagnostics? **Sphinx error on broken reference:** :: WARNING: undefined label: 'pet-ax5-oov3' **Assessment:** Sphinx identifies the label string but provides no guidance on WHICH dimension contains the error. A contributor seeing this warning must manually check ``pet`` (valid D1?), ``ax5`` (valid D2?), ``oov3`` (valid D3?). With 7 dimensions, this is tedious. **Worse:** per Attack 2.2, a misspelled code like ``oov3`` would be silently parsed as D6 by the BEST Names grammar, so the label would resolve but point to the wrong page (if it existed). Sphinx would show no error at all. **Result:** BREACH (Minor). No label-testing tooling exists. The design should specify a linting script or Sphinx extension that tests labels against the BEST Names grammar and reports dimension-level errors. **Severity:** Minor. ---- Step 5 --- Design Contradiction Attacks ======================================= Attack 5.1: DRY vs. Compilation ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** Compiled pages copy/transform PoR content. If the PoR changes without recompilation, compiled pages are stale. Is this a DRY violation? **Assessment:** This is a standard build-artifact pattern, not a DRY violation. The PoR is the single source of truth; compiled pages are derived outputs. Staleness between compilation runs is the same as staleness between code compilation and binary --- managed by running the build. The design addresses this with CURRENT-Replace mode. **Result:** HELD (medium confidence). Not a DRY violation if the compilation skill is reliably run. The design should explicitly note that compiled pages are build artifacts, not independent sources. Attack 5.2: Include Ban vs. Reality ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** The AHA document bans ``.. include::`` for labeled content (Section 1). But ``axioms/index.rst`` currently uses it. **Evidence (``axioms/index.rst`` lines 31--43):** :: .. include:: /matheology/pet/axioms.rst :start-after: PET-AXIOMS-CONTENT-START :end-before: PET-AXIOMS-CONTENT-END .. include:: /matheology/jub/axioms.rst :start-after: JUB-AXIOMS-CONTENT-START :end-before: JUB-AXIOMS-CONTENT-END The included regions contain label definitions (``.. _pet-ax1:``, ``.. _jub-ax15:``, etc.). The ``.. include::`` directive pastes these labels into ``axioms/index.rst`` before Sphinx processes it. Since ``pet/axioms.rst`` and ``jub/axioms.rst`` are ALSO processed as independent documents, the same labels exist in BOTH documents. **Expected behavior:** Sphinx should emit duplicate-label warnings: :: WARNING: duplicate label: 'pet-ax1', other instance in matheology/axioms/index **Mitigating factor:** The file contains a TODO comment: :: .. TODO (Phase 3): Replace .. include:: with compiled pages. So the author knows this is a violation. But it is a LIVE violation in the current codebase, and the AHA's own Section 1 rule says this "MUST NOT" be done. **Result:** BREACH (Major). The ``axioms/index.rst`` file violates the AHA's own NO-INCLUDE rule for labeled content. This creates duplicate labels. The TODO indicates awareness but does not resolve the contradiction. **Severity:** Major (active rule violation in the codebase that the design itself says "MUST NOT" occur). Attack 5.3: D7 Language Suffix vs. Sphinx i18n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** The BEST Names grammar defines D7 language suffixes (``pet-ax5-de`` for German). But Sphinx's built-in i18n uses ``.po`` translation files with language-NEUTRAL labels. **Sphinx i18n mechanism:** - English source: ``source/matheology/pet/axioms.rst`` contains ``.. _pet-ax5:`` - German translation: ``locale/de/LC_MESSAGES/*.po`` translates the content. - German build output: ``build/html/de/matheology/pet/axioms.html#pet-ax5`` --- same label ``pet-ax5``, different directory. **BEST Names D7 mechanism:** - ``pet-ax5-de`` = a SEPARATE RST file with its own label, containing German-specific content (not a translation of ``pet-ax5``). **Conflict:** These are two different approaches to multilingual content. Sphinx i18n produces translated versions of the same label; BEST Names D7 produces language-specific variants with distinct labels. The design does not specify: 1. When to use Sphinx i18n (``.po`` files) vs. D7 suffixed pages. 2. Whether D7 is for translation (duplicating Sphinx i18n functionality) or for culturally-adapted content (a separate need). 3. How cross-references work across the two systems. A ``:ref:`pet-ax5``` in the German Sphinx build resolves within the German tree. A ``:ref:`pet-ax5-de``` resolves to a different document entirely. **Result:** BREACH (Major). The D7 language suffix mechanism and Sphinx's built-in i18n are two parallel, undocumented, potentially conflicting approaches to multilingual content. The design must specify the boundary: when each mechanism is used and how they interact. **Severity:** Major. Attack 5.4: Machine Codes --- D4 or D6? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** Machine codes (``ma*``) appear in both D4 (depth, Section 7) and D6 (state, Section 9.1, "Set C"). **Assessment:** D4 lists ``mab``, ``mai``, ``mapi``, ``mardf``, ``majld`` as depth codes. Section 9.1 references "Set C (machine): regex ``^ma`` prefix, already captured by D4 machine codes." Set C is not a D6 namespace --- it is a notation in the D6 collision proof explaining that ``ma*`` tokens are consumed at D4 position before reaching D6. **However:** The presentation is confusing. The phrase "Set C" implies a D6 sub-namespace parallel to Set A and Set B. A reader might think machine codes can appear at either D4 or D6 position. **Result:** HELD (medium confidence). Machine codes live in D4 only. Set C is a proof annotation, not a real D6 namespace. But the presentation should be clarified. Attack 5.5: Reserved Code ``ref`` Overloaded ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Attack:** ``ref`` appears in three different contexts in the design. **Context 1 --- D2 reserved element type (Section 5):** ``ref`` --- "Pointer to another ReRaft within ResearchCity" **Context 2 --- D6 analytical code, Set B (Section 9.3):** ``ref`` --- "Pointer to another ReRaft within ResearchCity" **Context 3 --- Extraction matrix keyword (Section 12):** ``ref`` --- "Include as cross-reference link only (point to PoR)" **Analysis:** Contexts 1 and 2 have identical descriptions but live in different dimensions. ``pet-ref1`` (D2: a standalone reference document) vs. ``pet-ax5-ref`` (D6: the reference view of axiom 5). The parser resolves these unambiguously by position. Context 3 is in a separate namespace entirely (extraction matrix, not label grammar). No parser collision. **Human confusion:** A contributor encountering "ref" must determine: is this an element type (D2), a state code (D6), or an extraction keyword? The three meanings are related but distinct. Using the same 3-letter code for all three invites misunderstanding. **Result:** BREACH (Minor). ``ref`` is overloaded across 3 contexts. While parseable (positions disambiguate), the semantic overload creates contributor confusion. **Severity:** Minor. ---- Summary Statistics ================== .. list-table:: :header-rows: 1 :widths: 10 8 20 62 * - ID - Result - Severity / Confidence - Description * - 1.1 - HELD - -- / High - D1 x D2 prefix collision * - 1.2 - HELD - -- / High - D2 bare vs. specific element * - 1.3 - BREACH - Minor / High (current), Low (future) - Cross-dimension: unstated 2-letter invariant * - 1.4 - BREACH - Minor / -- - D5: D4 codes not restricted from v/s prefix * - 1.5 - HELD - -- / High - D6 Set A / Set B disjoint by length * - 1.6 - **BREACH** - **Critical** / -- - D7/D6 collision: 5 missed ISO 639-1 codes including live ``kk`` * - 1.7 - BREACH - Minor / -- - Future model codes: unidirectional D1/D2 constraint * - 1.8 - **BREACH** - **Major** / -- - Quest label ``{N}r{M}`` pattern not in grammar * - 2.1 - HELD - -- / High - 12/12 example labels parse correctly * - 2.2 - **BREACH** - **Major** / -- - D6 Set B catch-all absorbs typos silently * - 2.3 - HELD - -- / Medium - Dimension ordering enforced by parser precedence * - 2.4 - BREACH - Minor / -- - D2 type codes not explicitly restricted to [a-z] * - 2.5 - HELD - -- / Medium - Sole-separator rule implicitly prevents hyphenated values * - 3.1 - HELD - -- / High - 1000 axioms x 20 models: tractable * - 3.2 - HELD - -- / Medium - 100 languages: tractable * - 3.3 - HELD - -- / High - 50 worldviews: tractable * - 3.4 - HELD - -- / Medium - 50 versions: tractable with automation * - 3.5 - HELD - -- / Low - Combinatorial explosion: stub policy handles it in theory * - 3.6 - HELD - -- / Medium - Build time: incremental builds handle development scale * - 4.1 - HELD - -- / Medium - Label memorability: shorthand forms provided * - 4.2 - HELD - -- / Medium - Prose confusion: model prefix handles disambiguation * - 4.3 - BREACH - Cosmetic / -- - Beginner onboarding: no quick-start guide * - 4.4 - HELD - -- / Low - Worldview sensitivity: no codes actively offensive * - 4.5 - BREACH - Minor / -- - Error messages: no label-testing tooling * - 5.1 - HELD - -- / Medium - DRY vs. compilation: standard build-artifact pattern * - 5.2 - **BREACH** - **Major** / -- - Include ban: live violation in ``axioms/index.rst`` * - 5.3 - **BREACH** - **Major** / -- - D7 language suffix conflicts with Sphinx i18n * - 5.4 - HELD - -- / Medium - Machine codes: D4 only, Set C is proof notation * - 5.5 - BREACH - Minor / -- - ``ref`` overloaded across 3 contexts **Totals:** - Total attacks: 29 - HELD: 17 - BREACH: 12 - Critical: 1 (Attack 1.6 --- D7/D6 collision analysis incomplete) - Major: 4 (Attacks 1.8, 2.2, 5.2, 5.3) - Minor: 6 (Attacks 1.3, 1.4, 1.7, 2.4, 4.5, 5.5) - Cosmetic: 1 (Attack 4.3) ---- Proposed Fixes ============== Minimal fixes for each BREACH, ordered by severity. No fixes proposed for HELDs. Fix for 1.6 (Critical): Complete D7/D6 Collision List ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Add all 8 double-letter ISO 639-1 codes to the collision table in AHA Section 10. Require these languages to use ISO 639-3 forms: .. list-table:: :header-rows: 1 :widths: 12 20 20 * - ISO 639-1 - Language - Required ISO 639-3 * - ``aa`` - Afar - ``aar`` * - ``ee`` - Ewe - ``ewe`` * - ``ff`` - Fulah - ``ful`` * - ``ii`` - Sichuan Yi - ``iii`` * - ``kk`` - Kazakh - ``kaz`` * - ``nn`` - Norwegian Nynorsk - ``nno`` * - ``ss`` - Swati - ``ssw`` * - ``tt`` - Tatar - ``tat`` Add a design rule: *Any ISO 639-1 code that matches D6 Set A pattern (two identical letters) MUST use its ISO 639-3 form instead. This is a closed, enumerable set (8 codes) that will not change unless ISO 639-1 is revised.* Fix for 1.8 (Major): Quest Label Grammar Extension ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Extend the D2 grammar rule to accommodate round numbers: :: {elementType}{itemNumber}[r{roundNumber}] Where ``r`` is a literal character within the D2 segment, applicable to types ``con`` and ``pro``. Document that ``r`` is NOT a dimension separator --- it is part of the D2 element identifier. Update the parser to handle the pattern: after extracting leading letters and digits, check for a trailing ``r`` + digits sequence. Fix for 2.2 (Major): Close D6 Set B ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Change D6 Set B from a structural definition (any 3+ letter string) to a closed registry (lookup-based). Add a design rule: *D6 Set B codes MUST be registered in the AHA document before use. Any token that does not match a registered D3, D4, D5, D6, or D7 code is a parse error.* This eliminates the catch-all behavior and enables typo detection. Fix for 5.2 (Major): Remove Include Violation ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Replace ``.. include::`` in ``axioms/index.rst`` with ``:doc:`` cross-references or compiled content (as the existing TODO indicates). This should be prioritized in Phase 3. As an interim measure, if the ``.. include::`` is retained, remove the label definitions from the included regions (use start-after/end-before markers that exclude labels), keeping labels only in the PoR source files. Fix for 5.3 (Major): Document D7/i18n Boundary ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Add a section to the AHA document specifying: 1. **Sphinx i18n** (``.po`` files) is used for TRANSLATION of existing content into other languages. Labels remain language-neutral (``pet-ax5`` in all languages). 2. **D7 language suffix** is used for CULTURALLY-ADAPTED content that differs structurally from the English version (not just by translation). Example: ``pet-ax5-easy-de`` is a German-specific beginner explanation that may differ in structure, examples, and cultural references from the English ``pet-ax5-easy``. 3. **Default path:** Most multilingual content uses Sphinx i18n. D7 suffixes are the exception, used only when cultural adaptation requires a structurally different document. Fix for 1.3 (Minor): State 2-Letter Invariant ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Add to AHA Section 3.1 (grammar rules): *D3 version codes, D4 depth codes, and D6 Set B codes MUST be at least 3 characters long. Two-character non-doubled tokens are reserved for D7 (language).* Fix for 1.4 (Minor): D4 Prefix Restriction ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Add to AHA Section 7: *D4 depth codes MUST NOT begin with ``v`` or ``s``, which are reserved prefixes for D5 view/source codes.* Fix for 1.7 (Minor): Bidirectional D1/D2 Constraint ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Change the design rule in AHA Section 5 from: "D2 codes MUST NOT equal any D1 model code." To: "D1 model codes and D2 element type codes MUST be mutually exclusive. Neither may equal any code in the other dimension's registry." Fix for 2.4 (Minor): D2 Letter-Only Rule ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Add to AHA Section 5: *D2 element type codes MUST contain only lowercase ASCII letters [a-z]. Digits are reserved exclusively for item numbers following the type code.* Fix for 4.5 (Minor): Label-Testing Tooling ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Specify that a label-linting script should be created (Phase 3) that: 1. Parses each ``.. _label:`` against the BEST Names grammar. 2. Reports which dimension each segment matched. 3. Flags unregistered codes, misordered dimensions, and structural violations. 4. Runs as part of ``make html`` or as a pre-commit hook. Fix for 5.5 (Minor): Disambiguate ``ref`` ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Rename D6 analytical code ``ref`` to ``xref`` (cross-reference) to distinguish it from D2 reserved ``ref`` (reference element type) and extraction matrix keyword ``ref`` (cross-reference inclusion mode). Alternatively, rename D2 reserved ``ref`` to ``reft`` (reference-to) if the D6 code is more established. Fix for 4.3 (Cosmetic): Quick-Start Guide ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Create a 1-page "BEST Names Cheat Sheet" with: - The label grammar (1 line). - The 12 example labels with annotations. - The 5 most common patterns (PoR, versioned, depth, view, full). - "When in doubt, use ``{model}-{element}`` and nothing else." ---- Overall Assessment ================== **Is the architecture sound enough for Phase 3 deployment?** **Yes, with the Critical and Major fixes applied first.** The architecture is fundamentally well-designed: the 7-dimension system is orthogonal, the label grammar is expressive, and the scalability ceiling is extremely high. The 17 HELDs demonstrate that the core structural properties (dimension separation, collision freedom between most dimension pairs, scalability) are solid. **However, the 1 Critical and 4 Major findings must be addressed before deployment:** 1. **Critical (1.6):** The D7/D6 collision list is incomplete. This is a factual error that can cause silent misparsing. Fix is mechanical: add 5 codes to the collision table. Estimated effort: 15 minutes. 2. **Major (1.8):** Quest labels violate the grammar. Fix requires a documented grammar extension. Estimated effort: 30 minutes to document, 0 minutes to implement (Sphinx already accepts the labels). 3. **Major (2.2):** D6 Set B catch-all absorbs typos. Fix requires changing Set B from structural to registry-based. Estimated effort: 1 hour to document and update the proof. 4. **Major (5.2):** Live ``.. include::`` violation. The TODO already indicates awareness. Fix is Phase 3 work (compiled pages). Interim mitigation: move labels outside the included regions. 5. **Major (5.3):** D7/i18n conflict. Fix is documentation-only: specify when each mechanism applies. Estimated effort: 30 minutes. **The 6 Minor and 1 Cosmetic findings are non-blocking** but should be addressed as part of the next design iteration to prevent future contributors from falling into the identified traps. **Bottom line:** The BEST Names architecture is ~80% deployment-ready. The Critical fix is trivial. The Major fixes are moderate effort. After these fixes, the architecture provides a solid foundation for a 100-year naming system. .. admonition:: TELES migration report (2026m04d04) Mechanical identifier migration applied to this file. All axiom/theorem text references were migrated from short form (e.g., A15) to compound form (e.g., ax15_A15) as part of the matheology compound naming operation. Both forms refer to the same formal object. The old form survives as the suffix to ensure consistency with the oldest records; the new form adds a temporary-status prefix. Forward-facing pages use brief form (ax15) only. See :ref:`hell-ll-other-b15-teles-renaming-prompt` for the complete mapping table and :ref:`legacy-5d-link-names-table-for-pet-jub-model` for the permanent reference.