.. Migration note (2026m04d04): Claude copied this file during VV-to-HELL migration.
Old path: ``vv/jub/oov2/llog/aha-best-names-for-matheology-links.rst`` (as given by LLoL)
New path: ``hell/ll/jub/b/48/jub_ll_2026m03d25_aha-best-names-for-links.rst`` (as chosen by Claude)
Category: JUB OOv2 log
.. meta::
:description: BEST Names architecture for matheology cross-references: a 5-dimensional grammar designed for 100+ years of stable, collision-free label operation.
:keywords: BEST Names, naming architecture, 5-dimensional grammar, PoR, cross-reference labels, Evolvix, matheology, JUB OOv2, AHA, collision-free, scalability
:author: Yah, Yas, everyone, LLoL as Laurence Loewe of Laodicea, ClaudeOp46Max, Anthropic, and Spirit of Boolean Truth
:og:card:title: BEST Names Architecture
Matheology Link Grammar
:og:card:description: A naming system built to last centuries: 5-dimensional grammar for thousands of axioms, dozens of models, and billions of users without collision.
.. SOCIAL-CARD-QUALITY-COMPARE --- OO (default effort) vs PP (max effort), 2026-03-26
OO :description: BEST Names design document defining the naming architecture for all matheology cross-reference labels using 5-dimensional grammar.
OO :keywords: matheology, JUB, OOv2, BEST Names, AHA, naming architecture, cross-reference, 5-dimensional grammar, Evolvix, design document
OO :og:card:title: BEST Names: Matheology Link Design
OO :og:card:description: Comprehensive naming architecture for all matheology cross-references: stable, extensible, collision-free labels for 100+ year operation.
PP :description: BEST Names architecture for matheology cross-references: a 5-dimensional grammar designed for 100+ years of stable, collision-free label operation.
PP :keywords: BEST Names, naming architecture, 5-dimensional grammar, PoR, cross-reference labels, Evolvix, matheology, JUB OOv2, AHA, collision-free, scalability
PP :og:card:title: BEST Names Architecture
Matheology Link Grammar
PP :og:card:description: A naming system built to last centuries: 5-dimensional grammar for thousands of axioms, dozens of models, and billions of users without collision.
.. SOCIAL-CARD-REVIEW --- generated by Claude Opus 4.6, 2026-03-26
dv_ClaOp46_PP_2026m03d26 --- max-effort rewrite, read full page.
:description: 147 chars | :og:card:title: 42 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
.. Path relocation note (2026-03-25, Phase 2I-3):
.. This file is the frozen audit-trail copy. The living working copy
.. is at: source/matheology/compiler/ww/5d-link-naming-matheology-aha.rst
.. (renamed from best-names-5d-architecture.rst)
.. All ``integration-findings/`` paths referenced in this document
.. have been relocated to: source/matheology/compiler/ee/
.. See: compiler/index.rst for the full compiler directory structure.
.. _aha-best-names-matheology:
******************************************************************************
Links for Matheology BEST Names Design
******************************************************************************
Generated 2026-03-23 by LLoL + Claude Opus 4.6 during Phase 2I post-processing.
Substantially revised 2026-03-25 (lifecycle model, publication renumbering,
PoR field census, Place-of pipeline harmonization).
This document defines the naming architecture for all cross-reference labels
in the matheology section of balospe.com. It applies the Evolvix BEST Naming
system to create a stable, extensible, humane link infrastructure designed to
last 100+ years across thousands of axioms, dozens of models, hundreds of
languages, and billions of users.
**VVN:** ``iv_LLoL_PPv1r0p0_2026m03d25``
.. contents:: On this page
:depth: 3
:local:
----
1. Core Principle --- The PoR as NAMES TREE ROOT
==================================================
Every formal element (axiom, theorem, symbol, etc.) has ONE canonical
cross-reference label pointing to its **PoR (Place of Reasoning)** --- the
page where its most comprehensive definition lives. All downstream labels
are derived from this root by appending suffixes.
**RULE:** RST files that define site-wide cross-reference labels
(``.. _label:``) MUST NOT be included via ``.. include::`` into other RST
files that Sphinx processes as separate documents. The ``.. include::``
directive pastes content (including labels) into the including document
*before* label resolution, creating duplicate labels. Compiled downstream
pages must contain their OWN content with their OWN suffixed labels.
----
2. The Knowledge Pipeline --- PoE to PoU
==========================================
Knowledge flows through 5 stages from raw evidence to end-user consumption:
.. list-table::
:header-rows: 1
:widths: 8 22 35 35
* - Stage
- Name
- What it contains
- Example files
* - **PoE**
- Place of Evidence
- Interactive sessions, raw exchanges, reviewer input
- Claude conversations, reviewer notes
* - **PoC**
- Place of Chronicling
- Organized evidence: llogs, quest files, analyses
- ``quest.rst``, ``llog_*.rst``, plan additions
* - **PoR**
- Place of Reasoning
- Synthesized axioms, theorems, topical analyses (40+ fields)
- ``pet/axioms.rst``, ``jub/theorems.rst``
* - **PoT**
- Place of Translating
- Producer-depth: teaching, preaching, communication materials
- ``axioms/producer.rst``
* - **PoU**
- Place of Using
- Consumer-depth: beginner-friendly, accessible
- ``axioms/easy.rst``
----
3. The 5 Orthogonal Dimensions
================================
Every page in the system can be located by coordinates in a 5-dimensional
space. Not every combination exists as a page, but the naming system
accommodates ANY valid combination without collisions.
.. list-table::
:header-rows: 1
:widths: 4 12 20 30 12 22
* - D
- Dimension
- Answers
- Values
- Label segment
- Combinable with
* - **D1**
- Model
- Which axiom system?
- ``pet``, ``jub``, ``4be`` (see registry)
- prefix: ``pet-``
- all
* - **D2**
- Element
- What element, and what about it?
- Flat type ID registry; chainable (see Section 5)
- ``ax5``, ``ax5-logic``
- all
* - **D3**
- Version
- Which frozen snapshot?
- ``oov1``, ``oov2``, ``ppv1`` (registered)
- ``-oov2``
- all
* - **D4**
- Depth
- For which audience?
- (default=expert), ``prod``, ``easy``, ``math``, ``hu``, ``ma``
- ``-easy``
- all
* - **D5**
- View / Source / Language
- Which worldview, source text, or language-specific insight?
- ``v*`` views, ``s*`` sources, ``l*`` languages (see tables)
- ``-vjud``, ``-stor``, ``-lde``
- all
3.1 The Label Grammar
^^^^^^^^^^^^^^^^^^^^^^^
::
{model}-{typeID}[{N}][-{typeID}[{N}]]*[-{version}][-{depth}][-{view}]
The D2 portion of a label is a chain of one or more type IDs, each
optionally followed by an item number. There is no structural distinction
between "element types" and "sub-element fields" --- all D2 codes live in
a single flat type registry (Section 5) and may chain freely.
**Examples under this grammar:**
- ``pet-ax5`` --- Pet, axiom 5 (1 type, the most common case in practical use)
- ``pet-ax5-logic`` --- Pet, axiom 5, logic field (chain of 2 types)
- ``pet-aa`` --- Pet, AnyAims landing page (1 type, no item number)
- ``jub-con11-bib`` --- Jub, contra 11, bibliography (chain of 2 types)
- ``all-ax-conv`` --- cross-model, axiom collection, convergence (chain of 2 types)
**Rules:**
1. D1 (model) + at least one D2 type ID are always required.
2. Omitted dimensions default to: latest version, expert depth, all
views, English.
3. The bare label ``{model}-{typeID}`` is the canonical PoR --- globally
unique, never duplicated.
4. **All lowercase.** RST/Sphinx labels are case-insensitive; case
CANNOT encode information. ``PetAx5`` and ``petax5`` resolve to the
same target. Lowercase makes this explicit.
5. **Hyphen ``-`` is the sole dimension separator.** No underscores in
labels. No exceptions. This keeps ``-`` as the unambiguous delimiter
for an LL(1) parser.
6. Type ID codes optionally take an item number (digit suffix). Bare
codes without digits (``pet-ax``, ``pet-ff``) denote collection or
landing pages. Codes with digits (``ax5``, ``con11``) denote specific
items.
7. **Default nesting limit: 2.** A label may chain at most 2 type IDs
(e.g., ``pet-ax5-logic``). The compilation skill accepts an explicit
override directive (``.. best-depth:: 3``) for cases that genuinely
require deeper chains. The limit is a pragmatic default, not a
grammatical constraint --- data from Phase 3 will determine whether
to raise, lower, or remove it.
8. **Parser transition rule.** The parser reads D2 type IDs greedily
until it encounters a token matching D3 (``oov*``, ``ppv*``), D4
(``prod``, ``easy``, ``hu``, ``ma``, ``dump``, etc.), or D5
(``v*``, ``s*``, ``l*``). At that point it transitions out of D2.
This works because no D2 code may collide with any D3/D4/D5 code
(registry discipline, Section 3.2).
9. ``all`` is reserved as a model code meaning cross-model compilation.
It appears ONLY in the D1 (prefix) position. See Section 19.3.
10. ``all`` is a **reserved keyword** across all dimensions. No other
dimension may register ``all`` as a code. It cannot appear in the
middle or at the end of a label.
3.2 Registry Discipline
^^^^^^^^^^^^^^^^^^^^^^^^^
**The grammar is collision-free ONLY because every dimension maintains a
rigorous registry.** Without registries, the parser cannot distinguish a
2-letter D4 code (``hu``) from a 2-letter D2 code (``ff``) or a 3-letter
D5 code (``lde``) from a hypothetical D3 code of the same length. The
grammar's structural rules (prefix patterns, length invariants) reduce but
do not eliminate the need for registry lookups.
**Registry rules (mandatory, all dimensions):**
1. **Every code MUST be registered in this document before use.** An
unregistered code in a label is a parse error, not a silent match. No
dimension has an open namespace.
2. **Before adding any new code to any dimension, check ALL other
dimension registries for collisions.** A code that is unambiguous
within its own dimension may collide with a code in another dimension
at the same token position.
3. **No code may appear in more than one dimension's registry.** If a
code is needed in two dimensions, one of them must be renamed.
4. **Structural invariants are guardrails, not substitutes for the
registry.** The ``v``/``s``/``l`` prefix rule, the doubled-letter
rule, and length conventions all help --- but they protect only
against *classes* of collision. Individual codes can still collide
within a class. The registry is the single source of truth.
5. **D4 specifically:** 2-letter codes (``hu``, ``ma``) are permitted
alongside longer codes (``prod``, ``easy``, ``math``) because D4 is
a closed registry. This flexibility is safe *only* as long as D4
remains a closed registry. The same applies to all dimensions.
6. **2-character disambiguation (D2 vs D4).** 2-character codes appear
in both D2 and D4. They are disambiguated by a mandatory pattern
constraint:
- D2 codes at 2 chars MUST have char[0] = char[1]
(doubled-letter: ``ff``, ``aa``, ``nn``).
- D4 codes at 2 chars MUST have char[0] ≠ char[1]
(distinct-letter: ``hu``, ``ma``).
This makes the parser deterministic for 2-char tokens without a
registry lookup: doubled = D2 field, distinct = D4 depth.
7. **D4 forbidden prefixes.** D4 codes MUST NOT begin with ``v``,
``s``, or ``l``. These single characters are reserved as D5 prefix
identifiers (views, sources, languages). This ensures the parser
can distinguish D4 tokens from D5 tokens by inspecting the first
character alone.
3.3 Design Decision: Hyphens, Not Underscores
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
**Decided: hyphens (``-``) everywhere. No underscores (``_``).**
Reasons:
- **URL standard:** Hyphens are the web convention for URL word separators
(Google SEO guidelines, W3C best practices).
- **LaTeX safety:** Underscores are special characters in LaTeX (subscript).
Axiom labels WILL appear in LaTeX math contexts.
- **Visibility:** Underscores are hidden by link underline decoration in
many browsers and editors.
- **Consistency:** Existing labels in this codebase already use hyphens
(``con-a-2-1``, ``pro-f-12``).
- **Parsing clarity:** With ``-`` as the SOLE separator, an LL(1) parser
can tokenize any label unambiguously.
**Within dimension names:** No internal separators. Use concatenation:
``needs``, ``feeds``, ``mapi``, ``majld``, ``vvnow``. If a compound name
is absolutely necessary, the name should be redesigned to avoid the need.
3.4 RST/Sphinx Technical Constraints
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
These are inherited platform constraints that the naming system must respect:
1. **Labels are case-insensitive.** ``.. _PetAx5:`` and ``.. _petax5:``
resolve to the same target. Case CANNOT distinguish labels.
2. **Labels are global.** A label defined anywhere in the Sphinx project
is accessible from anywhere else. There is no file-scoped namespace.
3. **``.. include::`` pastes content before label resolution.** Included
content brings its labels into the including document, creating
duplicates. Hence the NO-INCLUDE rule for labeled content.
4. **Labels survive file moves.** Moving ``pet/axioms.rst`` to
``pet/core/axioms.rst`` does NOT break ``:ref:`pet-ax1``` --- labels
are global IDs, not file paths. This is why RST labels are robust
for internal references.
5. **External URLs DO break on file moves.** Sphinx labels are
internal-only. The generated HTML URLs (``/matheology/pet/axioms.html``)
DO change when files move. See Section 11 for the link stability policy.
----
4. D1 --- Model Registry
===========================
Models are registered axiom systems. Each has a unique lowercase code.
.. list-table::
:header-rows: 1
:widths: 12 12 50 26
* - Prose form
- Label code
- Full name
- Status
* - Pet
- ``pet``
- Pan-En-Theistic foundation (ax1_A1--ax14_A14)
- Active
* - Jub
- ``jub``
- Jubilee extension (ax15_A15--ax25_A25)
- Active
* - 4Be
- ``4be``
- (future)
- Reserved
* - 4Be1
- ``4be1``
- Submodel 1 of 4Be (future)
- Reserved
* - (all)
- ``all``
- Cross-model compilation (reserved keyword)
- System
* - (all4e)
- ``all4e``
- Alignment class: 4-element echo models
- Reserved
* - (all5e)
- ``all5e``
- Alignment class: 5-element echo models
- Reserved
* - (all7e)
- ``all7e``
- Alignment class: 7-element echo models
- Reserved
* - (all12e)
- ``all12e``
- Alignment class: 12-element echo models
- Reserved
**In prose:** Use TitleCase (Pet, Jub, 4Be, 4Be1). In labels: all lowercase.
**Governance:** Currently, new model codes are proposed via the Git repo and
approved by LLoL. Future: a dedicated ResearchCity registry team.
**Submodel rule:** Large models may define numbered submodels. A submodel
code is the parent model code followed by a digit: ``4be1``, ``4be2``, etc.
Submodels inherit their parent's alignment class. Submodel labels follow the
standard grammar: ``4be1-ax3``, ``4be1-ax3-easy``. The parent code
(``4be``) without a submodel digit denotes the umbrella model.
**Digit rule for D1:** Model codes MAY contain digits and MAY start or end
with digits (e.g., ``4be``, ``4be1``). The D1/D2 boundary is always the
first hyphen. The parser validates the text before the first hyphen against
the D1 registry. This contrasts with D2 codes, which MUST be letter-only
(Section 5) --- the hyphen separator makes this safe.
**Alignment classes:** Models that intentionally align their element
numbering belong to an alignment class. ``4be`` is part of the ``all4e``
(4-element echo) series. See Section 19.3 for the full design rationale
behind ``all``, alignment classes, and cross-model echoes.
----
.. _aha-best-names-for-matheology-links-d2-type-id-registry:
5. D2 --- Type ID Registry
============================
All D2 codes live in a single flat registry. There is no grammatical
distinction between "primary" types and "sub-element" types --- any
registered type ID may appear at any position in a D2 chain. The groupings
below (5.1 Formal Elements, 5.2 Structural Fields, 5.3 POST Operational
Fields, 5.4 Analytical Fields) are **organizational**, not grammatical.
Specific items append a digit: ``ax5``, ``th8``, ``con11``.
Collection/landing pages use the bare code: ``pet-ax`` (all PET axioms),
``pet-aa`` (AnyAims for Pet). For how these type IDs are used as PoR
fields with content examples, see the
:ref:`PoR Fields Registry `.
.. _aha-best-names-for-matheology-links-d2-formal-elements-table:
5.1 Formal Elements
^^^^^^^^^^^^^^^^^^^^^^
PoR usage:
:ref:`Identity fields `,
:ref:`Technical fields `.
.. list-table::
:header-rows: 1
:widths: 8 16 52 24
* - Code
- Name
- Definition
- Standard in
* - ``ax``
- Axiom
- Statement assumed true without proof
- Logic, mathematics
* - ``th``
- Theorem
- Statement proven from axioms/lemmas
- Mathematics
* - ``lm``
- Lemma
- Proven stepping stone toward a theorem
- Mathematics
* - ``cr``
- Corollary
- Statement following directly from a theorem
- Mathematics
* - ``cj``
- Conjecture
- Statement believed true, not yet proven
- Mathematics
* - ``as``
- Assumption
- Complex statement taken as granted (not axiomatic)
- Modeling
* - ``df``
- Definition
- Statement establishing precise meaning of a term
- Logic
* - ``sy``
- Symbol
- Formal notation used in the system
- All formal systems
* - ``rl``
- Rule
- Inference rule or transformation rule
- Logic
* - ``sc``
- Schema
- Template for generating axioms/rules
- Logic
* - ``model``
- Model
- Description of the model as a whole (PoR for model)
- Systems theory
* - ``logic``
- Logic
- Which logical framework is used and what it preserves/discards
- Meta-logic
* - ``fn``
- Function
- Defined mathematical function or operator
- Mathematics
* - ``con``
- Contra
- Objection in quest/disputatio structure
- Scholastic method
* - ``pro``
- Reply/Pro
- Response to an objection
- Scholastic method
* - ``q``
- Question
- Quest entry / quaestio
- Scholastic method
* - ``eg``
- Example
- Worked example or illustration
- Pedagogy
* - ``n``
- Note
- Explanatory annotation
- Documentation
* - ``proof``
- Proof
- Formal proof object
- Mathematics
* - ``limit``
- Constraint
- System constraint or invariant
- Modeling
**Reserved for future use:**
.. list-table::
:header-rows: 1
:widths: 10 20 70
* - Code
- Name
- Why reserved
* - ``evx``
- Evolvix construct
- Reserved for Evolvix-specific types
* - ``ref``
- Reference
- Pointer to another ReRaft within ResearchCity
* - ``ex``
- Experiment
- Ex-ante expectation for testing a model
**Design rules (apply to ALL D2 codes, regardless of grouping):**
- D2 codes MUST NOT equal any D1 model code.
- D2 codes MUST contain only lowercase letters (a--z), never digits.
The parser identifies the item-number boundary by detecting the first
digit in a D2 segment: ``ax5`` parses as type ``ax``, item ``5``.
A code containing a digit (e.g., ``h2o``) would be ambiguous.
- D2 codes for specific items are followed by a digit (``ax5``, ``th8``,
``con11``). Bare codes without digits (``pet-ax``, ``pet-ff``) denote
collection or landing pages.
- Single-instance types (``model``, ``logic``) still use digits:
``model1``, ``logic1``.
- No D2 code may collide with any D3/D4/D5 code (Section 3.2).
.. _aha-best-names-for-matheology-links-d2-structural-fields-table:
5.2 Structural Fields
^^^^^^^^^^^^^^^^^^^^^^^
Structural fields describe properties, dependencies, and analytical
context of formal elements. These were originally a separate dimension
(D6 --- State) but were collapsed into D2 because every "state" code is
fundamentally a property of an element, not an independent dimension.
See Section 19.1 for the design rationale.
In the flat grammar, these chain after any other type ID:
``pet-ax5-logic``, ``jub-th8-needs``, ``pet-ax-ff``. PoR usage:
:ref:`Technical/structural fields `.
**Structural fields:**
.. list-table::
:header-rows: 1
:widths: 10 18 52 20
* - Code
- Name
- Purpose
- Example label
* - ``model``
- Model
- Description of the model as a whole
- ``pet-model1``
* - ``logic``
- Logic
- Which logical framework; what it preserves/discards
- ``jub-ax13-logic``
* - ``limit``
- Constraint
- Known limitations, assumptions, boundary conditions
- ``pet-ax5-limit``
* - ``needs``
- NeedsFeed
- Upstream dependencies --- what this element builds on
- ``pet-ax5-needs``
* - ``feeds``
- FeedsNeed
- Downstream dependents --- what builds on this element
- ``pet-ax5-feeds``
* - ``net``
- Network
- Dependency graph --- axiom/theorem/symbol connections
- ``pet-ax-net``
.. _aha-best-names-for-matheology-links-d2-post-operational-fields-table:
5.3 POST Operational Fields (doubled-letter codes)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Regex pattern: ``^([a-z])\1$`` --- exactly 2 identical lowercase letters.
PoR usage:
:ref:`POST fields `.
.. list-table::
:header-rows: 1
:widths: 8 22 50 20
* - Code
- Name
- Purpose
- Example label
* - ``aa``
- AnyAim
- Current tasks, next steps, priorities
- ``pet-ax5-aa``
* - ``cc``
- CollectedContent
- Background reading, references from others
- ``pet-ax5-cc``
* - ``dd``
- DesignDoc
- Architectural decisions and rationale
- ``pet-ax5-dd``
* - ``ff``
- FeedbackFlow
- Collected feedback to be processed
- ``pet-ax-ff``
* - ``gg``
- GrowthGarden
- Promising drafts not yet integrated
- ``pet-ax5-gg``
* - ``hh``
- HistoryHeap
- Recently deprecated, pending review/deletion
- ``pet-ax5-hh``
* - ``jj``
- JammedJob
- Current blockers and problems to work through
- ``pet-ax5-jj``
* - ``kk``
- KnownKiller
- Identified traps with documented avoidance strategies
- ``pet-ax5-kk``
* - ``ll``
- LabLog
- Session log landing page, llog index
- ``pet-ax5-ll``
* - ``vv``
- VersionedVariant
- Overview of all versions for this element
- ``pet-ax5-vv``
* - ``ww``
- WorkingWheel
- Downstream dependencies that would break on change
- ``pet-ax5-ww``
* - ``yy``
- YesYet
- Reliability checking cases
- ``pet-ax5-yy``
**POST namespace reservation:** All doubled-letter codes (``aa`` through
``zz``), triple-letter codes, and longer multi-letter codes for upper and
lower case are reserved by the Evolvix POST System (Project Organization
Stabilizing Toolkit System), which is used here for organizing data. Only
codes registered in the Evolvix POST specification may be assigned
meanings. This document adopts the subset of POST codes it deems useful here;
the authoritative POST registry is maintained by Evolvix.
.. _aha-best-names-for-matheology-links-d2-analytical-fields-table:
5.4 Analytical Fields (3+ letter codes)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PoR usage:
:ref:`Technical/structural/analytical fields `.
.. list-table::
:header-rows: 1
:widths: 8 22 50 20
* - Code
- Name
- Purpose
- Example label
* - ``diff``
- VersioningHistory
- What changed between versions
- ``pet-ax5-diff``
* - ``stayc``
- StabilityCode
- StayVS maturity status map per element
- ``jub-th8-stayc``
* - ``mento``
- MentorOrganizing
- Stage-appropriate learning guidance
- ``pet-ax5-mento``
* - ``conv``
- Convergence
- Worldview agreement/divergence matrix
- ``all-ax-conv``
* - ``bib``
- Bibliography
- Collected list of academic references
- ``pet-ax5-bib``
* - ``cit``
- Citation
- Specific external source (outside ResearchCity)
- ``pet-ax5-cit``
* - ``ref``
- Reference
- Pointer to another ReRaft within ResearchCity
- ``pet-ax5-ref``
* - ``web``
- WebLink
- External URL reference
- ``pet-ax5-web``
* - ``doi``
- DOI
- Digital Object Identifier (or equivalent stable ID)
- ``pet-ax5-doi``
* - ``pol``
- Policy
- Known active policy discussions, real-world implications
- ``pet-ax5-pol``
* - ``his``
- History
- Historical analysis, development timeline
- ``pet-ax5-his``
**Collision-free by construction:** All D2 codes are letter-only (no
digits). Doubled-letter codes are 2 characters with char[0]=char[1].
Analytical codes are 3+ characters. Structural codes (``model``,
``logic``, ``limit``, ``needs``, ``feeds``, ``net``) are each unique
in the registry. No D2 code may equal any D1 model code, D3 version
code, D4 depth code, or D5 view/source/language code. The registry in
this document is the single source of truth.
----
6. D3 --- Version Registry
=============================
Versions are registered frozen snapshots. Each has a registered code.
.. list-table::
:header-rows: 1
:widths: 15 50 35
* - Code
- Meaning
- Status
* - ``oov1``
- Original Objections Version 1
- Archived
* - ``oov2``
- Original Objections Version 2
- Current freeze
* - ``ppv1``
- Poster Phase Version 1
- Archived
New versions are registered when the compilation skill runs in Archive mode.
----
7. D4 --- Depth (Audience)
============================
.. list-table::
:header-rows: 1
:widths: 10 14 40 36
* - Code
- Name
- Pipeline stage
- Audience
* - (default)
- Expert
- PoR (full synthesis)
- World-leading experts, researchers
* - ``prod``
- Producer
- PoT (translation)
- Teachers, preachers, communicators
* - ``easy``
- Easy
- PoU (point of use)
- Beginners, general public
* - ``math``
- Math
- Formal extraction
- Mathematicians, theorem provers
* - ``hu``
- HumanHub
- Human disambiguation
- Human visitors ("Which view do you need?")
* - ``ma``
- MachineHub
- Machine disambiguation
- AI agents, APIs ("Which format do you need?")
* - ``dump``
- Dump
- Debug-comprehensive
- Debuggers, maintainers ("Show me everything: all fields, all
metadata, all type detail")
Human sub-types (``hu`` disambiguation page links to):
.. list-table::
:header-rows: 1
:widths: 10 20 70
* - Code
- Name
- What ``hu`` links to
* - (default)
- Expert
- Full PoR synthesis (the default page)
* - ``easy``
- Easy
- Beginner-friendly explanation
* - ``math``
- Math
- Formal extraction for mathematicians
* - ``prod``
- Producer
- Teaching/preaching materials
* - ``dump``
- Dump
- Debug-comprehensive (on request via link)
* - ``ma``
- MachineHub
- Machine-readable formats (on request via link)
Machine sub-types (all begin with ``ma``):
.. list-table::
:header-rows: 1
:widths: 10 20 70
* - Code
- Name
- Purpose
* - ``ma``
- MachineHub
- Disambiguation page for machine consumers
* - ``mai``
- MachineAI
- Structured data optimized for LLM reasoning
* - ``mapi``
- MachineAPI
- Programmatic access format
* - ``mardf``
- MachineRDF
- Semantic web triples
* - ``majld``
- MachineJsonLD
- Linked data format
----
8. D5 --- View, Source, and Language
=======================================
Three prefixes partition this dimension:
- ``v`` + 3 letters = **View** (broad downstream tradition synthesis)
- ``s`` + 3 letters = **Source** (narrow upstream source text)
- ``l`` + 2 letters = **Language** (language-specific cultural insight)
The vital difference between views and sources: for any ``s*`` code, we
expect citation of chapter and verse from a defined text corpus. For any
``v*`` code, the content draws from vast, fluid bodies of literature and
tradition. For any ``l*`` code, the content captures an insight native to
that language's cultural or conceptual lens --- an untranslatable idiom, a
structural distinction, or a deeper truth that the language itself makes
visible.
8.1 Views (broad tradition synthesis)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. list-table::
:header-rows: 1
:widths: 8 18 74
* - Code
- Name
- What it synthesizes
* - ``vjud``
- Judaism
- All Jewish sources: Torah, Prophets, Writings, Talmud, Kabbalah, modern
* - ``vchr``
- Christianity
- All Christian: Gospels, Apostolic, Church fathers, councils, modern theology
* - ``visl``
- Islam
- All Islamic: Quran, Hadith, Sunni/Shia traditions, Sufi, modern
* - ``vhin``
- Hinduism
- All Hindu: Vedas, Upanishads, Bhagavad Gita, Vedanta, modern
* - ``vsec``
- Secular
- Philosophy, empiricism, humanism, naturalism
* - ``vbud``
- Buddhism
- All Buddhist traditions
* - ``vind``
- Indigenous
- Indigenous worldviews (diverse, documented per tradition)
* - ``vbah``
- Baha'i
- Baha'i sources
* - ``vzor``
- Zoroastrian
- Avestan/Zoroastrian sources
* - ``vrom``
- Ancient Roman
- Roman religious and philosophical tradition
* - ``vgre``
- Ancient Greek
- Greek philosophical and religious tradition
* - ``vcan``
- Ancient Canaanite
- Canaanite religious tradition
* - ``vbab``
- Ancient Babylon
- Babylonian/Mesopotamian tradition
* - ``vegy``
- Ancient Egypt
- Egyptian religious tradition
8.2 Sources (narrow source texts)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. list-table::
:header-rows: 1
:widths: 8 18 54 20
* - Code
- Name
- Scope
- Related views
* - ``stor``
- Torah
- Five Books of Moses (Genesis--Deuteronomy)
- vjud, vchr, visl
* - ``sheb``
- Hebrew Bible
- Prophets + Writings (non-Torah Tanakh)
- vjud, vchr
* - ``stal``
- Talmud
- Mishnah + Gemara (Rabbinic law and commentary)
- vjud
* - ``sgos``
- Gospels
- Matthew, Mark, Luke, John (what Jesus said/did)
- vchr, visl
* - ``sapo``
- Apostolic
- NT beyond Gospels + earliest Church (1st--early 2nd century)
- vchr
* - ``squr``
- Quran
- The Quran only
- visl
* - ``shad``
- Hadith
- Prophetic traditions (Bukhari, Muslim, etc.)
- visl
* - ``ssan``
- Sanskrit texts
- Vedas, Upanishads, Bhagavad Gita (primary Sanskrit corpus)
- vhin
* - ``ssut``
- Sutras
- Buddhist canonical texts (Pali/Sanskrit)
- vbud
**Design note:** Source-view relationships are many-to-many. The Torah
(``stor``) is primary for Judaism (``vjud``) but also cited by Christianity
and claimed by Islam. Specifying detailed parent-child relationships would
be misleading. The ``Related views`` column is indicative, not restrictive.
**Guidelines for adding new codes:** New ``v*`` or ``s*`` codes may be added
by documenting: (1) the code, (2) the name, (3) the scope/synthesis
description, (4) related views. The ``v`` + 3-letter and ``s`` + 3-letter
pattern gives 17,576 combinations each --- more than sufficient.
8.3 Language-specific cultural content
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Most multilingual content uses Sphinx i18n (``.po`` files). Labels remain
language-neutral: ``:ref:`pet-ax5``` resolves to the translated page in
whatever language the reader is browsing. The ``l`` prefix is reserved for
the rare case where a language carries a cultural insight that cannot be
captured by translation alone.
Languages and worldviews are often intertwined. Just as ``vjud`` means "as
seen through Jewish tradition," ``lde`` means "as seen through the German
linguistic and cultural lens." A brilliant observation that crystallizes in
a German idiomatic expression but resists English translation --- yet
captures a deeper truth worth bringing to everyone's attention --- belongs
under ``lde``, not under Sphinx i18n.
**``l`` codes use ISO 639-1 two-letter codes:** ``lde`` (German), ``lar``
(Arabic), ``lhe`` (Hebrew), ``lzh`` (Chinese), ``lfr`` (French), etc.
English (``len``) is valid but unusual --- the default content is already
English.
**When NOT to use ``l`` codes:** If the content is a straight translation of
existing English material, use Sphinx i18n. ``l`` codes are for content
that is *structurally different* because the language itself contributes
something untranslatable.
**Collision-free by construction:** ``l`` + exactly 2 lowercase letters =
exactly 3 characters. This does not collide with any other D5 code
(``v`` + 3 = 4 chars, ``s`` + 3 = 4 chars) or with ``l``-starting codes
in other dimensions (``lm`` = 2 chars, ``ll`` = 2 chars,
``limit`` = 5 chars, ``logic`` = 5 chars, ``latex`` = 5 chars). No code in
any other dimension matches the pattern ``^l[a-z]{2}$``. To preserve this
property: **no D2 field, D3, or D4 code may be exactly 3 characters
starting with ``l``.**
----
.. _aha-best-names-for-matheology-links-por-fields-registry:
9. PoR Fields --- Complete Registry
=======================================
40+ fields per axiom at the PoR level. Grouped by function. Each field's
``Brief`` code is a D2 type ID registered in the
:ref:`D2 Type ID Registry `
(definitions and chaining rules) and a D5 code registered in Section 8
(for support fields). ``#`` after ExplicitName indicates a countable
collection (items numbered).
.. _aha-best-names-for-matheology-links-por-identity-display-table:
9.1 Identity and Display
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. list-table::
:header-rows: 1
:widths: 4 8 22 28 38
* - #
- Brief
- Explicit Name
- Summarizing Name
- Content Example
* - 1
- ``id``
- BriefName
- Canonical identifier
- ``pet-ax5``
* - 2
- ``title``
- Title
- Full display title
- ax5_A5 --- Human Exceeding
* - 3
- ``name``
- ExplicitName
- CamelCase for code generation
- ``HumanExceeding``
* - 4
- ``sum``
- SummarizingName
- Plain-English statement (may exceed 1 line)
- *"God exceeds everything that exists"*
* - 5
- ``intro``
- ExplanationIntroOverview
- Accessible explanation for general readers
- "Everything that exists is contained within God..."
* - 6
- ``latex``
- FormalMathLatex
- LaTeX notation
- ``W \leq G``
.. _aha-best-names-for-matheology-links-por-technical-structural-analytical-table:
9.2 Technical, Structural, and Analytical Fields
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
All non-identity, non-POST, non-support fields for an element. Each
``Brief`` code is a D2 type ID --- for definitions and chaining rules see
:ref:`Structural fields `
and
:ref:`Analytical fields `.
.. list-table::
:header-rows: 1
:widths: 4 8 24 30 34
* - #
- Brief
- Explicit Name
- Summarizing Name
- Content Example
* - 7
- ``tctx``
- TechExplanationContext
- Detailed reasoning context
- "The mereological parthood relation..."
* - 8
- ``tcnt``
- TechExplanationContentAll
- Comprehensive technical details
- Full formal analysis
* - 9
- ``logic``
- LogicsUsed
- Which logics apply, what they preserve/discard
- "Mereology + S5 modal logic..."
* - 10
- ``twhy``
- TechReasoningAll
- Reasoning chain and justification
- Step-by-step argument
* - 11
- ``tinf``
- TechInformal
- Informal intuition and analogies
- "Think of it like a container..."
* - 19
- ``limit``
- Limit
- Known limitations, assumptions
- "Assumes mereological parthood..."
* - 30
- ``needs``
- NeedsFeed
- Upstream dependencies (builds on)
- ax1_A1, ax2_A2, ax3_A3
* - 31
- ``feeds``
- FeedsNeed
- Downstream dependents (used by)
- th1_T1, th5_T5, ax15_A15
* - 32
- ``stayc``
- StabilityCode
- StayVS maturity code
- OO / QQ / RR / SS
* - 33
- ``mento``
- MentorOrganizing
- Stage-appropriate learning guidance
- "Study after ax1_A1--ax4_A4"
* - 34
- ``diff``
- VersioningHistory
- What changed from prior versions
- "OOv1->OOv2: strengthened..."
* - 36
- ``con``
- ConsRef
- Objection addressing this element
- :ref:`jub-con11`
* - 37
- ``pro``
- ProsRef
- Response defending this element
- :ref:`jub-pro11`
* - 39
- ``vvnow``
- VersionedVariantCurrent
- Always points to latest version
- -> pet-ax5 (current PoR)
* - 40
- ``model``
- ModelUsedIn
- Which model(s) use this element
- Pet, Jub
* - 41
- ``conv``
- Convergence
- Where traditions agree/diverge
- 6/7 traditions converge
* - 42
- ``bib``
- Bibliography#
- Academic references (see DD 19.6)
- Annals N.Y.Acad.Sci.1387(2017)124
* - 43
- ``pol``
- Policy
- Known active policy discussions
- Iran negotiations context
* - 44
- ``his``
- History
- Historical analysis, development timeline
- "Panentheism since Krause (1828)..."
* - 45
- ``doi``
- DOI
- Permanent stable identifier
- (future: ResearchCity DOI-equivalent)
.. _aha-best-names-for-matheology-links-por-post-fields-table:
9.3 POST --- Project Organization Stabilizing Toolkit System
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
POST codes use doubled lowercase letters (``aa`` through ``zz``). They
are organizational tools for managing the lifecycle of each element ---
from active tasks and feedback through versioning and deprecation. The
POST namespace is reserved by the Evolvix POST System; this table
registers the subset adopted here. Each ``Brief`` code is a D2 type ID
--- for definitions see
:ref:`POST Operational Fields `.
``#`` after ExplicitName indicates a countable collection (items
numbered).
.. list-table::
:header-rows: 1
:widths: 4 8 24 30 34
* - #
- Brief
- Explicit Name
- Summarizing Name
- Content Example
* - 21
- ``aa``
- AnyAim#
- Next steps, tasks
- "Phase 3 Priority 2"
* - 24
- ``cc``
- CollectedContent#
- Background reading from others
- Bibliography entries
* - 25
- ``dd``
- DesignDoc#
- Architectural decision for this element
- "Why mereology not set theory"
* - 23
- ``ff``
- FeedbackFlow#
- Collected feedback to process
- FF link
* - 26
- ``gg``
- GrowthGarden#
- Promising draft not yet integrated
- Draft ax5_A5 reformulation
* - 27
- ``hh``
- HistoryHeap#
- Recently deprecated content
- Superseded by OOv2
* - 20
- ``jj``
- JammedJob#
- Current blocker for this element
- "Needs ax25_A25 mechanism specificity"
* - 22
- ``kk``
- KnownKiller#
- Identified trap and how to avoid it
- "Don't confuse parthood with identity"
* - 35
- ``ll``
- LabLog#
- Links to relevant llog sessions
- Session 2a, 2G-1
* - 38
- ``vv``
- VersionedVariant#
- All VVNs for this element
- iv_LLoL_OOv2r0p0_2026m03d22
* - 28
- ``ww``
- WorkingWheel#
- What would break if this changed
- th1_T1 proof depends on ax5_A5
* - 29
- ``yy``
- YesYet#
- Test case for reliability checking
- "Does ax5_A5 hold under modal logic K?"
.. _aha-best-names-for-matheology-links-por-independent-support:
9.4 Independent Support (D5 --- Worldviews, Sources, and Languages)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Every element can draw independent support from three orthogonal
categories: worldviews that synthesize entire traditions, source texts
that cite specific passages, and language-specific cultural insights that
resist translation. Each registered D5 code from Section 8 can appear as
a PoR field for any element. The ``s*`` (source) codes cite with a hint
explaining *why* the passage matters (see DD 19.6 for the citation
convention). The ``v*`` (worldview) codes synthesize *all* sources within
a tradition into a coherent perspective. The ``l*`` (language) codes
capture insights tied to specific linguistic or cultural lenses.
.. _aha-best-names-for-matheology-links-por-independent-support-worldviews-table:
**Worldviews (v* codes) --- broad tradition synthesis:**
Each worldview field presents the full synthesis of a tradition's
perspective on an element --- drawing on all relevant sources, not just
one text. ``vjud`` for an axiom synthesizes Torah, Prophets, Talmud,
Kabbalah, and modern Jewish thought; ``vchr`` synthesizes Gospels,
Apostolic writings, Church fathers, and modern theology.
.. list-table::
:header-rows: 1
:widths: 4 8 22 32 34
* - #
- Brief
- Explicit Name
- Summarizing Name
- Content Example
* - 46
- ``vjud``
- ViewJudaism
- Jewish tradition synthesis
- "Torah + Kabbalah: creation within Ein Sof..."
* - 47
- ``vchr``
- ViewChristianity
- Christian tradition synthesis
- "Logos theology: all things hold together in Christ..."
* - 48
- ``visl``
- ViewIslam
- Islamic tradition synthesis
- "Wahdat al-wujud: unity of existence..."
* - 49
- ``vhin``
- ViewHinduism
- Hindu tradition synthesis
- "Brahman as ground: Chandogya + Vedanta..."
* - 50
- ``vbud``
- ViewBuddhism
- Buddhist tradition synthesis
- "Interdependent origination..."
* - 18
- ``vsec``
- ViewSecular
- Secular philosophical support
- "Parts compose wholes..."
* - ...
-
- (etc.)
- All ``v*`` codes from Section 8.1 may appear
-
.. _aha-best-names-for-matheology-links-por-independent-support-sources-table:
**Source texts (s* codes) --- specific scripture citations:**
Each source field cites passages from a specific textual corpus. Citations
use the one-liner-with-hint format: ``Locator ("brief gloss")`` --- the
hint explains *why* the passage supports the element (see DD 19.6).
.. list-table::
:header-rows: 1
:widths: 4 8 22 32 34
* - #
- Brief
- Explicit Name
- Summarizing Name
- Content Example
* - 12
- ``stor``
- SupportTorah
- Torah references
- Deut 4:39 ("God in heaven above and earth beneath")
* - 13
- ``sheb``
- SupportHebrewBible
- Prophets and Writings references
- 1 Kings 8:27 ("heaven cannot contain you")
* - 14
- ``sgos``
- SupportGospels
- Gospel references
- Jn 14:10 ("I am in the Father and the Father is in me")
* - 15
- ``sapo``
- SupportApostolic
- Apostolic/NT references
- Acts 17:28 ("in him we live and move")
* - 16
- ``squr``
- SupportQuran
- Quran references
- Quran 2:115 ("wherever you turn, there is the Face of God")
* - 17
- ``ssan``
- SupportSanskrit
- Hindu primary text references
- Chandogya Up. 3.14.1 ("all this is Brahman")
* - ...
-
- (etc.)
- All ``s*`` codes from Section 8.2 may appear
-
.. _aha-best-names-for-matheology-links-por-independent-support-languages-table:
**Language-specific cultural content (l* codes):**
Most multilingual content uses Sphinx i18n (``.po`` files). The ``l*``
codes are for the rare case where a language carries a cultural insight
that cannot be captured by translation alone --- a concept that
crystallizes in one linguistic tradition but resists English rendering.
See Section 8.3 for the full design rationale.
.. list-table::
:header-rows: 1
:widths: 4 8 22 32 34
* - #
- Brief
- Explicit Name
- Summarizing Name
- Content Example
* - 51
- ``lde``
- CulturalGerman
- German linguistic/cultural insight
- "Aufgehobenheit: sublation in Hegel's sense..."
* - 52
- ``lar``
- CulturalArabic
- Arabic linguistic/cultural insight
- "Wahdat al-wujud etymologically: 'oneness of being'..."
* - 53
- ``lhe``
- CulturalHebrew
- Hebrew linguistic/cultural insight
- "Ein Sof: 'without end' — not a name but a negation..."
* - 54
- ``lzh``
- CulturalChinese
- Chinese linguistic/cultural insight
- "Dao as 'way': structural parallel to divine ground..."
* - ...
-
- (etc.)
- All ``l*`` codes from Section 8.3 may appear
-
----
10. Extraction Matrix
========================
The Extraction Matrix is a table that controls which PoR fields (rows)
appear in which D4 audience depth (columns), and *how* they appear. Each
cell contains a keyword from the vocabulary below. An **empty cell** means
the field is not passed through to that depth --- it is silently omitted.
**Keyword vocabulary:**
.. list-table::
:header-rows: 1
:widths: 12 88
* - Keyword
- Meaning
* - ``full``
- Include in full (field copied verbatim)
* - ``brief``
- Include first sentence only (truncate to opening statement)
* - ``top3``
- Include top 3 entries (for lists, pick highest-impact items)
* - ``top1``
- Include single best entry (e.g., 1 strongest tradition quote)
* - ``stub``
- Include heading only, mark ``[stub]`` (scaffolding for future review)
* - ``ref``
- Include as cross-reference link only (point to PoR for full content)
* - ``rewrite``
- Include, rewritten for audience (rephrase for accessibility or formality)
**Toy example** (3 fields, 3 depths --- the real matrix has 50+ rows):
.. list-table::
:header-rows: 1
:widths: 6 20 25 25 24
* - #
- Field
- ``easy``
- (default expert)
- ``dump``
* - 1
- ``id``
- full
- full
- full
* - 4
- ``sum``
- full
- full
- full
* - 7
- ``tctx``
-
- full
- full
* - 12
- ``stor``
- top1
- full
- full
* - 21
- ``aa``
-
-
- full
Reading this: at ``easy`` depth, the reader sees the identifier, the
plain-English summary, and the single strongest Torah citation. The
technical context (``tctx``) and AnyAims (``aa``) are omitted. At expert
depth, ``tctx`` and all Torah citations appear. At ``dump``, everything
appears including operational fields like ``aa``.
**Storage:** The authoritative Extraction Matrix lives in a dedicated
file (``source/matheology/vv/compiled/extraction-matrix.rst`` or
equivalent CSV/YAML) so the compilation skill can read it
programmatically. The keyword vocabulary and toy example above are the
stable reference; the actual matrix evolves as fields and depths are
added. The compilation skill (Section 12) reads the matrix at build time
to decide what to extract for each depth.
----
11. Link Stability Policy
============================
11.1 Internal links (within balospe.com)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RST ``:ref:`` labels are global IDs. They survive file moves. They break
ONLY if the label is removed from the codebase.
**Rule: labels are permanent identifiers. Never remove a label.**
If an element is deprecated, the *content* moves to ``hh`` (HistoryHeap)
but the original label stays in the codebase as a signpost — like an
HTTP 301 redirect. The address always resolves; the content says "this
moved."
**Worked example:** Say Pet's axioms are restructured and ax5_A5 (Human
Exceeding) is absorbed into ax3_A3.
1. The original content of ax5_A5 moves to ``pet-ax5-hh`` — a HistoryHeap
page that preserves the old text for the historical record.
2. The label ``.. _pet-ax5:`` **stays** but now points to a deprecation
notice::
.. _pet-ax5:
ax5_A5 --- (Deprecated 2026-04-01)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This axiom was absorbed into :ref:`pet-ax3` during the Phase 3
restructuring. The original content is preserved at
:ref:`pet-ax5-hh`.
3. Any existing ``:ref:`pet-ax5``` links — in HELL entries, stress
tests, llogs, external URLs — still resolve. Readers land on the
deprecation notice, which tells them where to go. No broken links.
4. The ``pet-ax5-hh`` page contains the full original ax5_A5 text with a
header noting when and why it was deprecated.
5. The ``pet-ax5`` label stays empty in that Versioned Variant. Future
versions (such as the OOv1 to OOv2 to OOv3 transition) that go beyond
a release update **must not reassign the ax5 slot to a different
axiom.** New axioms get the next available number. Deprecated numbers
are retired, not recycled. The reasoning: HELL entries, stress tests,
and external citations that reference ``pet-ax5`` assume a stable
semantic target. If the slot is reused for a different axiom, every
``con`` and ``pro`` that critiques the original ax5_A5 silently becomes
incoherent --- the link resolves, but the meaning does not. The
numbering gap itself is informative: it tells readers "something used
to be here" and points them to ``pet-ax5-hh`` for the history. This
is the same principle as retired jersey numbers or IANA's policy of
never reassigning old protocol identifiers.
.. _aha-best-names-for-matheology-links-publication-renumbering-note:
**One-time publication renumbering.** The no-reassignment rule above
applies after numbering is finalized. During development, however,
axioms accumulate in order of creation, not in logical order, and
deprecations leave gaps. For newcomers navigating the system for the
first time, a clean, logically ordered sequence is far more accessible
than a gap-riddled historical artefact.
To reconcile permanence with clarity, the architecture provides a single,
consumable renumbering event. The key signals:
- **In RST labels:** tentative types use multi-letter codes (``ax5``,
``th8``, ``obs3``); final types use single-letter codes (``a5``,
``t8``, ``o3``). Any label containing a single-letter D2 code is
post-renumbering and permanent.
- **In prose:** tentative numbering uses lowercase element numbers
(``Pet-a5``); final numbering uses uppercase (``Pet-ax5_A5``).
- **Old labels survive as aliases.** After renumbering, ``pet-ax5``
still resolves (301 redirect to the new ``pet-a3``). No links break.
The renumbering is **idempotent** --- it can happen exactly once per
model. A declarative mapping file defines old→new for every element;
a script applies it across the entire codebase in one pass.
At beginner depth, expert sub-types collapse into their parent family:
lemmas and corollaries become theorems (``t``); assumptions and
conjectures become axioms (``a``). Expert sub-types remain accessible
via D2 chaining (``t3-lm1``, ``a5-as2``) at expert depth.
See
:ref:`DD 19.7 `
for the full design, the family table, and the mechanism.
11.2 External links (from outside balospe.com)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
External URLs (``https://balospe.com/matheology/pet/axioms.html#pet-ax5``)
break when files are moved, because the URL path changes even though the
RST label survives.
**Policy for external link stability:**
1. **Always cite versioned URLs for permanence.** The URL
``/matheology/vv/oov2/axioms-expert.html#pet-ax5-oov2``
points to an immutable archive. It will never move or change.
2. **The ``/matheology/`` prefix is committed as permanent.** No file under
``source/matheology/`` will be moved to a different top-level path.
3. **Model directories are permanent.** ``/matheology/pet/`` and
``/matheology/jub/`` will not be renamed.
4. **Compiled view paths are permanent.** ``/matheology/axioms/easy.html``
will always exist once created.
5. **VV archive paths are immutable.** ``/matheology/vv/oov2/``
will never be restructured.
6. **Jubilee recompile:** Periodically (at Jubilee intervals), the entire
site is recompiled to ensure all internal links resolve. This is a
technical argument for the Jubilee cycle: accumulated link debt requires
periodic global reconciliation.
**Guidance for external users:** "When linking from academic papers, APIs,
or any context requiring permanence, use the versioned URL with the
``/vv/{version}/`` path. The unversioned ``/matheology/pet/``
paths always show the latest content but may restructure over time."
*(Two AA notes moved to*
:doc:`/matheology/hell/ll/jub/b/37/aims-plotter-phase3`
*--- PoR field review against 7Sp DOISI designs, and tech-debt Jubilee
argument for recompile cycles.)*
----
12. Compilation Skill --- ``/compile-matheology``
====================================================
12.1 Modes
^^^^^^^^^^^^
.. list-table::
:header-rows: 1
:widths: 18 30 52
* - Mode
- When to use
- What it does
* - CURRENT-Replace
- PoR changed substantially
- Regenerate ALL downstream pages from current PoR sources
* - CURRENT-Append
- New model added (e.g., 4Be)
- Add new elements without regenerating existing entries
* - MakeNew-Archive
- Major milestone (OOv2 freeze)
- Replace first, then copy to ``vv/compiled/{version}/``
* - MIGRATE
- Structure change (e.g., ``ax1`` to ``pet-ax1``)
- Transform existing files to new naming structure
12.2 User Decisions
^^^^^^^^^^^^^^^^^^^^^
.. list-table::
:header-rows: 1
:widths: 4 28 20 48
* - #
- Decision
- Default
- Notes
* - 1
- Mode
- (required)
- Replace, Append, Archive, or Migrate
* - 2
- Output folder
- ``matheology/``
- Override for non-standard locations
* - 3
- Models to include
- All registered
- Subset selection if needed
* - 4
- Audience-depths
- All
- expert, prod, easy, math, hu, ma
* - 5
- Worldviews
- All registered
- Which v-codes and s-codes to generate
* - 6
- D2 chain types
- All standard
- Which D2 type IDs to generate pages for (POST + analytical)
* - 7
- Stub folder
- ``_templates/stubs/``
- Pre-defined stub templates for complex views
* - 8
- Generate stubs?
- No
- If No, omit pages that would be stubs (no dead links)
* - 9
- Version increment
- (required for Archive)
- v+1 (incompatible), r+1 (features), p+1 (bugfix)
* - 10
- Archive folder
- ``vv/{version}/``
- Override for non-standard location
* - 11
- VVN
- (required for Archive)
- e.g., ``hv_LLoL_OOv2r0p0_2026m03d22``
* - 12
- StayVS maturity
- (required for Archive)
- StayC code for the compilation
* - 13
- Freeze PoR?
- No
- Copy PoR sources to NEW per-model VV archives
**Stub policy:** When ``Generate stubs = No``, pages that would contain only
stub content are not generated and no links to them are created. This
prevents drowning users in empty pages. Stubs are generated only when
explicitly requested (e.g., to prepare scaffolding for the next research
round).
----
13. Prose Reference Convention
================================
.. list-table::
:header-rows: 1
:widths: 12 28 22 38
* - BEST
- Name in Context
- Format
- Example
* - Brief
- First mention or standalone
- Model-element (hyphenated)
- Pet-ax5_A5, Jub-th8_T8, 4Be-A26
* - Brief
- Subsequent (model clear)
- Element only
- ax5_A5, th8_T8
* - Explicit
- Formal heading
- Full with title
- Pet-ax5_A5 --- Containment
* - Explicit
- RST cross-reference
- ``:ref:`pet-ax5```
- renders as "Pet-ax5_A5 --- Containment"
* - Brief
- Code/label context
- All lowercase
- ``pet-ax5``
----
14. Label Examples
====================
.. list-table::
:header-rows: 1
:widths: 40 60
* - Label
- Meaning
* - ``pet-ax5``
- Pet Axiom 5, canonical PoR (latest, expert, English)
* - ``pet-ax5-oov2``
- Pet ax5_A5, frozen at OOv2
* - ``pet-ax5-easy``
- Pet ax5_A5, beginner view (latest)
* - ``pet-ax5-oov2-easy``
- Pet ax5_A5, OOv2, beginner
* - ``pet-ax5-prod-vjud``
- Pet ax5_A5, producer depth, Jewish perspective
* - ``pet-ax5-net-oov2-easy-vjud``
- Pet ax5_A5, network field, OOv2, beginner, Jewish perspective
* - ``pet-ax5-lde``
- Pet ax5_A5, German language-specific cultural insight
* - ``pet-ax-net``
- Pet axiom dependency network (collection)
* - ``jub-th8-stayc``
- Jub-th8_T8 maturity status (D2 chain: th + stayc)
* - ``all-ax-conv``
- All axioms convergence matrix (D2 chain: ax + conv)
* - ``all-ax-hu``
- All axioms human disambiguation page
* - ``pet-ax-ff``
- Pet axioms feedback collection (D2 chain: ax + ff)
* - ``pet-aa``
- Pet AnyAims landing page (single D2 type, no item number)
* - ``pet-model1``
- Pet model statement (specific)
* - ``pet-logic1``
- Pet logic description (specific)
* - ``jub-ax13-logic``
- Jub-ax13_A13 logical framework (D2 chain: ax + logic)
* - ``pet-ax5-needs``
- Pet-ax5_A5 upstream dependencies (D2 chain: ax + needs)
* - ``pet-ax5-limit``
- Pet-ax5_A5 known constraints (D2 chain: ax + limit)
----
15. HELL --- Historically Experienced Lessons Learned
=======================================================
HELL has the central findings register for all models. It collects
objections (con), responses (pro), and their summaries in a structured
folder hierarchy designed to scale to thousands of entries.
15.1 Folder Structure
^^^^^^^^^^^^^^^^^^^^^^^
Logarithmic bands group findings by magnitude:
::
hell/
├── con/
│ ├── a/ ← band a: items 1--9
│ │ ├── 1/
│ │ │ └── index.rst ← con1 landing (summary)
│ │ ├── 2/
│ │ │ └── index.rst
│ │ └── ...
│ ├── b/ ← band b: items 10--99
│ │ ├── 11/
│ │ │ └── index.rst ← con11 landing (summary)
│ │ ├── 12/
│ │ │ └── index.rst
│ │ └── ...
│ ├── c/ ← band c: items 100--999
│ │ ├── 100/
│ │ │ └── index.rst
│ │ └── ...
│ └── d/ ← band d: items 1000--9999
│ ├── 10/
│ │ ├── 00/
│ │ │ └── index.rst ← con1000
│ │ └── 01/
│ │ └── index.rst ← con1001
│ └── ...
└── pro/
├── a/ ← mirrors con structure
│ └── ...
├── b/
│ └── ...
└── ...
**Design rules:**
- **Always-folder:** Every finding is a folder with ``index.rst``, never a
bare file. This allows future sub-pages without restructuring.
- **Band letter = consistency check:** The band letter (a/b/c/d) is
derivable from the item number. ``con11`` lives in ``b/`` because
11 is in range 10--99. If someone puts item 11 in ``a/``, the
inconsistency is immediately visible.
- **Numbering starts at 11.** Band ``a`` (items 1--9) is reserved for
special-purpose entries. Regular findings begin at ``con11``.
- **Up to 999 entries per folder.** Band ``d`` uses two-level nesting
(``d/10/00/`` through ``d/99/99/``) to stay under this limit.
15.2 Label Conventions
^^^^^^^^^^^^^^^^^^^^^^^^
- ``con11`` — landing page / up-to-date summary for finding 11
- ``con11a`` — first individual finding within con11
- ``con11b`` — second individual finding
- ``pro11`` — landing page / up-to-date summary for response 11
- ``pro11a`` — first individual response within pro11
- ``pro11e`` — fifth individual response
**Matched IDs:** ``con11`` and ``pro11`` always address the same issue.
The ``con`` landing page summarizes the objection; the ``pro`` landing
page summarizes the defense. Sub-items (``con11a``, ``pro11e``) are
individual findings and responses within that issue.
**Cross-model objections:** A finding that applies to multiple models
uses the ``all`` prefix: ``all-con11``. Model-specific findings use the
model prefix: ``pet-con11``, ``jub-con15``.
**Storage vs. linking:** Every finding lives in HELL exactly once, at its
unique location (e.g., ``hell/con/b/11/``). The model prefixes above are
for *linking to* that HELL entry in the context of a specific model ---
not for storing separate copies per model. A page discussing Pet axioms
links to ``pet-con11`` to indicate "this objection is relevant here"; the
link resolves to the same ``con11`` content in HELL. The HELL entry itself
links back to whichever model details are affected.
15.3 Relationship to Quest and LLog
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- **HELL** has the **register** (content-indexed, permanent, flat-numbered)
- **Quest** (``quest.rst``) is the **priority backlog** (what to work on next)
- **LLog** is the **chronicle** (temporal audit trail, append-only)
Findings are *discovered* in llogs, *triaged* in quest, and *registered*
in HELL. The llog records when and how; HELL records what and why. Such
work can be described in the natural growth cycle of Seed, Feed, Grow,
and Reap, as seen in the next section.
----
16. Audit Cycle Workflow
==========================
An audit cycle is the process of commissioning, executing, and resolving
a review of the matheology content. Cycles replace the earlier concept of
"rounds" which encoded temporal information into labels.
16.1 Lifecycle
^^^^^^^^^^^^^^^^
An audit cycle follows the rhythm of a growing season. You prepare the
ground, plant the seeds, tend the crop, and bring in the harvest --- then
start the next season with richer soil. Each cycle strengthens
matheology the way each season strengthens a well-tended field: not by
getting it right in one pass, but by returning again and again with
sharper tools and better questions.
**1. Seed** --- *Prepare the ground and plant the questions.*
Define the scope of the audit: which models, which axioms, what depth of
review. Write it down in an llog entry so the intent is on record before
anyone starts digging. A clear scope is like marking the rows before
planting --- without it, effort scatters and nothing takes root.
*In practice:* Commission the review. Document scope, method (adversarial
stress test, peer review, formal check), and success criteria in an llog.
**2. Feed** --- *Expose the work to challenge and nourishment.*
Run the review. Let critics, colleagues, and adversarial agents test the
axioms. Every objection is nourishment, not attack --- it shows where the
roots are shallow. Record everything in the llog as it happens: the raw
exchange, the surprises, the moments where an axiom buckles or holds firm.
This is where most of the real learning happens, and where contributors
of all backgrounds can make a difference. You do not need a PhD in modal
logic to notice that an argument feels wrong, that a metaphor misleads,
or that a tradition has been misrepresented. Those observations, honestly
stated, are among the most valuable nutrients in the field.
*In practice:* Execute the review. Record results in llog (append-only).
The true Places of Evidence (PoE) are outside the system --- a Torah
passage, a philosophical argument, a lived experience, a mathematical
proof. For the purposes of the system, the PoE becomes whatever hints or
artefacts arrive that can be recorded in the llog. The purpose of the log
is to point to the PoEs beyond the system. Further processing generates
more systematic Places of Chronicling (PoC), which then serve as the basis
for integrating the data into Places of Reasoning (PoR), where the actual
decisions are made about how the system changes. Yet none of this
**K**\ nowledge-**U**\ ncertainty **F**\ eedback **I**\ ntegration
**R**\ efinery (KUFIR) --- or "**K**\ nowledge **P**\ ipeline
**R**\ efinery" (KPR) for short --- works if there is no
initial hint that something is not quite right. Hence, value your doubts
as a potential source of truth --- but also seek to clarify them by letting care and truth guide you as
best you can, in order to grow deeper roots into the truth about reality.
**3. Grow** --- *Let the roots deepen and the branches reach.*
In biology, growth happens through specialized tissue at the tips of roots
and branches --- meristems --- that exist nowhere else in the plant. The
Quest file plays a comparable role in matheology: it is the collected list
of all such cutting-edge growth zones, the places where the system is
actively extending itself into new territory.
Extract the findings. Each genuine objection gets a ``con`` number in
HELL --- a permanent address in the register, not buried in a session
log. Each response gets a ``pro`` number: the defense, stated as clearly
as the objection. The Places of Evidence gathered during the Feed stage
are here properly transformed into Places of Chronicling --- which is what
the cons and pros are functionally doing: collecting, organizing, and
crystallizing the raw observations into structured positions.
Update the quest with priorities: which findings are urgent, which can
wait, which need expertise you do not yet have. Assess whether the
responses hold. Mark each finding HELD (the system withstood the
challenge) or BREACH (the challenge succeeded and something must change).
Be honest. A BREACH is not failure --- it is the system getting stronger,
the way a bone heals thicker at the break.
All of this may look like harvesting, but it is not --- not yet. This is
the hidden root growth, the patient deepening that must happen before any
fruit can form. The Places of Chronicling have not yet reached the Place
of Reasoning at which decisions are made about whether any of this will
actually change the system. That comes at the next stage.
*In practice:* Triage findings into HELL (``con``/``pro``). Update quest
priorities. Assess: mark HELD or BREACH.
**4. Reap** --- *Gather what you have learned and prepare for the next
season.*
The task of reaping is to walk through all of HELL's newly updated Cons
and Pros --- always in that order, for scholastic method reasons: the
objection must be fully heard before the defense is weighed --- and
compare them to whatever they are critiquing or defending. This is where
the Places of Reasoning come in. The goal is to determine whether the
cons and pros can justify particular changes on the basis of the logics
used to evolve this system. If yes, that is a fruit to be kept: a genuine
reaping. If no, the work done is honored as part of someone's best
attempt to improve the system.
It is generally impossible to predict which attempts will succeed and
which will not. Therefore, all attempts are honored by the system, and
all contributors who seriously tried to improve it by submitting their
best feedback should be acknowledged accordingly. (What such acknowledgment
looks like in practice remains to be defined, but the principle is
non-negotiable.) For now the best reward is that their work stays at the
Place of Chronicling and is marked as having been considered. While this
work is not included in THIS round of changes, it stays in HELL's Cons
and Pros, because there is no way of predicting when it might serve as a
building block of some substantial Con or Pro that may arise in the
future. Hence, all Con and Pro submissions are public, to best encourage
serious reasoning about all this --- and to help future contributors see
which types of critiques have already been attempted. That may encourage
them to invest their time more productively in areas not yet explored. In
this sense, these critiques are meant to stay forever.
And since we are talking about HELL, let us name what these Cons and Pros
may cover: **FLAMES** --- **F**\ eedbackFlows, **L**\ abLogs and
**L**\ ifeLogs, **A**\ nyAims, **M**\ ockupModels,
**E**\ nclosedExperiments, **S**\ tableSystems --- and anything else that
can be described in the POST system. These FLAMES burn forever in that
they help everyone avoid work already done while also exposing bugs
otherwise hidden under layers of well-intended but misguided oblivion.
The puns on HELL are intentional and are part of LLoL's funny,
non-violent Jonah-Esther-Exodus re-envisioning of Revelation (which is in the process of being described elsewhere).
It is impossible to grow wheat without straw. The attempts that did not
lead to changes --- not yet, at least --- are the straw. Keeping it in
the FLAMES of HELL is to find secondary uses for such straw, and to honor
the commitment it took to produce it in the first place.
*In practice:* Walk through HELL Cons then Pros. Apply Places of
Reasoning to decide changes. Update quest. Archive cycle metadata in
llog. Identify scope for the next cycle.
**5. Next cycle** --- *Take a break, then seize the next opportunity.*
Growth happens naturally. But it needs farming to make it efficient at
scale.
Opportunities are not limitless and need to be seized when they arise.
How to scale up an efficient innovation economy that has learned to
self-stabilize to avoid self-destruction --- that is the broader question
matheology exists to address, hopefully in time before the world
self-destructs.
Each cycle builds on the last. The soil is richer because you now know
where the objections cluster, which defenses held, and which corners of
the system have never been tested. Matheology grows not by decree but by
this patient, iterative cultivation --- and anyone willing to ask an
honest question can contribute to the next season. The effort spent in
defining this AHA document is spent in the hope of encouraging such
farming, which is impossible without some organizing of where the seeds
are stored before being sowed and some technical conventions for how to
do this.
16.2 Some Technical Farming Tools
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Generally, this document --- and the whole balospe.com site --- intends
to be a collection of such farming tools: conventions, registries, and
naming systems that make the Seed/Feed/Grow/Reap cycle practical at
scale. The following list contains some aspects related to help
**migration between rounds**, especially when changes are large, such as
on initial migrations after a major restructuring.
**No encoding of cycles in labels.** Audit cycles are temporal events
documented in llogs. They do not appear in HELL labels. ``con11`` is
``con11`` regardless of which cycle discovered it.
**Migration from round-based labels (completed 2026-03-24, Phase 2I-6).**
The 66 round-based labels (33 con + 33 pro) from ``quest.rst`` have been
migrated to flat HELL numbers (``con11``--``con43``,
``pro11``--``pro43``). Old labels are preserved as aliases in
``quest.rst`` for backwards compatibility (except
``jub-con11``--``jub-con14`` / ``jub-pro11``--``jub-pro14``, which
collide with new numbering and were reassigned to
``jub-con21``--``jub-con24`` / ``jub-pro21``--``jub-pro24``).
Full mapping and details:
:doc:`/matheology/hell/ll/jub/b/39/jub_ll_2026m03d24_phase2I-6-hell-migration`
.. _aha-best-names-for-matheology-links-reap-design-fruits:
16.3 Reaping Architectural Design Fruits
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Good design decisions need real-world data. The adversarial critiques,
stress tests, and restructuring work of Phase 2 produced a heap of
content --- 25 axioms, 11 theorems, 33 objections, 33 responses, plus
supporting material --- that is now awaiting integration into the BEST
Names structure. That integration is the biggest sorting exercise in
matheology so far: every piece of content moves, every label
is re-examined, no stone of the old data is left unturned.
This is a once-in-a-project opportunity. Several open design questions
(Section 17.1) cannot be answered by analysis alone --- they require
empirical evidence from real content being sorted into real labels. If
those questions are not kept in mind during the sorting, the opportunity
is lost. But when they stay at the center of attention, the person (or
agent) doing the sorting can see: "this combination would be genuinely
useful" or "this combination is grammar-legal but nobody would ever want
it." That empirical signal is exactly what the architecture needs to
mature.
**The questions to keep in mind during integration:**
1. **D1/D2 compatibility:** Which type IDs are actually used by which
models? Where are the gaps?
2. **Should Pet have con/pro?** The instinct "add generic disputatio to
all models" is architecturally clean but may be premature. Watch for
whether cross-model objections naturally emerge (e.g., "this Pet axiom
contradicts that Jub axiom") or whether ``con``/``pro`` remains
structurally specific to Jub's quest format. Real data first.
3. **D2 chaining:** Do authors naturally reach for chains of two or more
type IDs? Or does a single type always suffice?
4. **Alignment class echoes:** Do element numbers in different models
address the same concepts? How strong are the parallels?
5. **PoR field #40 collision:** Does the name ``model`` cause real
ambiguity between the D2 type and the PoR field?
**Where to report findings:**
Each question has a dedicated data collection file with sample entries
showing the expected format. Agents append rows during integration;
summaries are written after integration completes.
- :doc:`/matheology/hell/ll/jub/b/41/d1-d2-testing-matrix`
--- D1/D2 combination evidence (BREACH 1.7)
- :doc:`/matheology/hell/ll/jub/b/41/d2-chaining-evidence`
--- natural chaining cases for/against deeper nesting
- :doc:`/matheology/hell/ll/jub/b/41/alignment-class-echoes`
--- cross-model echo observations
- :doc:`/matheology/hell/ll/jub/b/41/por-field-collision-check`
--- ``model`` name collision instances
- :doc:`/matheology/hell/ll/jub/b/41/por-field-usage-census`
--- PoR field real-world usage and proposed new fields
**Agent prompts for this task:**
- :doc:`/matheology/hell/ll/jub/b/41/prompt_reap-design-questions-during-integration`
(instructs integration agents to collect evidence for questions 1--6
alongside their primary sorting work)
- :doc:`/matheology/hell/ll/jub/b/47/prompt_por-field-usage-census`
(detailed instructions for the PoR field census, including sampling
strategy and proposed-new-fields tracking)
**The principle:** Architecture should follow data, not precede it. The
grammar is deliberately permissive (flat D2, default nesting limit 2,
syntactically open D1/D2 combinations). The integration exercise will
produce the evidence to tighten or confirm those choices. Until then,
the questions in Section 17.1 remain open --- but they are being actively
investigated, not merely deferred.
----
.. note::
**Token-saving note for agents:** Sections 1--16 above contain
the complete grammar, registries, and operational reference needed
for production use of this naming system. Sections 17+ below are
architect/maintainer material: open design questions, action items,
design decision rationale, and resolved-issue logs. Agents working
on content (compilation, label creation, cross-referencing) can stop
reading here.
----
17. Open Design Questions
===========================
17.1 Awaiting Integration Data
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The following items are deliberately deferred until the Phase 2I
integration scripts run against real content. See the integration testing
prompt (:doc:`/matheology/hell/ll/jub/b/41/prompt_2I-integration-tests`)
for the specific tests that will inform these decisions.
- **BREACH 1.7** (D1/D2 bidirectional mapping): Which D2 element types
are valid for which D1 models? Current examples: ``con``/``pro``/``q``
are specific to Jub's quest/disputatio structure; Pet has no disputatio
yet. Related question: **should Pet have a disputatio?** The grammar is
syntactically permissive (``pet-con1`` parses fine); the constraint is
semantic and should be informed by real data.
- **D2 chaining depth:** Should ``pet-ax5-logic-limit`` (3 type IDs) be
common enough to raise the default nesting limit above 2? The integration
scripts should track cases where authors naturally reach for deeper chains.
- **Alignment class metadata:** The grammar accommodates alignment classes
(``all7e``, ``all4e``, etc.) but the metadata schema for declaring which
models belong to which class is undefined. Design after the first real
cross-model echo compilation reveals what information is needed.
- **PoR field #40 name collision:** PoR field ``model`` ("ModelUsedIn")
shares its name with the D2 primary element type ``model``. Consider
renaming to ``usedby`` or ``inmodel``. Defer until the compilation skill
makes the collision a real parse conflict.
- **PoR field real-world usage:** The PoR registry (Section 9) defines
40+ fields per element. How many of these fields are actually populated
when real content is migrated from OOv1 to OOv2? Which fields are
naturally filled by existing content, which require expert invention,
and which remain empty stubs? Equally important: does the migration
reveal content that *wants* a field the current PoR does not have?
Such proposals should be recorded in a separate "proposed new fields"
list for Phase 3 review. The OOv1→OOv2 migration is the first
large-scale test of whether the PoR field set is right-sized. Data
should be collected during the migration and reviewed in Phase 3 to
decide which fields to keep, merge, drop, or add. See
:doc:`/matheology/hell/ll/jub/b/41/por-field-usage-census` for the data
collection file and
:doc:`/matheology/hell/ll/jub/b/47/prompt_por-field-usage-census`
for the agent prompt.
17.2 Phase 3 (Infrastructure)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- **``/go/{label}`` resolver:** Stable external URL system (similar to
DOI). Implementation deferred to Phase 3.
- **BREACH 5.2** (include directive violation): 6 combined pages
(``axioms/index.rst``, ``theorems/index.rst``, ``symbols/index.rst``)
use ``.. include::`` to pull in content files that contain RST labels,
causing duplicate-label warnings. Cannot be resolved until the Phase 3
compilation skill generates combined pages properly instead of using
raw includes.
- **BREACH 4.5** (label tooling): Specify the label linter/parser. Phase 3.
- **BREACH 4.3** (quick-start guide): Contributor quick-start. Phase 3.
----
18. AnyAims Remaining
=======================
Action items for this design document.
- **AA-1:** Set up a FeedbackFlow (FF) link for this page so that
readers can submit corrections and suggestions directly.
- **AA-2:** Review the PoR fields (Section 9) against 7Sp DOISI designs
before finalizing the PoR field structure.
- **AA-3:** Add the tech-debt Jubilee argument (periodic global recompile
to prevent link rot) to the Jubilee theological discussion.
- **AA-4:** Run the integration testing prompt and resolve the deferred
design questions in Section 17.1 based on the results.
- **AA-5:** Review the PoR field real-world usage census after the
OOv1→OOv2 migration completes. Decide which fields to keep, merge,
drop, or add based on empirical data.
Longer-term tasks are tracked in the
:doc:`Phase 3 AIMS Plotter `.
----
19. Design Decisions
======================
Rationale for major architectural choices. These sections document *why*
decisions were made, not the rules themselves (which live in Sections 1--8).
19.1 No State Dimension (D6 Collapsed into D2)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Earlier drafts included a 6th dimension (D6 --- State) with three
sub-namespaces: POST operational codes (doubled letters like ``ff``, ``kk``),
analytical codes (``diff``, ``conv``, ``stayc``), and machine codes (``ma*``).
This dimension was collapsed entirely into D2 as sub-element fields after
analysis revealed it was not a genuine independent dimension.
**Why D6 was eliminated:**
1. **Every D6 code is a property of an element.** ``pet-ax5-ff`` is feedback
*about* Axiom 5. ``jub-th8-stayc`` is the stability code *of* Theorem 8.
No D6 code ever existed independently of a D2 element. A property of an
element belongs in the element's dimension, not in a separate one.
2. **The "state" framing was misleading.** D6 was called "State (Context)"
but its codes describe what *about* an element, not what *state* it is in.
``bib`` is a bibliography, ``net`` is a dependency graph, ``logic`` is the
logical framework. These are sub-aspects of the element --- exactly what
D2 sub-element fields are for.
3. **Eliminates an entire collision surface.** With D6 removed, there is no
need to prove that D6 codes do not collide with D4 or D5 codes at the
same token position. The sub-element fields are registered in a single D2
registry alongside primary element types, making collision checking
trivial.
4. **Simplifies the grammar.** The label grammar drops from 6 slots to 5:
``{model}-{element}[-{field}][-{version}][-{depth}][-{view}]``. The
parser has fewer ambiguous positions to resolve.
5. **Closes BREACH 2.2** (D6 Set B catch-all risk) and **BREACH 5.5**
(``ref`` overloading across dimensions) from the Phase 2G adversarial
stress test. Both arose from D6 being an insufficiently bounded
namespace. Collapsing into D2 with strict registry discipline resolves
both.
**What moved where:**
- All POST operational codes (``aa`` through ``yy``) → D2 sub-element
fields, Section 5.2.2
- All analytical codes (``diff`` through ``his``) → D2 sub-element fields,
Section 5.2.3
- Structural fields previously split across D2 and D6 (``model``, ``logic``,
``limit``, ``needs``, ``feeds``, ``net``) → D2 sub-element fields,
Section 5.2.1
- Machine codes (``ma*``) → remain in D4 (they were always audience codes)
**Sub-element chaining:** The current grammar supports one field per label
(``pet-ax5-logic``). Whether to allow chaining (``pet-ax5-logic-limit``)
is deferred. Future Phase 2I+ scripts should watch for cases where chaining
would provide genuine value. If adopted, the parser would need to handle
ordered field sequences.
19.2 No Language Dimension
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Earlier drafts included a 7th dimension (D7) for human language, using
ISO 639-1 two-letter codes as the final label segment. This was removed
after adversarial stress-testing revealed both a critical collision and a
deeper architectural misalignment. The reasons:
1. **Standards consensus.** Every major identifier system (DOI, Wikidata
QIDs, W3C URIs, IETF BCP 47) treats language as routing metadata, not
as part of the resource identifier. An axiom is the same axiom
regardless of the language it is rendered in. The identifier should
reflect identity; the URL layer should handle language routing.
2. **Sphinx already solves this.** Sphinx i18n provides language-neutral
labels. ``:ref:`pet-ax5``` resolves to the translated page when
browsing under ``/de/``. Adding a language dimension to labels
duplicates what the build system already does correctly.
3. **Collision hazard.** ISO 639-1 two-letter codes collide structurally
with POST doubled-letter codes (now D2 sub-element fields) --- both are
2-letter lowercase patterns. Eight ISO 639-1 codes consist of doubled
letters (``aa``, ``ee``, ``ff``, ``ii``, ``nn``, ``ss``, ``tt``, and
one more), several of which are already assigned as POST codes. Under
the earlier design, a contributor writing a label with one of these
codes would produce a silent mismatch between intended language and
parsed POST field. Eliminating the language dimension eliminates the
entire collision class.
4. **Future-proofing.** If ResearchCity transitions from
``balospe.com/en/`` to subdomain-based routing (``en.balospe.com/``,
as Wikipedia uses), labels require zero changes --- because they never
contained language in the first place. This makes the naming system
robust against any future URL restructuring.
**For the rare case of language-specific cultural insights** that go beyond
translation --- an untranslatable idiom, a structural distinction, a deeper
truth that a language makes visible --- use a D5 language code (``lde``,
``lar``, ``lhe``). This treats language-specific insight the same way as
worldview-specific insight: as a *lens* through which formal content is
examined, not as a translation target. See Section 8.3.
19.3 ``all`` as D1-Only Reserved Keyword
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
``all`` occupies the D1 (model) position and ONLY the D1 position. It is
a reserved keyword that no other dimension may claim.
**Why D1-only?** The alternative --- allowing ``all`` in any dimension as a
"don't filter" wildcard --- was considered and rejected for two reasons:
1. **Parser ambiguity.** The grammar is
``{model}-{element}[-{field}][-{version}][-{depth}][-{view}]``. If
``all`` could appear in multiple dimensions, the parser seeing
``pet-ax5-all`` cannot determine whether ``all`` is version=all,
depth=all, or view=all. Each keyword must map to exactly one dimension
(Section 3.2, rule 3). Making ``all`` cross-dimensional would
require special-case parser logic --- a complexity tax that compounds
over time.
2. **Redundancy.** Omitting a dimension already means "use default." For
most dimensions, the default is the most common case in practical use:
- D3 omitted → latest version (the one you want)
- D4 omitted → expert depth (the most comprehensive standard view)
- D5 omitted → all views synthesized (the PoR)
The only dimension where ``all`` says something the default does not
is D1 --- because D1 is required, not optional. There is no way to
omit D1 to mean "all models." Hence ``all`` is needed in D1 and
redundant elsewhere.
**For the "dump everything / debug" use case** (showing all D2 types,
all metadata, all depth levels on one page), a dedicated D4 depth
code ``dump`` is registered (Section 7). ``pet-ax5-dump`` means "Pet
Axiom 5, debug-comprehensive format." This is clearer than a trailing
``all`` because it names the audience (the debugger) rather than
overloading a scope keyword.
**Dimensional analysis of ``all``:**
.. list-table::
:header-rows: 1
:widths: 8 20 30 42
* - Dim
- Example
- Would mean
- Assessment
* - **D1**
- ``all-ax5``
- Axiom 5 across all models
- **Useful.** Enables cross-model echo compilation. Registered.
* - **D1**
- ``all-ax``
- All axioms across all models
- **Useful.** Collection/landing page for cross-model axiom
integration. Follows from bare-code = collection rule.
* - **D2**
- ``pet-all``
- All elements of Pet
- **Redundant.** This is the model landing page, already served by
the ``pet/`` directory.
* - **D3**
- ``pet-ax5-all``
- Across all versions
- **Marginal.** A version-evolution page. If needed, use ``dump``.
* - **D4**
- ``pet-ax5-all``
- All audience depths
- **No.** You don't serve expert+easy+math simultaneously. The
debug use case is better served by ``dump``.
* - **D5**
- ``pet-ax5-all``
- All worldviews
- **Redundant.** The default expert PoR already synthesizes all
views. Omitting D5 = all views.
19.4 Alignment Classes (Cross-Model Echoes)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Some axiom systems intentionally align their numbering so that element N
in one model echoes element N in another. These alignments carry deep
structural insight --- connections that are easy to miss but essential for
keeping an innovation economy balanced. LLoL calls these **cross-model
echoes**.
Not all models align. Pet and Jub assign numbers near-randomly; asking
for ``all-ax5`` across them yields a sparse comparison. But families of
models designed around a shared structural template --- called **alignment
classes** --- have rich echo relationships.
Alignment classes are registered as D1 model codes with an ``all`` prefix
and an element-count suffix:
- ``all4e`` — models aligning 4 elements
- ``all5e`` — models aligning 5 elements
- ``all7e`` — models aligning 7 elements
- ``all12e`` — models aligning 12 elements
**How models declare alignment:** A model that participates in an
alignment class declares so in its model registration (the D1 registry
table in Section 4 or a future dedicated registry file). The declaration
specifies: (1) which alignment class, (2) which element numbers are
aligned, (3) which model elements map to which alignment positions.
**Examples:**
.. list-table::
:header-rows: 1
:widths: 25 75
* - Label
- Meaning
* - ``all-ax``
- Collection of all axioms across all models (integration page)
* - ``all-ax5``
- Axiom 5 across all models (sparse for non-aligned models)
* - ``all7e-ax3``
- Axiom 3 across all 7-element-aligned models (echo compilation)
* - ``all7e-ax``
- All axioms across all 7-element-aligned models
* - ``all7e-ax3-easy``
- Same echo compilation, easy depth
* - ``all-ax-dump``
- Cross-model axiom collection, debug-comprehensive format
**Design note:** The bare ``all`` compiles across ALL models regardless of
alignment. Alignment-class codes (``all7e``, etc.) restrict compilation to
models that declared membership. Non-aligned models are simply absent from
an alignment-class compilation --- no error, just no data.
**Deferred:** The exact format for declaring alignment membership (which
fields, where stored) is deferred until the integration scripts surface
real-world echo patterns. The grammar and registry accommodate alignment
classes now; the metadata schema can be defined when the data demands it.
19.5 Flat D2 Grammar (Prototypal Element Structure)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
**Decision (2026-03-24):** The D2 dimension uses a single flat type ID
registry with free chaining. There is no grammatical distinction between
"element types" and "sub-element fields." All D2 codes are peers in one
namespace; any registered code may appear at any position in a D2 chain.
**Old grammar (rejected):**
::
{model}-{elementType}{itemNumber}[-{field}][-{version}][-{depth}][-{view}]
This imposed a two-tier hierarchy: certain D2 codes (``ax``, ``th``,
``con``, ``pro``, etc.) were "primary element types" that had to come
first, while others (``logic``, ``needs``, ``ff``, ``aa``, etc.) were
"sub-element fields" that could only attach dependently after a primary
element.
**New grammar (adopted):**
::
{model}-{typeID}[{N}][-{typeID}[{N}]]*[-{version}][-{depth}][-{view}]
**Why the hierarchy was wrong:**
1. **The killer example: ``pet-aa``.** Under the old grammar, ``pet-aa``
would parse as model=``pet``, elementType=``aa``. But ``aa`` (AnyAims)
was classified as a "sub-element field," not a "primary element type,"
so the grammar would reject or misclassify it. Yet ``pet-aa`` is a
completely natural label --- "the AnyAims landing page for Pet." There
is no principled reason why ``aa`` should only be permitted *after* an
element type. What makes ``ax`` grammatically different from ``aa``?
Nothing.
2. **Codes already straddled both categories.** ``model``, ``logic``, and
``limit`` appeared in both the primary type table and the sub-element
field table. They were simultaneously "element types" and "sub-element
fields." A grammar with two categories where items routinely appear in
both is a grammar pretending to have two categories while the data
already treats them as one.
3. **The parser never needed the distinction.** The parser reads
left-to-right: consume the D1 model code (everything before the first
hyphen), then greedily consume D2 tokens (each optionally followed by
digits) until encountering a token matching D3, D4, or D5. Whether a
token is "primary" or "sub-element" never affects a single parsing
decision. The disambiguation rules --- letter-only constraint,
doubled-letter pattern, registry lookup --- work identically regardless
of position in the chain.
4. **Prototypal type systems as analogy.** In a prototypal type system
(as in JavaScript or Self), there is no class hierarchy --- objects
have properties and you chain them. Similarly, D2 codes are type IDs
in a flat namespace. ``pet-ax5-logic`` chains two type IDs; so could
``pet-logic1-ax5`` hypothetically. The grammar should not privilege
one ordering over another. Which combinations are *meaningful* is a
semantic question for the compilation skill; which combinations are
*parseable* is a grammatical question, and the answer should be: all
registered codes chain freely.
5. **Too many useful combinations were being ruled out.** Beyond
``pet-aa``, the old grammar also blocked patterns like ``pet-ff``
(feedback landing page for Pet), ``jub-dd`` (design doc for Jub),
``all-conv`` (cross-model convergence without specifying an element
type first). Each of these is natural and useful. The hierarchy was
not protecting against real ambiguity --- it was an arbitrary
structural choice imposed before enough data existed to justify it.
**How the combinatorial explosion is managed:**
A flat grammar with free chaining could produce nonsensical labels like
``pet-ax5-logic-needs-ff-bib-conv-...`` chained indefinitely. The
solution is not to hardcode which codes can chain with which (that
reintroduces the hierarchy) but to impose a pragmatic depth limit:
- **Default nesting limit: 2 type IDs** (e.g., ``pet-ax5-logic``).
This covers the vast majority of real use cases.
- **Explicit override:** The compilation skill accepts a directive
(``.. best-depth:: 3``) for cases that genuinely require deeper
chains. The override is per-page, auditable, and rare.
- **Data-driven refinement:** The limit is a pragmatic default. Phase 3
integration data will determine whether to raise, lower, or remove it.
If the data shows that no label ever needs depth 3, the limit can be
hardened into a constraint. If several legitimate depth-3 cases emerge,
the default can be raised. The grammar accommodates both outcomes.
**What the organizational groupings mean now:**
Sections 5.1 (Formal Elements), 5.2 (Structural Fields), 5.3 (POST
Operational Fields), and 5.4 (Analytical Fields) are **documentation
groupings** for human readers navigating the registry. They help authors
find the right code. They are not grammatical categories and do not
constrain parsing. The parser sees one flat D2 namespace.
**POST namespace reservation:** The doubled-letter codes, triple-letter
codes, and longer multi-letter codes are reserved by the Evolvix POST
System (Project Organization Stabilizing Toolkit System). This document
adopts the subset of POST codes it deems useful here; the authoritative
POST registry is maintained by Evolvix.
19.6 Source References: Citations, Hints, and Bibliographies
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
**Decision (2026-03-24):** Source references in the BEST Names system use
a three-layer design that keeps the common case lightweight while
accommodating richer metadata when needed. The design deliberately avoids
reinventing citation management tools (Endnote, BibTeX, Zotero).
**The problem:**
The existing ad-hoc content format for source references is compact and
effective for reading:
::
- **Torah:** Deut 4:39 ("God in heaven above and earth beneath")
- **Gospel (Jesus):** "I am in the Father and the Father is in me" (Jn 14:10)
The parenthetical hint is not decoration — it IS the argument. "Deut 4:39
(God in heaven above and earth beneath)" says: *this verse supports this
axiom BECAUSE it says God is everywhere*. Strip the hint and you strip the
reasoning. Any design that loses these hints in compilation has failed.
But the one-liner format conflates several concerns:
- **Locator** — where in the source (Deut 4:39, Jn 14:10)
- **Hint/Gloss** — why it matters here (the parenthetical)
- **Translation** — which translation is being quoted (JPS? KJV? NIV?)
- **URL** — where to read it online
- **Edition** — which physical/digital edition (publisher, year, ISBN)
The one-liner handles the first two well. It cannot handle the rest
without becoming unwieldy.
**The ``cit`` / ``bib`` distinction:**
Two D2 type IDs serve complementary roles:
- **``cit`` (Citation)** — the in-situ reference: a specific passage
being cited, with locator and hint explaining *why* it is relevant
here. ``cit`` answers the reader's question: "what does the source say
that matters for this element?"
Example content in ``pet-ax1-cit``::
Deut 4:39 ("God in heaven above and earth beneath")
Gen 28:16 (Jacob: "God is in this place and I did not know")
Jn 14:10 ("I am in the Father and the Father is in me")
- **``bib`` (Bibliography)** — the formal metadata for the source work
itself: author, title, publisher, year, edition, identifier. ``bib``
answers the reader's question: "which edition are you using and how do
I find it?" This is what you would export to Endnote or BibTeX.
Example content in ``pet-ax-bib``::
Torah: JPS Hebrew-English Tanakh, 2nd ed.
Jewish Publication Society, 2003. ISBN 978-0-8276-0697-3.
New Testament: NRSV, Oxford UP, 2018. ISBN 978-0-19-064407-2.
A ``cit`` without a ``bib`` is still useful (the reader can find the
source). A ``bib`` without ``cit`` entries is a reading list, not an
argument. Most pages will have ``cit`` entries; ``bib`` entries will
typically live at the collection level (``pet-ax-bib``, not
``pet-ax5-bib``).
**How source codes (D5) cross-cut with ``cit`` / ``bib`` (D2):**
Source codes (``stor``, ``sheb``, ``sgos``, etc.) are D5 — they select
which *tradition*. ``cit`` and ``bib`` are D2 — they select what *kind
of reference*. These are orthogonal:
- ``pet-ax1-stor`` — Pet ax1_A1 rendered from a Torah perspective. Contains
Torah-informed content with citations embedded naturally as one-liners
with hints.
- ``pet-ax1-cit`` — all in-situ citations for Pet ax1_A1 across *all*
source traditions. Aggregates Torah + Gospel + Quran + secular
citations.
- ``pet-ax-bib`` — bibliography for all of Pet's axioms. Lists editions
used.
- ``all-ax-stor`` — cross-model Torah references across all axioms.
Compilation page.
The source code tells you *whose* perspective; the D2 type tells you
*what kind of page*.
**Three rendering layers, same page, depth-selected:**
1. **One-liner with hint** (default expert rendering). The format
convention ``Locator ("brief gloss")`` is machine-parseable:
everything before the opening parenthesis is the locator, everything
inside is the hint. This is what most readers need. It appears in
source pages and overview compilations.
2. **Extended entry** (rendered at ``dump`` depth). Uses RST definition
lists below the one-liner — no custom directives needed::
Deut 4:39
"Know this day, and lay it to your heart, that the LORD He is
God in heaven above and upon the earth beneath; there is none
else." — JPS 1917
Alt: "...the LORD is God in the heavens above and on the earth
below. There is no other." — NIV 2011
https://www.sefaria.org/Deuteronomy.4.39
The compilation skill renders the one-liner for overview pages; the
extended entry for ``dump`` depth.
3. **Collection pages** (``pet-ax-cit``, ``all-ax-stor``) aggregate
one-liners from all elements. At ``dump`` depth, extended entries
expand inline.
**Why this is not Endnote:**
- No citation database, no BibTeX files, no CSL formatting engine.
- The one-liner with hint is hand-written by the author — the hint is
editorial judgment about *why this passage matters here*, not
auto-generated metadata.
- Extended entries are optional. If nobody writes one, the one-liner
stands alone.
- The compilation skill does not *manage* citations; it *renders* them
at different depths.
- URLs and alternate translations are inline RST content, not structured
metadata fields in a schema.
- ``bib`` entries are plain-text paragraphs, not machine-parsed records.
If someone later wants BibTeX export, a script can parse them — but
the design does not depend on it.
**Deferred:** The exact rendering templates (how ``dump`` depth formats
extended entries, how collection pages aggregate) are deferred to the
compilation skill design (Phase 3). The content convention (one-liner
format, definition-list extended entries) can be adopted immediately by
authors writing new content.
.. _aha-best-names-for-matheology-links-dd-publication-renumbering:
19.7 Publication Renumbering (One-Time Idempotent Event)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
**Problem.** During development, elements are numbered in order of
creation. Deprecations leave gaps. The result is a sequence like
ax1_A1, ax2_A2, ax3_A3, (gap), ax5_A5, ax6_A6... ax14_A14, ax15_A15... ax25_A25 — where the logical
flow (ontological → epistemological → ethical) bears no relation to the
numbering. Newcomers must navigate this arbitrary ordering, which
is a significant barrier to comprehension.
At the same time, permanent label stability is a non-negotiable
architectural requirement: HELL entries, stress tests, external
citations, and archived Versioned Variants all assume that ``pet-ax5``
means the same thing forever (see Section 11.1, point 5).
**Solution.** The architecture provides a single, consumable
renumbering event — analogous to how RFC drafts receive temporary names
before publication, or how software uses breaking changes freely before
1.0 and semantic versioning after. The renumbering can happen **exactly
once per model.** After that, numbers are permanent.
**The signal is in the code itself.** Tentative (pre-renumbering) types
use multi-letter D2 codes. Final (post-renumbering) types use
single-letter D2 codes. This is machine-readable: any parser or grep
can instantly distinguish the two regimes.
**Family table.** The following types are eligible for renumbering.
Each row shows the tentative code (development), the final code
(publication), what question the type answers for readers, and which
expert-only sub-types collapse into this family at beginner depth.
.. list-table::
:header-rows: 1
:widths: 14 6 6 28 20 26
* - Family
- Dev
- Pub
- What it answers
- Name
- Expert sub-types
* - Foundations
- ``ax``
- ``a``
- "What is this built on?"
- Axiom
- ``as`` (assumption), ``cj`` (conjecture)
* - Observations
- ``obs``
- ``o``
- "What real-world data grounds this?"
- Observation
- *(new type)*
* - Derivations
- ``th``
- ``t``
- "What follows from the foundations?"
- Theorem
- ``lm`` (lemma), ``cr`` (corollary) via D2 chain
* - Definitions
- ``df``
- ``d``
- "What do the terms mean?"
- Definition
-
* - Symbols
- ``sy``
- ``s``
- "What notation is used?"
- Symbol
-
* - Rules
- ``ru``
- ``r``
- "What inference steps are allowed?"
- Rule
- Covers rule schemas (``sc`` dropped)
* - Functions
- ``fn``
- ``f``
- "What operations are defined?"
- Function
-
* - Logic
- ``logic``
- ``l``
- "What reasoning framework?"
- Logic
-
* - Model
- ``model``
- ``m``
- "What is the big picture?"
- Model
-
**Never renumbered.** The following types are excluded because their
ordering is inherently temporal or their permanence is structurally
required:
- **``con``, ``pro``** (Disputatio) — HELL entries. Discovery order IS
the scholarly record. Renumbering destroys the temporal evidence trail.
- **``q``** (Question) — Quest entries reflect priority triage, not
logical structure.
- **``eg``, ``n``** (Example, Note) — Subordinate to parent elements.
- **``proof``** — Tied 1:1 to its parent theorem; follows
automatically via D2 chain if the parent renumbers.
- **``limit``** (Constraint) — System constraints; not a
newcomer-facing sequence.
**Expert sub-types and D2 chaining.** Lemmas, corollaries, assumptions,
and conjectures are not independent top-level entries — they are
expert-depth refinements of their parent type, accessed via D2 chaining:
- ``pet-t3-lm1`` = "the first lemma supporting theorem 3"
- ``pet-t3-cr1`` = "the first corollary of theorem 3"
- ``pet-a5-as2`` = "the second assumption within axiom 5"
At beginner depth, the Extraction Matrix suppresses these sub-types
entirely: readers see ``a1`` through ``a14`` and ``t1`` through ``t11``.
At expert depth, the full D2 chains are visible. This serves both
audiences without maintaining two separate numbering systems.
Because sub-types are syntactically children of their parent, renumbering
the parent automatically carries the children: if ``th8`` → ``t3``,
then ``th8-lm1`` → ``t3-lm1``. No independent renumbering needed.
**Mechanism.**
1. A **mapping file** (machine-readable, e.g., RST or CSV) defines
every old→new assignment: ``pet-ax5 → pet-a3``, ``pet-th8 → pet-t3``,
etc. This file is the single source of truth for the renumbering.
2. A **renumbering script** reads the mapping and updates every label,
every ``:ref:``, every prose reference, every HELL citation, and every
compiled page across the entire codebase in one pass.
3. Every old label **survives as an alias** — a 301 redirect from
``pet-ax5`` to ``pet-a3``. No links break. Ever.
4. The mapping file is **committed to the repository** as permanent
evidence that the renumbering occurred. Its existence is the proof
that the one-time event has been consumed for that model.
5. **Idempotency enforcement:** The presence of single-letter D2 codes
in a model's labels means the renumbering has already happened. Any
attempt to run the renumbering script again detects this and refuses.
**Visual convention in prose.**
- Before renumbering: ``Pet-a5`` (lowercase element number = tentative)
- After renumbering: ``Pet-ax5_A5`` (uppercase element number = final)
- RST labels are always all-lowercase regardless: ``pet-ax5`` (before)
or ``pet-a5`` (after). The case convention applies only to
human-facing prose (Section 13).
**Registry changes implied by this DD:**
- **Add** ``obs`` (Observation) to the D2 formal elements table.
- **Rename** ``rl`` → ``ru`` (Rule) for readability. No content uses
``rl`` yet; change is costless.
- **Drop** ``sc`` (Schema). Add a note to ``ru`` that it covers both
concrete rules and rule schemas.
- **Reserve** single-letter codes ``a``, ``t``, ``o``, ``d``, ``s``,
``r``, ``f``, ``l``, ``m`` for post-renumbering use. They must not
appear in labels until the renumbering event.
**Deferred to Phase 3 (AIMS Plotter):**
- Design the mapping file format and renumbering script.
- Define how expert-level sub-type renumbering interacts with the main
renumbering event — if possible, without breaking the system.
- Determine whether ``df`` → ``d`` (Definition) merits its own
renumbering or whether definitions are few enough to order manually.
----
20. LabLog --- Resolved Design Issues
=======================================
Issues resolved during the design process, kept for historical
traceability.
- *(RESOLVED 2026-03-24)* **BREACH 1.3** (2-letter invariant): Promoted
doubled-letter vs. distinct-letter pattern to a formal structural
invariant in Section 3.2 rule 6.
- *(RESOLVED 2026-03-24)* **BREACH 1.4** (D4 reserved prefixes):
Documented as Section 3.2 rule 7.
- *(RESOLVED 2026-03-24)* **BREACH 2.4** (D2 letter-only constraint):
Documented in Section 5 design rules (applies to all D2 codes).
- *(RESOLVED 2026-03-24)* **``all`` keyword scope:** Documented as
D1-only reserved keyword in Section 3.1 rules 9--10 and Section 19.3.
``dump`` registered in D4 (Section 7). Alignment classes registered
in D1 (Section 4) with design rationale in Section 19.4.
- *(RESOLVED 2026-03-24)* **D2 grammar flattening:** Removed the
artificial distinction between "primary element types" and "sub-element
fields." The old grammar ``{model}-{elementType}{itemNumber}[-{field}]``
imposed a hierarchy where certain D2 codes (ax, th, con...) were
privileged as "primary" and others (logic, needs, ff, aa...) could only
appear in a dependent position. This ruled out natural labels like
``pet-aa`` (AnyAims landing page for Pet) and contradicted the fact
that codes like ``model``, ``logic``, and ``limit`` already appeared in
both categories. New grammar:
``{model}-{typeID}[{N}][-{typeID}[{N}]]*[-{version}][-{depth}][-{view}]``
--- a flat type ID registry with free chaining, default nesting limit 2,
and compiler override for deeper chains. Organizational groupings
(Sections 5.1--5.4) retained for readability; parser sees one namespace.
POST namespace reserved by Evolvix POST 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.