.. _dd-promy-pipeline: ********************************************************************* DD: PROMY Pipeline Specification (Draft) ********************************************************************* :Created: 2026-03-29 :Updated: 2026-03-30 (SEED/FEED/GROW/REAP lifecycle adopted) :Origin: Informal PROMY discussion during site reorganization session, refined after first PROMY:SEED run on e7He :Status: Draft --- SEED/FEED/GROW tested on e7He; REAP prompt drafted .. contents:: On this page :depth: 2 :local: The Problem ============= FORGE produces raw model content inside append-only llogs: axioms, theorems, symbols, predicates, proofs, test results, and repairs. This content is correct but unstructured --- it lives in a 10,000-line session transcript, interleaved with prompts, failed attempts, corrections, and meta-discussion. SISYF needs clean, structured model source files to assemble audience-depth views. The gap between FORGE output and SISYF input is PROMY's job. Currently this gap is bridged informally (or not at all), which is why FORGE-generated models (e7He, e7Ch, e7Tr) lack the structure that older models (PET, JUB) have. The SEED/FEED/GROW/REAP Pipeline =================================== PROMY's four stages follow the natural growth cycle used throughout the POST system (SEED → FEED → GROW → REAP). They also map onto the ZION framework (Zoning → Investigating → Organizing → Navigating): .. list-table:: :header-rows: 1 :widths: 12 12 12 54 * - Stage - Growth - ZION - What PROMY does * - **SEED** - Plant - Zoning - Identify and extract axioms, theorems, properties verbatim from FORGE llogs into standalone files. Zone the territory: what exists, how many statements, which labels. * - **FEED** - Nourish - Investigating - Fill gaps in the standard file set. Investigate which symbols were used, which submodels exist, which logics apply, which aims are open. Feed the record so the next stage has everything it needs. * - **GROW** - Integrate - Organizing - Apply HELL evidence (corrections, repairs, new findings) to update axiom and theorem statements. Organize beyond the model's horizon: link to diverse views, cross-reference logs, integrate across the system. This is the read-write dangerous step. * - **REAP** - Harvest - Navigating - Audit the full session. Close the books. Produce tailored overviews for three audiences (beginner, producer, expert) so each gets a landing page calibrated to their level. The model is now ready for SISYF. Each stage is a named lifecycle command (``PROMY:SEED``, ``PROMY:FEED``, ``PROMY:GROW``, ``PROMY:REAP``) with an explicit human review gate before transitioning to the next. PROMY:SEED --- Zone the Territory ------------------------------------ Pull axioms, theorems, symbols, predicates, and definitions out of FORGE llogs into standalone ``.rst`` files with proper labels. Also create the initial ``aa.rst`` (Any Aims) and ``llog.rst`` (local pointer to HELL logs). Write the PROMY llog in HELL. This is a **read-only** operation on the llog (extracting, not modifying). Low risk. *Input:* FORGE llog (e.g., ``sa3_2026m03d28/llog.rst``) *Output:* ``axioms.rst``, ``theorems.rst``, ``models.rst``, ``logics.rst``, ``aa.rst``, ``llog.rst`` + PROMY llog in HELL *Transition:* Human reviews extracted content for completeness. When satisfied: ``PROMY:FEED`` PROMY:FEED --- Fill the Gaps ------------------------------- Ensure the model directory has the complete standard file set (see below). Investigate which symbols, predicates, and cross-references exist. Fill in any files that SEED left incomplete. Check that all ``:ref:`` labels resolve. Run ``make html`` to confirm zero new warnings. *Input:* Files from SEED + existing model files (symbols.rst, predicates.rst, etc.) *Output:* Complete model directory matching the standard layout, with all gaps filled and all cross-references checked *Transition:* Human reviews directory structure and file completeness. When satisfied: ``PROMY:GROW`` PROMY:GROW --- Integrate Evidence ------------------------------------ Apply HELL evidence (corrections, repairs from TEMPER rounds, HELL/con and HELL/pro findings) to update axiom and theorem statements. Link to diverse views across the system. Organize cross-model connections. This is the **read-write dangerous** step. Requires git commit before and after. No unsupervised modifications. *Input:* Complete model files from FEED + HELL evidence *Output:* Updated model source files with integrated corrections *Transition:* Human reviews all diffs. When satisfied: ``PROMY:REAP`` PROMY:REAP --- Harvest and Navigate --------------------------------------- Audit the full PROMY session. Close the books: check all AA items are either resolved or explicitly deferred. Produce **three** tailored overview pages: - ``overview-beginner.rst`` --- accessible to someone with no formal background. What is this model about? Why should anyone care? Where to start reading. - ``overview-producer.rst`` --- for someone building on or with the model. What are the key interfaces? What depends on what? Where are the open edges? - ``overview-expert.rst`` --- for a formal logician or mathematician. What is the axiomatic structure? What logics are used? What is the relationship to standard results in the literature? Write the final PROMY llog entry summarizing the full session. The model is now ready for SISYF to compile into audience-depth downstream pages. *Input:* Updated model files from GROW + full session record *Output:* Three overview pages + final llog entry + closed AA items *Transition:* Session complete. Model is ready for SISYF. Standard Model File Set ========================= After a full PROMY pass (all four stages), every model directory should contain: :: model// index.rst Main page + toctree axioms.rst All axioms with :ref: labels theorems.rst All theorems with :ref: labels symbols.rst Symbol table predicates.rst Predicate specifications models.rst Submodel architecture logics.rst Formal disciplines used overview-beginner.rst Plain-language overview overview-producer.rst Builder-oriented overview overview-expert.rst Formal/mathematical overview aa.rst Any Aims tracking (POST convention) llog.rst Local pointer to HELL llogs Every model has submodels (even if only "m0 prerequisites + m1--m7 stages"). Every model uses specific logics (even if inherited from PET/JUB --- spell them out). "Not applicable" is never acceptable for ``models.rst`` or ``logics.rst`` --- the information exists, it only needs to be documented. **Which files each stage produces:** .. list-table:: :header-rows: 1 :widths: 30 15 15 15 15 * - File - SEED - FEED - GROW - REAP * - axioms.rst - create - check - update - * - theorems.rst - create - check - update - * - models.rst - create - check - - * - logics.rst - create - check - - * - symbols.rst - - fill gaps - - * - predicates.rst - - fill gaps - - * - aa.rst - create - update - update - close * - llog.rst - create - update - update - finalize * - overview-beginner.rst - - - - create * - overview-producer.rst - - - - create * - overview-expert.rst - - - - create * - index.rst - update toctree - check - - finalize LLog Storage ============== PROMY llogs record the Prometheus cycle: what toxins (errors, flaws, inconsistencies) were found, what was purified, and what regrew. These records are critical because: 1. **The purification is dangerous.** PROMY modifies source data. If a modification introduces a new error, the llog is the only way to trace what happened and why. 2. **The cycle repeats.** New FORGE sessions produce new raw content. New HELL evidence exposes new flaws. Each PROMY pass must know what previous passes did to avoid re-introducing fixed errors or overwriting intentional changes. 3. **The liver regrows.** Models grow. What was clean after one PROMY pass may need re-purification after the next FORGE session. The llog tracks which version of the model each purification targeted. **Storage location:** All PROMY llogs live in HELL, under a dedicated directory: :: hell/llog/promy/ promy_e7he_2026m03d29.rst promy_e7ch_2026m04d01.rst ... The naming convention is ``promy__.rst``. The ``promy_`` prefix groups all PROMY logs together when listing the directory. The model name identifies which model was purified. The date identifies when. **Why HELL?** HELL is "Historically Experienced Lessons Learned" --- an adversarial audit record. PROMY logs are exactly that: a record of what was wrong, what was done about it, and whether the fix held. They belong with the other adversarial records, not inside a compiler's implementation directory. **Future migration:** When the broader llog migration happens (moving FORGE and VV llogs into ``hell/llog/`` as well), PROMY llogs will already be in the right place. The directory structure will become: :: hell/llog/ forge/ forge_sa2_2026m03d27/ forge_sa3_2026m03d28/ promy/ promy_e7he_2026m03d29.rst vv/ vv_jub_oov2_2026m03d21/ ... Safety Model ============== - **SEED** and **FEED** are low-risk (read-only with respect to existing content; they create new files from llog content or fill gaps). Can run with lightweight oversight. - **GROW** is high-risk (modifies source data). Requires: - ``git commit`` before starting (clean baseline) - Human review of every diff before accepting - ``git commit`` after completion (auditable endpoint) - No batch mode --- each modification is reviewed individually - **REAP** is low-risk (creates overview pages and audit entries). The content is new writing, not modification of existing formal statements. PROMY must **never** be invoked by a blanket regeneration command. Each step is a separate operation with a separate human gate. Open Questions ================ - Should the ``llog.rst`` file in each model directory be a literal RST include of the HELL llog, or a hand-maintained pointer page with ``:doc:`` links? (Current practice: pointer page.) - How should PROMY handle cross-model dependencies (e.g., e7He axioms that reference e7Day axioms)? PROMY is defined as intra-model, but extraction may surface cross-model issues. - Should there be an explicit ``make html`` check between FEED and GROW to check all labels resolve before attempting modifications? - How do the three REAP overview pages relate to SISYF's audience- depth views? Are they the same thing (in which case SISYF produces them), or are they model-local summaries that SISYF then integrates across models?