qwen-sci 0.2.2__py3-none-any.whl

src/agents/idea_agent/agent/prompts/__init__.py

@@ -0,0 +1,48 @@
+from src.agents.idea_agent.agent.prompts.advanced_analysis import ADVANCED_ANALYSIS_PROMPT
+from src.agents.idea_agent.agent.prompts.component_novelty_evaluation import (
+    COMPONENT_NOVELTY_EVALUATION_PROMPT,
+)
+from src.agents.idea_agent.agent.prompts.mcts_evaluation import MCTS_IDEA_EVALUATION_PROMPT
+from src.agents.idea_agent.agent.prompts.re_analysis_replan import RE_ANALYSIS_REPLAN_PROMPT
+from src.agents.idea_agent.agent.prompts.reference_grounding import REFERENCE_GROUNDING_PROMPT
+from src.agents.idea_agent.agent.prompts.algorithm_structuring import ALGORITHM_STRUCTURING_PROMPT
+from src.agents.idea_agent.agent.prompts.algorithm_alignment import ALGORITHM_ALIGNMENT_PROMPT
+from src.agents.idea_agent.agent.prompts.scientific_materialization import (
+    SCIENTIFIC_MATERIALIZATION_PROMPT,
+)
+from src.agents.idea_agent.agent.prompts.idea_introduction import IDEA_INTRODUCTION_PROMPT
+from src.agents.idea_agent.agent.prompts.idea_fusion import IDEA_FUSION_PROMPT
+from src.agents.idea_agent.agent.prompts.scientific_debate import SCIENTIFIC_DEBATE_PROMPT
+from src.agents.idea_agent.agent.prompts.idea_result_alignment import IDEA_RESULT_ALIGNMENT_PROMPT
+from src.agents.idea_agent.agent.prompts.keynote_ops import (
+    KEYNOTE_GROUP_SUMMARY_PROMPT,
+    KEYNOTE_SCORING_PROMPT,
+    KEYNOTE_SINGLE_COMPRESSION_PROMPT,
+)
+from src.agents.idea_agent.agent.prompts.experiment_findings_extraction import (
+    EXPERIMENT_FINDINGS_EXTRACTION_PROMPT,
+)
+from src.agents.idea_agent.agent.prompts.topic_background import TOPIC_BACKGROUND_PROMPT
+from src.agents.idea_agent.agent.prompts.rag_query import RAG_QUERY_PROMPT
+
+
+PROMPTS = {
+    "advanced_analysis": ADVANCED_ANALYSIS_PROMPT,
+    "component_novelty_evaluation": COMPONENT_NOVELTY_EVALUATION_PROMPT,
+    "mcts_evaluation": MCTS_IDEA_EVALUATION_PROMPT,
+    "re_analysis_replan": RE_ANALYSIS_REPLAN_PROMPT,
+    "reference_grounding": REFERENCE_GROUNDING_PROMPT,
+    "algorithm_structuring": ALGORITHM_STRUCTURING_PROMPT,
+    "algorithm_alignment": ALGORITHM_ALIGNMENT_PROMPT,
+    "scientific_materialization": SCIENTIFIC_MATERIALIZATION_PROMPT,
+    "idea_introduction": IDEA_INTRODUCTION_PROMPT,
+    "idea_fusion": IDEA_FUSION_PROMPT,
+    "scientific_debate": SCIENTIFIC_DEBATE_PROMPT,
+    "idea_result_alignment": IDEA_RESULT_ALIGNMENT_PROMPT,
+    "keynote_group_summary": KEYNOTE_GROUP_SUMMARY_PROMPT,
+    "keynote_scoring": KEYNOTE_SCORING_PROMPT,
+    "keynote_single_compression": KEYNOTE_SINGLE_COMPRESSION_PROMPT,
+    "experiment_findings_extraction": EXPERIMENT_FINDINGS_EXTRACTION_PROMPT,
+    "topic_background": TOPIC_BACKGROUND_PROMPT,
+    "rag_query": RAG_QUERY_PROMPT,
+}

src/agents/idea_agent/agent/prompts/advanced_analysis.py

