.. Migration note (2026m04d04): Claude copied this file during VV-to-HELL migration.
Old path: ``vv/jub/oov2/prompts/prompt_2I-6.rst`` (as given by LLoL)
New path: ``hell/ll/jub/b/40/prompt_2I-6.rst`` (as chosen by Claude)
Category: JUB OOv2 prompt
.. meta::
:description: Execution prompt for writing public-facing documentation that explains the BEST Names architecture to four distinct audience levels on balospe.com.
:keywords: JUB OOv2, Phase 2I-6, public documentation, BEST Names, audience pages, naming architecture, easy, expert, producer, architect
:author: Yah, Yas, everyone, LLoL as Laurence Loewe of Laodicea, ClaudeOp46Max, Anthropic, and Spirit of Boolean Truth
:og:card:title: Phase 2I-6: Public
Documentation Prompt
:og:card:description: Four audiences, four explanations. This prompt creates public-facing pages that make the BEST Names architecture accessible to everyone.
.. SOCIAL-CARD-QUALITY-COMPARE --- OO (default effort) vs PP (max effort), 2026-03-26
OO :description: Prompt for Phase 2I-6 writing public-facing documentation that explains the BEST Names architecture to four audiences.
OO :keywords: JUB OOv2, Phase 2I-6, public documentation, BEST Names, audience pages, naming architecture, matheology, balospe.com
OO :og:card:title: Phase 2I-6: Public
Documentation Prompt
OO :og:card:description: Prompt for writing public-facing documentation explaining the BEST Names architecture to four distinct audiences.
PP :description: Execution prompt for writing public-facing documentation that explains the BEST Names architecture to four distinct audience levels on balospe.com.
PP :keywords: JUB OOv2, Phase 2I-6, public documentation, BEST Names, audience pages, naming architecture, easy, expert, producer, architect
PP :og:card:title: Phase 2I-6: Public
Documentation Prompt
PP :og:card:description: Four audiences, four explanations. This prompt creates public-facing pages that make the BEST Names architecture accessible to everyone.
.. 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: 38 chars (excl
)
- [ ] PP title more compelling than OO title
- [ ] PP description more accurate than OO description
- [ ] Description hooks without misleading
- [ ] Keywords specific to this page's actual content
- [ ] No language rule violations
- [ ] Character counts verified
*********************************************************************
Phase 2I-6: Public-Facing Documentation Pages
*********************************************************************
.. note::
**200K-token execution prompt.** Copy-paste everything below the
horizontal rule into a new Claude Code session.
**Prerequisite:** Phase 2I-5 (adversarial stress-test) should
have completed and any critical fixes applied. The naming system
must be stable before writing public documentation.
----
/clear
/compact
/effort max
You are executing Phase 2I-6 of the JUB OOv2 matheology project:
**writing public-facing documentation** that explains the BEST
Names architecture to four distinct audiences. These pages will be
part of the live balospe.com site.
This session creates content for real readers. Quality matters.
====================================================================
STEP 0 --- READ ALL REQUIRED FILES (DO THIS FIRST)
====================================================================
ax1_A1. AHA DESIGN DOC (5D architecture):
source/matheology/compiler/ww/5d-link-naming-matheology-aha.rst
ax2_A2. ADVERSARIAL STRESS-TEST REPORT (to know what was fixed):
source/matheology/vv/jub/oov2/llog/2I-adversarial-stress-test.rst
ax3_A3. COMPILED EXPERT VIEW (real example of the system in use):
source/matheology/axioms/expert/index.rst
ax4_A4. COMPILED EASY VIEW:
source/matheology/axioms/easy/index.rst
ax5_A5. MATHEOLOGY INDEX:
source/matheology/index.rst
ax6_A6. SITE-WIDE INCLUDE FILES (for page prefix/postfix convention):
source/_templates/include-file/page-prefix.rst
source/_templates/include-file/page-postfix-prelink.rst
source/_templates/include-file/page-postfix-postlink.rst
====================================================================
STEP 1 --- EASY PAGE (General Public)
====================================================================
Create: ``source/matheology/naming-easy.rst``
Label: ``.. _naming-easy:``
**Audience:** Someone who clicked a link and wants to understand
what the labels on this site mean. No technical background assumed.
**Contents:**
1. Title: "How We Name Things on This Site"
2. Start with a real example: "You might see a label like
``Pet ax5_A5`` or a link labeled ``ax5_A5 --- Containment``. Here's
what that means..."
3. Explain the model prefix (Pet = one way of organizing axioms,
Jub = another)
4. Explain element types (axiom = starting point, theorem = proven
result) using everyday analogies
5. Explain depths: "If you're new, look for pages marked 'easy'.
Experts can find the full technical details."
6. Skip version, state, and language details --- too much for this
audience
7. End with: "Every label is a stable address. You can bookmark it,
share it, and it will keep working."
8. FeedbackFlow link
**Tone:** Conversational, respectful, brief. Under 500 words. No
jargon. No LaTeX. Think "museum placard" not "textbook."
====================================================================
STEP 2 --- PRODUCER PAGE (Teachers, Preachers, Communicators)
====================================================================
Create: ``source/matheology/naming-producer.rst``
Label: ``.. _naming-producer:``
**Audience:** Someone who teaches, preaches, or writes about
these axioms and needs to cite them correctly. Comfortable with
structured references but not a software developer.
**Contents:**
1. Title: "Naming Convention for Teaching and Communication"
2. The prose reference convention (from AHA Section 15):
first mention = Model + Element, subsequent = Element only
3. How to cite in sermons, lectures, papers:
"Pet ax5_A5 --- Containment" or "ax5_A5 (Pet)" in parenthetical style
4. The depth system: what the producer view contains vs. the
expert and easy views
5. Worldview perspectives: how to reference the same axiom through
different traditions (``-vjud``, ``-vchr``, ``-visl``)
6. How to link to specific views when sharing online:
URL structure explained simply
7. Version pinning: why ``-oov2`` matters for academic citations
8. FeedbackFlow link
**Tone:** Professional, structured, practical. Think "style guide
for contributors." 800--1200 words.
====================================================================
STEP 3 --- EXPERT PAGE (Researchers, Theologians)
====================================================================
Create: ``source/matheology/naming-expert.rst``
Label: ``.. _naming-expert:``
**Audience:** Researchers, mathematicians, theologians who will
work directly with the PoR content. Comfortable with formal
notation and systematic structures.
**Contents:**
1. Title: "BEST Names Architecture --- Expert Reference"
2. The knowledge pipeline (PoE→PoC→PoR→PoT→PoU) with brief
explanation of each stage
3. The 7 dimensions table (from AHA Section 3)
4. The label grammar with parsing rules
5. The complete D1--D7 registries (from AHA Sections 4--10)
6. The 45 PoR fields (complete list from AHA Section 11)
7. The extraction matrix (from the skill specification)
8. The link stability policy (from AHA Section 13)
9. Cross-references to the AHA design doc for governance details
10. FeedbackFlow link
**Tone:** Precise, comprehensive, reference-quality. This is the
page a researcher bookmarks. 2000--3000 words. Tables are fine.
====================================================================
STEP 4 --- ARCHITECT PAGE (Developers, System Designers)
====================================================================
Create: ``source/matheology/naming-architect.rst``
Label: ``.. _naming-architect:``
**Audience:** Software developers, system architects, and future
ResearchCity contributors who need to understand the technical
design decisions.
**Contents:**
1. Title: "BEST Names Architecture --- Technical Design"
2. The ``.. include::`` problem and why it was solved this way
3. The LL(1) parsing proof: why hyphens, why this dimension order
4. The collision-free proof for D6 sub-namespaces
5. The compilation skill architecture (modes, extraction matrix,
stub policy)
6. Integration with Sphinx: labels, i18n, toctrees, build system
7. Integration with Evolvix: POST codes, StayVS, BEST naming
8. The link stability policy and Jubilee recompile argument
9. How to add a new model, element type, worldview, or language
10. Known limitations and future work (from the stress-test)
11. FeedbackFlow link
**Tone:** Technical, decision-oriented. Focus on the "why" behind
each design choice. This is the page an engineer reads before
contributing. 2500--4000 words. Code examples welcome.
====================================================================
STEP 5 --- CREATE INDEX AND NAVIGATION
====================================================================
Create: ``source/matheology/naming.rst``
Label: ``.. _naming:``
1. Title: "How We Name Things --- Choose Your Depth"
2. Brief paragraph: "The balospe.com naming system is designed for
audiences from beginners to architects. Pick the level of
detail you need:"
3. Four cards/links pointing to the four pages:
- Easy: "Just want to understand the labels? Start here."
- Producer: "Teaching or writing about these axioms? Read this."
- Expert: "Working with the full system? Here's the reference."
- Architect: "Building on this system? Here's the technical design."
4. Add ``naming`` to the toctree in ``source/matheology/index.rst``
under an appropriate caption.
====================================================================
STEP 6 --- CHECK BUILD
====================================================================
Run ``make html`` and confirm:
1. All 5 new pages render correctly
2. Zero new warnings
3. All cross-references resolve
4. Navigation between depth levels works
5. FeedbackFlow links are correctly formatted
====================================================================
STEP 7 --- APPEND TO DEBUG FILE
====================================================================
APPEND a session entry to:
source/matheology/vv/jub/oov2/llog/llog_2026m03d21_restructuring-phase1-prompts-reply-overviews-for-debugs.rst
With:
1. Verbatim prompt (this entire prompt, in a code-block)
2. List of all files created/modified
3. Word counts for each page
4. Build check result
====================================================================
CRITICAL RULES
====================================================================
1. llog files are APPEND-ONLY.
2. NEVER delete content files.
3. NEVER abbreviate prompts in llogs.
4. Every page MUST start with ``.. include:: /_templates/include-file/page-prefix.rst``
and end with the FF postfix block (if FF link is included).
5. Content is for REAL READERS. Write like a human author, not a
template engine.
6. The easy page must be genuinely easy. Test: could a 16-year-old
with no background understand it?
7. The architect page must be genuinely technical. Test: could a
senior engineer implement a new dimension from this spec alone?
8. LANGUAGE RULES:
a. NEVER use bare "Jubilee" as standalone noun.
b. NEVER use "the" for unproven superlatives.
.. 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.