Note

This is the compiler’s working copy of the 5D Link Naming architecture document. The original audit-trail copy lives at vv/jub/oov2/llog/aha-best-names-for-matheology-links.rst (frozen under its original filename). This copy is the living reference that all compilers (SISYF, PROMY) read from. Edits go here; the llog copy is immutable.

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

---

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:

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.

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.

Prose form	Label code	Full name	Status
Pet	pet	Pan-En-Theistic foundation (ax1–ax14)	Active
Jub	jub	Jubilee extension (ax15–ax25)	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.

---

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 PoR Fields Registry.

5.1 Formal Elements

PoR usage: Identity fields, Technical fields.

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:

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).

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: Technical/structural fields.

Structural fields:

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

5.3 POST Operational Fields (doubled-letter codes)

Regex pattern: ^([a-z])\1$ — exactly 2 identical lowercase letters. PoR usage: POST fields.

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.

5.4 Analytical Fields (3+ letter codes)

PoR usage: Technical/structural/analytical fields.

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.

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)

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):

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):

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)

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)

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``.

---

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 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).

9.1 Identity and Display

#	Brief	Explicit Name	Summarizing Name	Content Example
1	id	BriefName	Canonical identifier	pet-ax5
2	title	Title	Full display title	ax5 — 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

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 Structural fields and Analytical fields.

#	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, ax2, ax3
31	feeds	FeedsNeed	Downstream dependents (used by)	th1, th5, ax15
32	stayc	StabilityCode	StayVS maturity code	OO / QQ / RR / SS
33	mento	MentorOrganizing	Stage-appropriate learning guidance	“Study after ax1–ax4”
34	diff	VersioningHistory	What changed from prior versions	“OOv1->OOv2: strengthened…”
36	con	ConsRef	Objection addressing this element	Con-A.1 — th8 Is Not a Theorem; Bistability Is Asserted, Not Derived
37	pro	ProsRef	Response defending this element	Pro-A.1 — Response to Con-A.1 (th8 Bistability)
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)

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 POST Operational Fields. # after ExplicitName indicates a countable collection (items numbered).

#	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 reformulation
27	hh	HistoryHeap#	Recently deprecated content	Superseded by OOv2
20	jj	JammedJob#	Current blocker for this element	“Needs ax25 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 proof depends on ax5
29	yy	YesYet#	Test case for reliability checking	“Does ax5 hold under modal logic K?”

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.

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.

#	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

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).

#	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

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.

#	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:

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):

#	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/compiler/ww/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 (Human Exceeding) is absorbed into ax3.

1. The original content of ax5 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 --- (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 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 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.

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).

• 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 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 AIMS Plotter — Phase 3 Tasks — PoR field review against 7Sp DOISI designs, and tech-debt Jubilee argument for recompile cycles.)

---

12. Compilation — SISYF

12.1 Modes

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/{version}/
MIGRATE	Structure change (e.g., ax1 to pet-ax1)	Transform existing files to new naming structure

12.2 User Decisions

#	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

BEST	Name in Context	Format	Example
Brief	First mention or standalone	Model-element (hyphenated)	Pet-ax5, Jub-th8, 4Be-A26
Brief	Subsequent (model clear)	Element only	ax5, th8
Explicit	Formal heading	Full with title	Pet-ax5 — Containment
Explicit	RST cross-reference	:ref:`pet-ax5`	renders as “Pet-ax5 — Containment”
Brief	Code/label context	All lowercase	pet-ax5

---

14. Label Examples

Label	Meaning
pet-ax5	Pet Axiom 5, canonical PoR (latest, expert, English)
pet-ax5-oov2	Pet ax5, frozen at OOv2
pet-ax5-easy	Pet ax5, beginner view (latest)
pet-ax5-oov2-easy	Pet ax5, OOv2, beginner
pet-ax5-prod-vjud	Pet ax5, producer depth, Jewish perspective
pet-ax5-net-oov2-easy-vjud	Pet ax5, network field, OOv2, beginner, Jewish perspective
pet-ax5-lde	Pet ax5, German language-specific cultural insight
pet-ax-net	Pet axiom dependency network (collection)
jub-th8-stayc	Jub-th8 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 logical framework (D2 chain: ax + logic)
pet-ax5-needs	Pet-ax5 upstream dependencies (D2 chain: ax + needs)
pet-ax5-limit	Pet-ax5 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 Knowledge-Uncertainty Feedback Integration Refinery (KUFIR) — or “Knowledge Pipeline Refinery” (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 — FeedbackFlows, LabLogs and LifeLogs, AnyAims, MockupModels, EnclosedExperiments, StableSystems — 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: Phase 2I-6: HELL Migration — Quest Labels to Flat Finding Register

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.

• D1/D2 Testing Matrix — Cross-Model Usage Evidence — D1/D2 combination evidence (BREACH 1.7)

• D2 Chaining Evidence — Natural Multi-Type Combinations — natural chaining cases for/against deeper nesting

• Alignment Class Echoes — Cross-Model Topic Matches — cross-model echo observations

• PoR Field Collision Check — “model” Ambiguity — model name collision instances

• PoR Field Usage Census — Phase 2I-4 First Compilation — PoR field real-world usage and proposed new fields

Agent prompts for this task:

• Reap Design Questions During Integration — Agent Prompt (instructs integration agents to collect evidence for questions 1–6 alongside their primary sorting work)

• PoR Field Usage Census — Agent Prompt for Migration (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 (Phase 2I Integration Tests — Design Questions Requiring Real Data) 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 PoR Field Usage Census — Phase 2I-4 First Compilation for the data collection file and PoR Field Usage Census — Agent Prompt for Migration 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 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``:

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:

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 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 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.

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, ax2, ax3, (gap), ax5, ax6… ax14, ax15… ax25 — 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.

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 (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.