@@ -0,0 +1,235 @@
+ADVANCED_ANALYSIS_PROMPT_SURVEY_LED_WITH_PAPERS = """
+You are the lead author preparing an top-tier paper on the topic "{topic}".
+
+== Mature idea (optional; if empty, ignore) ==
+{mature_idea}
+
+== Mature idea source ==
+{mature_idea_source}
+
+== Refinement scope (optional; if empty, ignore) ==
+{refinement_scope}
+
+== Refinement scope source ==
+{refinement_scope_source}
+
+You have:
+(1) Survey contents (PRIMARY source of problem framing, clusters, and gaps):
+{survey_contents}
+
+(2) Curated cited-paper capsules derived from survey keynotes (SECONDARY source; use for evidence, baselines, feasibility details, and concrete instantiations ONLY):
+{papers}
+
+(3) Experiment findings extracted from raw ablation results (OPTIONAL; use only if present):
+{experiment_findings}
+
+Core principle (must follow):
+- Survey drives the agenda: method clusters + unresolved mechanism bottlenecks + evaluation blind spots MUST be derived from survey_contents.
+- Cited-paper capsules may refine or substantiate the survey-derived bottlenecks and gaps, but MUST NOT redefine the agenda or introduce a new main axis not present in the survey framing.
+- This stage is a 1.0 -> 1.1 calibrator, NOT a 2.0 invention stage. Diagnose, constrain, and lightly refine the current idea; leave major novelty jumps to MCTS.
+- If mature_idea is provided and mature_idea_source is `config_explicit` or `input_explicit`, keep the same topic, core hypothesis, and primary mechanism axis. Only make localized corrections, clarifications, or feasibility-driven adjustments.
+- If mature_idea_source is `input_inferred` or `empty`, treat the current mature_idea as provisional. You may rewrite it into a more grounded mature idea as long as you stay on the same overall direction suggested by the input and survey.
+- If refinement_scope is provided, treat it as a hard edit boundary. Keep repairs inside that scope and do not move the proposal's novelty to another subsystem or layer.
+- If refinement_scope_source is `input_inferred` or `empty`, you may sharpen or generate a clearer grounded refinement_scope from the survey and papers.
+- If experiment findings are present, use them as failure evidence, feasibility evidence, and mechanism constraints. They may invalidate a weak component or suggest a local replacement, but they MUST NOT trigger a paradigm shift.
+- Prioritize mechanism bottlenecks over evaluation tooling. Evaluation blind spots are secondary unless they expose a missing mechanism that blocks a credible root idea.
+- Do NOT directly introduce a new primary mechanism family. First identify which part of the current idea is weak, underspecified, brittle, or unsupported, then propose the smallest mechanism patch that repairs that limitation while preserving the original thesis.
+- Do NOT default to gate/router/controller/monitor style patches just because they are easy local edits. Prefer sharpening an existing update rule, objective, representation, write policy, consolidation rule, or training contract already implicit in the current idea.
+- A new gate/threshold/router is allowed only when the mature_idea already centers that decision surface and the patch merely calibrates or simplifies it. Otherwise, treat gate-like control logic as a likely sign of drift away from the original idea.
+- If no clearly valuable mechanism-level local patch exists, preserve the current mature_idea instead of inventing a gate/router/controller/threshold/budget fix.
+- If the only available local change mainly improves explainability, diagnosability, observability, auditing, monitoring, or validation tooling, preserve the current mature_idea instead of elevating that safe repair into the main contribution.
+- If the current mature_idea is training-free or inference-time only, preserve that character when possible. Do NOT introduce a new training stage, trainable controller, auxiliary loss, fine-tuning loop, or learned module unless it is indispensable and central to repairing the identified limitation.
+- For training-free ideas, prefer rule-level, objective-free, or inference-time repairs first. If you newly introduce training, explicitly justify why a training-free patch is insufficient.
+- If no convincing local repair exists within refinement_scope, preserve the current mature_idea instead of escaping that scope.
+
+Perform the steps below explicitly before answering:
+1) Survey-led clustering:
+   Map the dominant method clusters mentioned in the survey. For each cluster, summarize:
+   - assumptions
+   - supervision/training signals
+   - implementation constraints or operating assumptions (as described or implied by the survey)
+   Cited-paper capsules can be used only to add concrete examples, representative baselines, or implementation constraints for clusters already defined by the survey.
+
+2) Mechanism bottleneck stress test (survey is the ground truth for "what is missing"):
+   Extract unresolved mechanism-level limitations from the survey first, then list any evaluation blind spots that prevent those limitations from being measured cleanly.
+   You MAY use cited-paper capsules to corroborate a bottleneck (e.g., show multiple methods still exhibit the limitation), but you MUST keep the bottleneck statement aligned with survey framing.
+   Do NOT let an evaluation gap become the main novelty unless it directly reveals a missing mechanism on the current method axis.
+
+3) Conservative root calibration:
+   Produce a search-ready root idea that directly targets the extracted SURVEY mechanism bottlenecks while staying close to the current mature_idea when one is provided.
+   The root idea should be a minimal but meaningful refinement:
+   - read like a v1.1 update of the current idea, not a replacement idea,
+   - preserve the same main method axis,
+   - keep most of the existing structure if it is still defensible,
+   - explicitly identify which existing component/assumption/objective is weak and what local patch fixes it,
+   - prefer repairing an existing rule or mechanism already present in the idea over adding a new gating or routing layer,
+   - if the only available delta is easier explanation, diagnosis, monitoring, budgeting, or validation, keep the mature_idea unchanged instead of turning that safe repair into the new thesis,
+   - if the current idea is training-free, prefer training-free local repairs over introducing new optimization or fine-tuning machinery,
+   - only adjust components/objectives/protocols that are weak, unsupported, or contradicted by experiment findings,
+   - use evaluation gaps only as evidence for what must be measured to validate the mechanism patch, not as the main proposal.
+
+4) Validation tooling:
+   Specify what experiments/protocols/tools are required to validate the calibrated root idea credibly.
+   Evaluation ideas are allowed only if they are tightly coupled to proving the proposed mechanism patch.
+   Do not let the validation protocol become the primary contribution.
+
+Return STRICT JSON (no prose, no Markdown) with the schema:
+{{
+  "key_methods": ["..."],                          // survey-led cluster names or dominant families
+  "field_consensus": ["..."],                      // constraints / assumptions / consensus points the new idea should respect
+  "existing_problems": ["..."],                    // survey-led mechanism or structural limitations (primary driver of root_idea)
+  "evaluation_gaps": [
+    {{
+      "gap": "concise description of a measurement blind spot (MUST originate from survey_contents)",
+      "why_it_matters": "impact on validating the mechanism bottleneck or proposed patch",
+      "validation_expectation": "what the validation setup must include to measure that mechanism credibly"
+    }}
+  ],
+  "future_directions": ["..."],                    // incremental but useful; must still be anchored in survey
+  "preserve_current_idea": {{
+    "keep_original": false,
+    "reason": "empty unless no convincing valuable mechanism-level local patch exists and the mature_idea should be preserved"
+  }},
+  "mature_ideas": [
+    {{
+      "idea_id": "stable identifier",
+      "title": "independent mature idea title",
+      "hypothesis": "central hypothesis",
+      "scientific_object": "object or process",
+      "mechanism": "causal or formal mechanism",
+      "assumptions": ["..."],
+      "evidence_basis": ["SURVEY_ANCHOR: ..."],
+      "target_gap_ids": ["gap id when available"],
+      "refinement_scope": "allowed refinement boundary",
+      "falsifier": "result that would refute the idea",
+      "counterexamples": ["relevant counterexample or negative evidence"],
+      "retrieval_queries": ["idea-specific retrieval query"],
+      "mechanism_chain": ["object -> mechanism -> observable consequence"],
+      "validation_targets": ["testable target"],
+      "anchor_policy": "scoped_survey_anchor|reframe_without_default_problem_anchor",
+      "maturity_status": "mature|provisional",
+      "idea_source": "user_input|survey_gap|prior_candidate|experiment_feedback|problem_reframing|adversarial_generation|cross_domain_transfer",
+      "lineage": "where this idea came from",
+      "independence_rationale": "structural difference from other mature ideas"
+    }}
+  ],
+  "grounded_mature_idea": "3-6 sentences; if mature_idea is empty or provisional, provide a grounded mature idea derived from the survey/papers; otherwise return empty or a minimally clarified restatement",
+  "grounded_refinement_scope": "1-3 sentences; if refinement_scope is empty or provisional, provide a crisp edit boundary that matches the grounded mature idea; otherwise return empty or a minimally clarified restatement",
+  "root_idea": {{
+    "title": "one calibrated root idea title",
+    "abstract": "one concrete root idea abstract; should read like a refined v1.1 version of the current idea when mature_idea is provided",
+    "core_contribution": "main mechanism-level claim; keep it close to the current idea and express the smallest meaningful repair unless evidence forces a local correction. Prefer a repaired rule/objective/update contract over a new gate/router/controller",
+    "method": "specific method sketch with modules/objective/training contract; prefer local edits over new paradigms, state which original limitation is being repaired, avoid introducing a fresh gate/router/controller unless the mature idea already depends on one, and keep training-free ideas training-free unless new training is truly necessary",
+    "risks": "main scientific/engineering risks",
+    "target_defects": ["..."],
+    "rationale": "why this is the best calibrated 1.1 starting point from the extracted survey mechanism bottlenecks",
+    "supporting_papers": ["SURVEY_ANCHOR:...", "PAPER_ANCHOR:..."]
+  }},
+  "divergent_idea_seeds": [
+    {{
+      "title": "short memorable name",
+      "hypothesis": "small neighboring alternative only if useful",
+      "why_it_is_not_incremental": "leave empty or describe only a local contrast",
+      "method_sketch": "near-neighbor mechanism patch, not a new paradigm",
+      "evaluation_plan": "protocol/stress-test to validate the patch",
+      "risk": "dominant scientific or engineering risk",
+      "supporting_papers": ["SURVEY_ANCHOR:...", "PAPER_ANCHOR:..."]
+    }}
+  ],
+  "cross_domain_inspiration": [
+    {{
+      "source_field": "e.g., control theory, neuroscience",
+      "transferable_mechanism": "what we borrow only if it can be expressed as a local patch",
+      "application_hook": "explicit mapping: which survey bottleneck/cluster it improves and how without changing the main method axis"
+    }}
+  ],
+  "tldr": "≤50 word synthesis tying SURVEY mechanism bottlenecks to the calibrated 1.1 root idea"
+}}
+
+== Rules (Strict) ==
+- Always output exactly one `root_idea`; it must be concrete enough to act as the MCTS root node.
+- `root_idea` must directly address at least one named `existing_problems`; it may also respond to `evaluation_gaps`, but evaluation gaps should usually support validation rather than define the main novelty.
+- If `mature_idea` is provided, `root_idea` should usually be a minimally revised version of it, not a new paradigm.
+- If `refinement_scope` is provided, `root_idea` must stay inside that scope. Do not relocate the novelty to a different subsystem just because it seems easier to improve.
+- Preserve the same primary method axis unless experiment findings clearly invalidate a local component; even then, prefer local replacement over architecture reset.
+- `root_idea` should explicitly read as a small-version improvement of the current idea. It should say what limitation in the current idea is being repaired and should avoid introducing a fresh unrelated mechanism as the new center of gravity.
+- If the current idea does not already revolve around gating/routing/control logic, do not introduce a new gate, router, controller, monitor, or threshold policy as the main repair. Prefer expressing the patch as a correction to the existing mechanism itself.
+- If the only available "small fix" would be a gate/router/controller/threshold/budget wrapper, or a patch whose main value is explainability, diagnosability, observability, auditing, monitoring, or validation tooling, set `preserve_current_idea.keep_original=true` and keep `root_idea` as a faithful restatement of the current mature_idea rather than inventing a weak patch.
+- When `preserve_current_idea.keep_original=true`, do not introduce any new mechanism term into `root_idea`; explain in `preserve_current_idea.reason` why the original idea is being kept unchanged.
+- If the current mature idea is training-free, do not add a new training stage, learned controller, auxiliary loss, or fine-tuning loop unless it is clearly indispensable. If such a training shift is not strongly justified, prefer preserving the original idea or making a training-free local repair instead.
+- Every divergent_idea_seed MUST:
+  (a) cite at least one SURVEY_ANCHOR and name which existing_problems it addresses; mention evaluation_gaps only when they affect validation,
+  (b) propose a concrete local mechanism patch, not just instrumentation,
+  (c) keep the main axis consistent with survey framing and close to the current idea,
+  (d) remain a small contrastive variant rather than a replacement proposal.
+- `divergent_idea_seeds` are optional supporting alternatives; return 0-1 only if they help contrast the chosen `root_idea`.
+- `mature_ideas` may contain multiple structurally independent mature seeds. Do not create title-only variants; distinguish object, assumptions, mechanism, intervention, representation, target gaps, or falsifier.
+- Mature ideas may come from `user_input`, `survey_gap`, `prior_candidate`, `experiment_feedback`, `problem_reframing`, `adversarial_generation`, or `cross_domain_transfer`; preserve the exact source and a structured lineage record for each mature idea. Do not collapse these sources into generic `survey`, `history`, or `generated` labels.
+- Keep problem-reframing or adversarial records as formal exploratory/provisional ideas when they challenge the default problem definition; do not discard them solely for lower feasibility.
+- Papers may contribute:
+  - representative baselines and fair comparison protocol details,
+  - feasibility constraints (latency/memory/compute),
+  - evidence that a survey bottleneck or gap persists across recent works.
+  Cited-paper capsules may NOT contribute:
+  - a new main problem statement that is absent from survey,
+  - a new core mechanism term as the central novelty unless it is only a local substitute for a weak component.
+- Evaluation gaps alone should not define the root idea unless they expose a concrete missing mechanism that the root idea patches.
+- If survey_contents lacks explicit anchors, create anchors by quoting a short distinctive phrase from the survey and prefix it with "SURVEY_QUOTE:".
+- Keep the JSON valid and free of commentary.
+"""
+
+# Backward-compatible alias expected by prompt registry/imports.
+ADVANCED_ANALYSIS_PROMPT = ADVANCED_ANALYSIS_PROMPT_SURVEY_LED_WITH_PAPERS
+
+
+def render_advanced_analysis_prompt(prompt: str, profile_id: str | None = None) -> str:
+    """Keep the pre-MCTS survey analysis in the selected scientific vocabulary."""
+
+    if str(profile_id or "").strip().lower() == "computational_algorithmic":
+        return prompt
+    replacements = {
+        "method clusters + unresolved mechanism bottlenecks + evaluation blind spots": "scientific object/process clusters + unresolved mechanism bottlenecks + evidence blind spots",
+        "supervision/training signals": "evidence, observations, or operating conditions",
+        "implementation constraints or operating assumptions": "implementation, intervention, measurement, or operating assumptions",
+        "gate/router/controller/monitor style patches": "generic wrapper or decision-layer patches",
+        "gate/router/controller/monitor": "generic wrapper or decision-layer",
+        "gate/router/controller": "generic decision layer",
+        "gate/threshold/router": "generic decision layer",
+        "gate-like control logic": "generic decision logic",
+        "threshold/budget": "decision-layer/resource",
+        "gating/routing/control logic": "generic decision logic",
+        "gate, router, controller, monitor, or threshold": "generic decision or audit layer",
+        "threshold policy": "decision policy",
+        "trainable controller": "fitted or control layer",
+        "auxiliary loss": "auxiliary fitting criterion",
+        "learned module": "fitted component",
+        "fine-tuning": "additional optimization",
+        "fine tuning": "additional optimization",
+        "representation": "scientific object description",
+        "task-solving mechanism": "scientific mechanism",
+        "update rule, objective, representation, or training contract": "process rule, causal relation, measurement construct, assumption, or evidence contract",
+        "objective, representation, update contract, or training contract": "process rule, causal relation, measurement construct, assumption, or evidence contract",
+        "objective, representation, or training contract": "process rule, causal relation, measurement construct, or evidence contract",
+        "new training stage, trainable controller, auxiliary loss, fine-tuning loop, or learned module": "unrelated optimization stage, control wrapper, or auxiliary computational layer",
+        "training-free or inference-time": "non-learning, observation-only, or intervention-only",
+        "training-free": "non-learning",
+        "optimization or calibration-free": "non-learning",
+        "training-free ideas": "non-learning or intervention-only ideas",
+        "training-free local repairs": "profile-native local repairs",
+        "modules/objective/training contract": "objects/processes/relations/evidence contract",
+        "modules/objective/update contract": "objects/processes/relations/evidence contract",
+        "modules/objective": "objects/processes/relations",
+        "learned controller": "generic control wrapper",
+        "fine-tuning machinery": "unrelated optimization machinery",
+        "representation change": "object or relation change",
+        "update rule": "process or causal rule",
+        "training contract": "evidence contract",
+        "training signals": "evidence or operating signals",
+        "training": "optimization or calibration",
+        "supervision": "evidence or observation",
+        "modules": "scientific objects",
+        "objective": "claim or process target",
+    }
+    for source, target in replacements.items():
+        prompt = prompt.replace(source, target)
+    return prompt

