updated generation process

1 files changed, 33 insertions, 22 deletions

diff --git a/STAGE_MAP.md b/STAGE_MAP.md
index ee77f96..9e05842 100644
--- a/STAGE_MAP.md
+++ b/STAGE_MAP.md
@@ -1,28 +1,38 @@
-# GAP paper-to-code map
+# GAP paper-to-code and provenance map
 
-The original implementation batches adjacent conceptual stages into two model
-calls. Prompt-A returns the ordered proof-plan nodes and mutable slots; Prompt-B
-re-instantiates that plan and returns the regenerated proof and question.
-The package writes each conceptual output separately so every paper stage is
-visible in an end-to-end run without changing either prompt.
+The recovered original Putnam generator at `PutnamVariants@c3bed737` makes two
+model calls: Prompt-A returns 1--5 `core_steps` plus mutable-slot descriptions,
+and Prompt-B directly returns a complete question and solution. Those exact
+historical prompts remain byte pinned in `prompts.py`.
 
-The ordered nodes form a path-structured DAG, the exact graph induced by a
-minimal sequential proof plan. `ProofPlanDAG` validates node identity,
-dependencies, acyclicity, terminal connectivity, and order. The five judges
-receive stable node IDs with the method-label sequence, and a verdict is valid
-only when its step-by-step check covers every node.
+The manuscript describes a richer five-stage procedure. The default executable
+path in `paper_pipeline.py` implements those operations explicitly, using the
+paper-aligned prompts in `kernel_prompts.py`. It does not claim these new
+prompts are byte-identical to the historical two-call generator.
 
 | Paper operation | Implementation | Saved artifact |
 |---|---|---|
 | Surface rename | `SurfacePipeline.run_family` | `surface_<family>_variant.json` |
-| 1. Reference solution to proof structure | `KernelPipeline.extract_plan` + `ProofPlanDAG` validation | `01_proof_dag.json` |
-| 2. Content-free method plan | `KernelPipeline.extract_plan` | `02_method_plan.json` |
-| 3. Mutable-slot identification | `KernelPipeline.extract_plan` | `03_mutable_slots.json` |
-| 4. Proof regeneration | `KernelPipeline.generate_candidate` | `04_regenerated_proof.json` |
-| 5. Problem rendering | `KernelPipeline.generate_candidate` | `05_variant_question.json` |
-| Five-judge verification | `KernelPipeline.verify_candidate` | five call records and one iteration record per round |
-| Consecutive-pass protocol | `KernelPipeline.verify_candidate` | `K=2`; any rejection resets the streak |
-| Repair loop | `KernelPipeline._repair` | complete corrected question and solution; at most `T=15` rounds |
+| 1. Reference solution to concrete proof DAG | `PaperKernelPipeline.construct_dag` + `ProofDAG` validation | `01_proof_dag.json` |
+| 2. Content-free method plan | `PaperKernelPipeline.summarize_methods` | `02_method_plan.json` |
+| 3. Guarded replacement generation | `PaperKernelPipeline.generate_replacements` | `03_replacement_vNN.json` |
+| 4. Node-by-node DAG diffusion | `PaperKernelPipeline.diffuse_dag` | `04_diffused_proof_vNN.json` |
+| 5. Answer-to-question rendering | `PaperKernelPipeline.render_variant` | `05_rendered_variant_vNN.json` |
+| Five-judge verification | `PaperKernelPipeline.verify` | five call records and one iteration record per round |
+| Consecutive-pass protocol | `PaperKernelPipeline.verify` | `K=2` on the unchanged bundle hash |
+| Repair loop | `PaperKernelPipeline.build_bundle` | rerun stages 3--5 from judge feedback; at most `T=15` rounds |
+
+## Enforced contracts
+
+- The concrete DAG may branch; every dependency must reference an earlier node,
+  and every node must contribute to the terminal node.
+- The method plan contains exactly one method label per DAG node.
+- Every replacement records its source node, exact old/new values, mathematical
+  guard, and guard justification.
+- The diffused proof must preserve node IDs, dependencies, and method labels.
+- The rendered solution must cite every node in order and retain the diffused
+  terminal answer.
+- Every judge must discuss every node ID and every replacement slot ID.
 
 ## Per-item artifacts
 
@@ -36,6 +46,7 @@ items/<item-id>/
   final.json
 ```
 
-Prompt literals are byte-locked by `PROMPT_SHA256SUMS` and
-`tests/test_prompts.py`. The OpenAI adapter does not pass a temperature
-argument; `o3` therefore uses its supported default.
+Historical prompt literals are byte-locked by `PROMPT_SHA256SUMS` and
+`tests/test_prompts.py`. The new five-stage prompts are versioned source code
+and covered by schema and end-to-end tests. The OpenAI adapter does not pass a
+temperature argument; `o3` therefore uses its supported default.