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

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

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/<name>/
  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:

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_<model>_<date>.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?