src/agents/idea_agent/agent/prompts/algorithm_alignment.py

@@ -0,0 +1,55 @@
+ALGORITHM_ALIGNMENT_PROMPT = """
+You are a research alignment editor. A single idea (title + abstract) is implemented by several algorithm specs, but some may drift away from the idea. Rewrite the algorithms so every entry clearly supports the given idea, removing anything that cannot be justified.
+
+== Idea Title == 
+{idea_title}
+
+== Idea Abstract == 
+{idea_abstract}
+
+== Idea Method ==
+{idea_method}
+
+== Exact Components ==
+{components}
+
+== Component Explanations ==
+{component_explanations}
+
+== Candidate Algorithms == 
+{algorithms}
+
+== Requirements ==
+- The top-level JSON value MUST be an object, never a raw array.
+- Even if only one algorithm remains, still return `{{"algorithms": [ ... ]}}`.
+- Do NOT return `[{{...}}]` at the top level.
+- Maintain the schema exactly: each algorithm has "name", "input", "output", "pipeline".
+- Edit minimally. Preserve concrete operations and structure when already aligned.
+- Do NOT rewrite detailed steps into higher-level summaries, overviews, or motivation prose.
+- `input`, `output`, and `pipeline` must remain arrays of strings, not arrays of objects.
+- `pipeline[*]` must keep the `Step k:` form.
+- Whenever a pipeline step or input references an existing module, use the exact component names copied from `components`.
+- The final algorithm must read as a standalone specification for THIS idea only. Assume the downstream experiment agent can see only this idea.
+- Remove any mention of other ideas, alternative candidates, sibling modes, source modes, fusion, host idea, parent idea, rejected components, or comparisons against other ideas.
+- You may repair, merge, or drop entries, but only if needed to align them with the idea title, abstract, and method.
+- If you keep multiple algorithms, ensure each pipeline explicitly references the mechanisms and exact components in the method.
+- No commentary outside the JSON.
+
+Return JSON:
+{{
+  "algorithms": [
+    {{
+      "name": "...",
+      "input": [
+        "concrete input description"
+      ],
+      "output": [
+        "concrete output description"
+      ],
+      "pipeline": [
+        "Step 1: concrete execution action using exact component names"
+      ]
+    }}
+  ]
+}}
+"""

