.. meta:: :description: TELES renaming policy --- when and how to perform mechanical identifier migrations in LLogs and active content, with full cons/pros analysis. :keywords: TELES, renaming, identifier migration, policy, cons, pros, EDEN, compound naming, axiom, theorem, BABL, ZION :author: Yah, Yas, everyone, LLoL as Laurence Loewe of Laodicea, ClaudeOp46Max, Anthropic, and The Spirit of Boolean Truth .. _teles-renaming-policy: *********************************************************************** TELES Renaming Policy --- Mechanical Identifier Migrations *********************************************************************** This document defines when, why, and how TELES may perform mechanical identifier migrations --- operations that change the *surface form* of formal object references (axiom labels, theorem numbers, etc.) while preserving their *identity*. .. contents:: On this page :depth: 2 :local: ---- Why This Extension Exists =========================== Identifier renaming is not rare. In any long-lived project, naming conventions evolve as understanding deepens, scope expands, and new audiences arrive. The original TELES contract forbade all changes to formal content, including identifiers. This was too restrictive: it forced a choice between (a) living with problematic identifiers forever, or (b) creating a separate migration authority for each renaming, multiplying bureaucracy. The extended TELES contract allows controlled identifier migrations under strict conditions, recognizing that changing `A15` to `ax15` does not change what Axiom 15 *says* --- it changes how we *refer* to it. When to Use TELES for Renaming ================================ **Use TELES renaming when ALL of these hold:** 1. The formal objects are **unchanged** --- same axioms, same theorems, same content. Only the labels change. 2. The old identifier is **preserved** as a suffix, alias, or documented synonym. No information is lost. 3. The migration is **mechanical** --- a deterministic substitution, not an editorial judgment call. 4. The migration **solves a concrete problem** (parsing failures, ambiguity, systematic confusion, convention alignment). 5. The researcher in charge has **reviewed and approved** the scope. **Do NOT use TELES renaming when:** - The migration changes what an axiom/theorem *means* (true rename, not synonym) - The old identifier would be lost or made unsearchable - The migration requires editorial judgment about which references to change - The migration is purely cosmetic with no concrete benefit Cons and Pros of Mechanical Identifier Migrations ==================================================== Pro: Why Renaming Can Be ZION ------------------------------- 1. **Consistency reduces errors.** When all references use the same format, typos and mismatches are easier to detect. 2. **Self-documenting names reduce lookup cost.** A compound like ``ax15`` tells the reader both the temporary status (``ax``) and the legacy mapping (``ax15``) without consulting a table. 3. **Parsing safety.** Characters like ``'`` (apostrophe) in identifiers cause real problems in grep, URLs, databases, and cross-referencing tools. Removing them prevents silent failures. 4. **Explicit temporariness.** Lowercase ``ax`` signals "this number will change at finalization" --- preventing readers from citing a temporary number as if it were permanent. 5. **One migration now prevents N migrations later.** If the convention changes piecemeal over many sessions, each session pays a partial migration cost, and the codebase accumulates mixed conventions. One thorough migration is cheaper in total. Con: Why Renaming Can Be BABL ------------------------------- 1. **Blast radius.** A rename touching thousands of references across hundreds of files can introduce errors faster than it fixes them. Every substitution is a potential false positive. 2. **LLog immutability tension.** LLogs are append-only audit trails. Changing identifiers in them --- even mechanically --- means the llog no longer matches what was actually said during the session. The migration report documents this, but the tension remains. 3. **Readability cost.** Compound names like ``ax15`` are harder to read than ``ax15`` in running text. Dense passages with many axiom references become noticeably uglier. 4. **Double migration risk.** If the final numbering comes sooner than expected, the compound names will need updating again. Each migration has a nonzero error rate. 5. **Short identifiers (ax1--ax9) have high false-positive risk.** These patterns are common in non-axiom contexts (list items, headings, hexadecimal values, abbreviations). EDEN verdict: **Grey Edge.** The migration is defensible but not risk-free. The cons are manageable with careful execution (context-aware regex, manual review, batch-and-test). The pros are genuine but only pay off if the codebase is actively cited (which it will be, via papers a1--a7). Procedures for a TELES Renaming Session ========================================== Pre-flight ------------ 1. **Define the mapping table.** Every old→new substitution must be listed explicitly. No wildcards, no "and similar." 2. **Identify the scope.** Which files are affected? Separate into: - **Active content** (axioms.rst, theorems.rst, etc.) --- highest priority - **Historical llogs** --- mechanical consistency, reviewed post-hoc - **Generated/inventory pages** (socialcards) --- mechanical, low risk - **Static files** (HTML, PDF) --- may need separate handling 3. **Identify false-positive risks.** For each substitution pattern, list contexts where the pattern might match non-target text. Design regex to exclude those contexts. 4. **Build baseline.** Run ``make html`` and record the warning count. Execution ----------- 1. **Process in batches** (e.g., by axiom range: ax10--ax25 first, then ax1--ax9 with extra care). Build and test after each batch. 2. **Use word-boundary-aware regex.** Example: .. code-block:: bash # Safe for A10+ (distinctive, low false-positive risk) sed -i '' 's/\bA15\b/ax15/g' # For ax1-ax9, use context-aware matching # (preceded by "Axiom ", "axiom ", ".", or start of RST reference) 3. **Append migration report** to every modified file. 4. **Manual review** of ax1--ax9 changes --- check every substitution in context. Post-flight ------------- 1. **Build and test.** Warning count must not increase. 2. **Store the mapping table** permanently at a stable location (linked from the TELES documentation). 3. **Record the session** as an llog in ``hell/ll/teles/b//``. 4. **Update the Root Table** (BEST Names) with all synonym mappings. Reference: First TELES Renaming (Planned) ============================================ The first planned use of the TELES renaming extension is the axiom/theorem compound naming migration: - ``ax1`` → ``ax1`` through ``ax25`` → ``ax25`` - ``ax11b`` → ``ax11b`` (apostrophe elimination) - ``th1`` → ``th1`` through ``th11`` → ``th11`` - Papers and external citations use the brief form: ``ax15``, ``th8`` The execution prompt for this migration is stored at: :ref:`hell-ll-other-b15-teles-renaming-prompt` Future agents writing TELES renaming prompts should reference that prompt as a model for scope, structure, and safeguards. ---- *This policy was created on 2026m04d03 during the HELL Stability Review and FLAMES Restructuring session.*