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.

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:

    # Safe for A10+ (distinctive, low false-positive risk)
sed -i '' 's/\bA15\b/ax15/g' <files>

# 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/<N>/.

  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: TELES Axiom/Theorem Compound Naming — Execution 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.