src/agents/idea_agent/agent/prompts/algorithm_structuring.py

@@ -0,0 +1,48 @@
+ALGORITHM_STRUCTURING_PROMPT = """
+You are an expert algorithm architect. Your task is to translate an abstract research idea into a rigorous, executable algorithm specification.
+
+== Topic == 
+{topic}
+
+== Idea Title ==
+{idea_title}
+
+== Idea Abstract ==
+{idea_abstract}
+
+== Compact Idea JSON ==
+{idea}
+
+Return ONLY a valid JSON object matching this schema exactly:
+{{
+  "algorithms": [
+    {{
+      "name": "Concise algorithm name (<8 words)",
+      "input": [
+        "concrete input description"
+      ],
+      "output": [
+        "concrete output description"
+      ],
+      "pipeline": [
+        "Step 1: concrete execution action using exact component names"
+      ]
+    }}
+  ]
+}}
+
+== Rules (Strict) ==
+- The top-level JSON value MUST be an object, never a raw array.
+- Even if there is only one algorithm, still return `{{"algorithms": [ ... ]}}`.
+- Do NOT return `[{{...}}]` at the top level.
+- `input`, `output`, and `pipeline` must each be arrays of strings, not arrays of objects.
+- Use ONLY exact component names copied from `components` whenever an input line or pipeline step touches an existing module.
+- Every `pipeline` item must start with `Step k:` and describe one concrete execution step, not an overview, heading, or prose summary.
+- Each pipeline step should explicitly name the exact components it uses and the concrete state, signal, or artifact it produces.
+- Write the algorithm as a standalone specification for THIS idea only. Assume the downstream experiment agent can see only this idea.
+- Do NOT mention other ideas, alternative candidates, sibling modes, source modes, fusion, host idea, parent idea, rejected components, or comparisons against other ideas anywhere in `name`, `input`, `output`, or `pipeline`.
+- NO MAGIC WORDS: do not write vague summaries like 'integrate the system' or 'optimize performance'. Write the actual mechanism.
+- Keep inputs/outputs concrete (e.g., `slot_records` instead of `data`).
+- If multiple distinct sub-algorithms are needed to realize the idea, include each as its own entry in the `algorithms` array.
+- Do not add any markdown formatting (like ```json) or commentary outside the JSON object.
+"""

src/agents/idea_agent/agent/prompts/component_extraction.py

@@ -0,0 +1,62 @@
+COMPONENT_EXTRACTION_PROMPT = """
+You are an expert research scientist. Given a mature research idea and a fixed scientific intervention profile, extract its key domain-native research components.
+
+Each component should be a concise name (2-5 words, snake_case) representing a distinct scientific object, mechanism, intervention, process, relation, measurement, proof object, data step, or evaluation protocol described in the idea.
+
+== Mature Idea ==
+{mature_idea}
+
+== Topic ==
+{topic}
+
+== Fixed scientific intervention profile ==
+{scientific_intervention_profile}
+
+== Previous idea component inventory (reuse these exact names whenever the revised idea still contains the same component role) ==
+{prior_components}
+
+== Latest component decisions from re_analysis_replan ==
+{component_decisions}
+
+Return STRICT JSON (no Markdown wrapping):
+{{
+  "components": ["component_name_1", "component_name_2", ...],
+  "component_explanations": {{
+    "component_name_1": "Short explanation of the role this component plays in the idea.",
+    "component_name_2": "Short explanation of the role this component plays in the idea."
+  }}
+}}
+
+== Rules (Strict) ==
+-  Extract at least 1 and at most 5 components.
+-  Each component must be a distinct, non-overlapping part of the idea's scientific object, intervention, mechanism, or methodology.
+-  Use short, descriptive snake_case names. Examples are profile-native roles such as "controllable_process", "causal_mediator", "measurement_endpoint", or "proof_obligation"; choose concrete names from the idea rather than copying these examples.
+-  Do NOT include generic placeholders such as "unnamed_object" or "generic_process" — be specific to this idea.
+-  Do not invent profile objects merely because the discipline is unresolved; use the selected profile's object, intervention, mechanism, observable, comparator, and boundary roles instead.
+-  If the revised mature idea keeps or strengthens a prior component, reuse the exact prior component name instead of inventing a synonym.
+-  Component explanations may change; name reuse matters more than explanation reuse.
+-  If a component is genuinely replaced with a different mechanism, create a new name only when the functional role has materially changed.
+-  Prefer the smallest stable rename set: reuse old names wherever reasonable, introduce new names only for genuinely new components.
+-  Order objects by their importance to the central claim (most claim-critical first).
+"""
+
+
+def render_component_extraction_prompt(profile_id: str = "") -> str:
+    """Render extraction wording without computational vocabulary for non-CS profiles."""
+
+    prompt = COMPONENT_EXTRACTION_PROMPT
+    if str(profile_id or "").strip().lower() == "computational_algorithmic":
+        return prompt
+    replacements = {
+        "Each component should be a concise name": "Each scientific object should be a concise name",
+        "Previous idea component inventory (reuse these exact names whenever the revised idea still contains the same component role)": "Previous scientific-object inventory (reuse these exact names whenever the revised idea still contains the same role)",
+        '"components": ["component_name_1", "component_name_2", ...],': '"components": ["scientific_object_1", "scientific_object_2", ...],',
+        "Each component must be a distinct, non-overlapping part": "Each scientific object must be a distinct, non-overlapping part",
+        "If a component is genuinely replaced with a different mechanism, create a new name": "If a scientific object is genuinely replaced with a different mechanism, create a new name",
+        "If the revised mature idea keeps or strengthens a prior component, reuse the exact prior component name": "If the revised mature idea keeps or strengthens a prior scientific object, reuse the exact prior name",
+        "Component explanations may change; name reuse matters more than explanation reuse.": "Scientific-object explanations may change; name reuse matters more than explanation reuse.",
+        "Prefer the smallest stable rename set": "Prefer the smallest stable scientific-object rename set",
+    }
+    for source, target in replacements.items():
+        prompt = prompt.replace(source, target)
+    return prompt

src/agents/idea_agent/agent/prompts/component_novelty_evaluation.py

@@ -0,0 +1,54 @@
+COMPONENT_NOVELTY_EVALUATION_PROMPT = """
+You are a strictly objective novelty evaluator for a research idea during an MCTS search process.
+
+== Topic ==
+{topic}
+
+== Scientific novelty profile ==
+Profile: {profile_id}
+Novelty axes: {novelty_axes}
+
+== Candidate idea state (JSON) ==
+{idea_state}
+
+== Component explanations used as semantic queries ==
+{components_with_explanations}
+
+== Nearest paper-graph evidence nodes ==
+These are the most frequently retrieved core nodes after running top-{retrieval_top_k} component-summary semantic search for EACH component explanation.
+Treat them as the closest known prior-art neighborhood in the existing paper graph.
+{retrieved_nodes}
+
+Novelty scoring policy:
+- Score scientific novelty, not component-name novelty. The nearest-neighbor search is prior-art context, not proof of a research gap.
+- Evaluate the profile-native novelty axes above. Consider mechanism, relation, boundary, causal/measurement design, proposition/proof structure, or algorithmic mechanism as appropriate to the profile.
+- Ignore impact, feasibility, and writing quality when assigning novelty.
+- Use the retrieved nodes as the main baseline, but do not stop at nearest-neighbor text similarity.
+- High similarity usually lowers novelty, but it does NOT automatically force a low score if the mechanism shift is concrete and scientifically substantive.
+- Low similarity does NOT automatically imply high novelty if the idea is vague, generic, or just repackages common patterns not captured in the retrieved set. Penalize vague claims.
+- COMPONENT AGGREGATION RULE: If an idea combines standard/highly-similar components with at least ONE highly novel, scientifically substantive object, relation, or boundary change, anchor the overall `rubric_score` on that change (do not simply average component names).
+- POLARITY FOR SIMILARITY: 5 = Nearly identical/heavy overlap with retrieved nodes. 0 = Completely orthogonal/unrelated to retrieved nodes.
+
+Rubric anchors (for the final `rubric_score`):
+- 0 = Trivial restatement or cosmetic rename of the retrieved neighborhood.
+- 1 = Very small edit that preserves the same underlying mechanism.
+- 2 = Modest variation with limited new mechanism content.
+- 3 = Meaningful recombination or scoped mechanism change, but still close to nearby prior art.
+- 4 = Clear mechanism-level departure relative to the retrieved neighborhood.
+- 5 = Strongly differentiated mechanism with concrete, defensible novelty.
+
+First, conduct your analysis in the `evaluation_scratchpad`. Then, assign the numeric scores.
+Return STRICT JSON ONLY (no markdown blocks like ```json, no prose outside the JSON object):
+{{
+  "retrieval_similarity": <int 0-5>,
+  "novelty_axes": {{
+      "mechanism_or_process": <int 0-5>,
+      "relation_or_claim": <int 0-5>,
+      "boundary_or_regime": <int 0-5>,
+      "evidence_or_measurement_design": <int 0-5>
+  }},
+  "perceived_novelty": <int 0-5>,
+  "rubric_score": <int 0-5>,
+  "rationale": "One concise sentence summarizing why this specific rubric_score was chosen based on the mechanism delta."
+}}
+"""

src/agents/idea_agent/agent/prompts/experiment_findings_extraction.py

@@ -0,0 +1,39 @@
+EXPERIMENT_FINDINGS_EXTRACTION_PROMPT = """
+You are a research-analysis agent.
+
+== Task == 
+Read the raw ablation / experiment JSON below and extract structured findings for LigAgent.
+
+== Important assumptions == 
+- Treat every key under `components` as a REAL component name.
+- Do not invent new component names.
+- Base all findings strictly on the provided raw JSON.
+- The output must stay grounded in the raw JSON. Do not add action suggestions, theme taxonomies, or other speculative labels.
+- Every component under `components` MUST appear exactly once in `component_findings`.
+- The `component` field must exactly match the original key from `components`.
+- If `summary.feasible`, `summary.confidence`, or `summary.key_findings` exist in the raw JSON, preserve them faithfully unless the raw JSON is clearly inconsistent.
+
+== Raw ablation JSON ==
+{raw_ablation}
+
+Return STRICT JSON with this schema:
+{{
+  "summary": {{
+    "hypothesis_status": "supported|challenged|falsified|mixed|inconclusive",
+    "feasible": true,
+    "overall_confidence": 0.0,
+    "tldr": "short summary of the overall ablation outcome",
+    "key_findings": ["..."]
+  }},
+  "component_findings": [
+    {{
+      "component": "string",
+      "result": "positive|negative|inconclusive",
+      "metric": "string",
+      "value": "string",
+      "confidence": 0.0,
+      "analysis": "short grounded explanation of what this result means"
+    }}
+  ]
+}}
+"""