@r1z4x/tezgah 1.0.0

package/skills/ai-research/21-research-ideation/creative-thinking-for-research/SKILL.md

@@ -0,0 +1,366 @@
+---
+name: creative-thinking-for-research
+description: Applies cognitive science frameworks for creative thinking to CS and AI research ideation. Use when seeking genuinely novel research directions by leveraging combinatorial creativity, analogical reasoning, constraint manipulation, and other empirically grounded creative strategies.
+version: 1.0.0
+author: Orchestra Research
+license: MIT
+tags: [Creative Thinking, Research Ideation, Analogical Reasoning, Problem Reformulation, Cognitive Science]
+dependencies: []
+---
+
+# Creative Thinking for Research
+
+Eight empirically grounded frameworks from cognitive science, applied to computer science and AI research. Unlike ad-hoc brainstorming, each framework here is backed by decades of creativity research — from Koestler's bisociation to Kauffman's adjacent possible. They target distinct cognitive operations: combining, reformulating, analogizing, constraining, inverting, abstracting, exploring boundaries, and holding contradictions.
+
+## When to Use This Skill
+
+- Generating genuinely novel ideas, not incremental extensions of prior work
+- Feeling trapped in a local optimum of thinking within a single subfield
+- Wanting to systematically apply creativity heuristics rather than waiting for inspiration
+- Preparing for a research retreat or PhD-level ideation session
+- Bridging between fields and seeking structural (not superficial) connections
+
+**Do NOT use this skill when**:
+- You need structured project-level brainstorming workflows (use `brainstorming-research-ideas`)
+- You have a well-defined problem and need execution help (use domain-specific skills)
+- You need a literature survey (use `scientific-skills:literature-review`)
+
+**Relationship to Brainstorm skill**: The brainstorm skill provides operational workflows (diverge → converge → refine) and practical filters. This skill provides the deeper cognitive engines that power creative leaps. Use them together: creative-thinking to generate raw insight, brainstorm to structure and evaluate it.
+
+---
+
+## Framework 1: Combinatorial Creativity (Bisociation)
+
+Novel ideas arise from combining existing concepts in unexpected ways. Arthur Koestler called this **bisociation** — connecting two previously unrelated frames of reference, as distinct from routine association within a single frame.
+
+**Why it works**: Meta-research consistently shows that breadth of knowledge is a precursor to creative output. People who read across disciplines produce more novel work. The combination itself is the creative act.
+
+**In CS Research**:
+- Biological evolution → optimization (genetic algorithms)
+- Game theory → networking (mechanism design for routing)
+- Statistical physics → machine learning (Boltzmann machines, energy-based models)
+- Linguistics → programming (type theory, formal grammars)
+
+**Systematic Bisociation Workflow**:
+
+1. **Select two domains** you have at least passing familiarity with
+2. **List core primitives** in each domain (5-10 fundamental concepts per domain)
+3. **Create a cross-product matrix**: row = concepts from Domain A, column = concepts from Domain B
+4. **For each cell**, ask: "What would it mean to apply A's concept to B's problem?"
+5. **Filter**: Which combinations produce a non-trivial, testable research question?
+6. **Validate structural depth**: Is the connection mechanistic or merely metaphorical?
+
+**Cross-Product Example**:
+
+| | Caching | Load Balancing | Fault Tolerance |
+|---|---------|---------------|-----------------|
+| **Natural Selection** | Evict least-fit entries | Adaptive allocation via fitness | Population-level redundancy |
+| **Immune Memory** | Learned threat signatures | Distributed detection | Self/non-self discrimination |
+| **Symbiosis** | Cooperative prefetching | Mutualistic resource sharing | Co-dependent resilience |
+
+**Quality Test**: A strong bisociation is not a surface metaphor ("the network is like a brain") but a structural mapping where the mechanism transfers ("attention mechanisms implement a form of selective gating analogous to cognitive attention filtering").
+
+**Self-Check**:
+- [ ] Is the connection structural (mechanisms map) or merely verbal (labels map)?
+- [ ] Does the combination generate testable predictions?
+- [ ] Would an expert in both fields find the connection non-obvious but sound?
+
+---
+
+## Framework 2: Problem Reformulation (Representational Change)
+
+Gestalt psychologists identified that breakthroughs often come not from solving the problem as stated, but from **re-representing the problem itself**. Kaplan and Simon's work on insight shows that changing the problem space — the constraints, the abstraction level, the formalism — is often where creativity lives.
+
+**The Key Shift**: From "How do I solve this problem?" to "Am I even thinking about this problem correctly?"
+
+**Reformulation Strategies**:
+
+| Strategy | Example |
+|----------|---------|
+| **Change the objective** | "Make the algorithm faster" → "Eliminate the need for this computation" |
+| **Change the formalism** | Graph problem → linear algebra problem (spectral methods) |
+| **Change the granularity** | Per-token prediction → per-span prediction |
+| **Change the agent** | "How should the model learn?" → "How should the data teach?" (curriculum learning) |
+| **Change the timescale** | Real-time optimization → amortized inference |
+| **Invert the direction** | Forward simulation → inverse problem (learning from observations) |
+
+**Workflow**:
+
+1. State your current problem in one sentence
+2. Identify the **hidden assumptions** in that statement:
+   - What formalism are you using? (Could you use a different one?)
+   - What is the objective? (Is it the right objective?)
+   - What level of granularity? (Could you go coarser or finer?)
+   - Who is the agent? (Could you shift perspective?)
+3. For each assumption, **generate the alternative**: "What if [opposite assumption]?"
+4. For each alternative, ask: "Does this reformulation make the problem easier, harder, or different in a useful way?"
+5. A reformulation that makes a hard problem easy is often a publishable insight on its own
+
+**Classic CS Examples**:
+- **PageRank**: Reformulated "find important web pages" from content analysis to graph eigenvalue problem
+- **Dropout**: Reformulated "prevent overfitting" from regularization to approximate ensemble
+- **Attention**: Reformulated "handle long sequences" from remembering everything to selectively querying
+
+---
+
+## Framework 3: Analogical Reasoning (Structure-Mapping)
+
+Dedre Gentner's **structure-mapping theory** and Kevin Dunbar's studies of real scientists show that analogy is the core engine of scientific creativity. The critical finding: surface-level analogies are common but weak; **structural or relational analogies** — where the deep causal/relational structure maps across domains — produce the most powerful insights.
+
+**Dunbar's Finding**: In the most successful labs, analogies from distant domains drove the most important discoveries. Nearby analogies refined ideas; distant analogies generated them.
+
+**Levels of Analogical Depth**:
+
+| Level | Description | Value | Example |
+|-------|-------------|-------|---------|
+| **Surface** | Things look similar | Low | "A neural network is like a brain" |
+| **Relational** | Relationships between entities match | Medium | "Attention allocation in models parallels resource allocation in economics" |
+| **Structural** | Deep causal mechanisms map | High | "Diffusion models reverse a thermodynamic process; the math of non-equilibrium stat-mech directly applies" |
+
+**Structure-Mapping Workflow**:
+
+1. **Describe your problem** using only relational/causal language (strip domain-specific nouns)
+   - Bad: "We need to improve transformer attention efficiency"
+   - Good: "We have a system that must selectively aggregate information from a large set, where relevance is context-dependent and the cost scales quadratically with set size"
+2. **Search for structural matches**: What other systems selectively aggregate from large sets?
+   - Database query optimization, visual attention in neuroscience, information retrieval, resource allocation
+3. **Pick the most distant match** with genuine structural fidelity
+4. **Map the solution mechanism**: How does the source domain solve this?
+5. **Transfer and adapt**: What changes when you bring that mechanism into your domain?
+6. **Generate predictions**: The analogy should tell you something you didn't already know
+
+**Validation Checklist**:
+- [ ] Does the mapping preserve causal/relational structure (not just labels)?
+- [ ] Can I identify at least one prediction the analogy makes in my domain?
+- [ ] Would an expert in the source domain confirm the mechanism is correctly understood?
+- [ ] Is the analogy non-obvious to my target audience?
+
+---
+
+## Framework 4: Constraint Manipulation (Boden's Framework)
+
+Margaret Boden's framework distinguishes three forms of creativity based on how they interact with constraints:
+
+| Type | Operation | CS Example |
+|------|-----------|------------|
+| **Exploratory** | Search within the existing conceptual space | Hyperparameter tuning, architecture search within a fixed paradigm |
+| **Combinational** | Combine elements from different spaces | Multi-task learning, neuro-symbolic methods |
+| **Transformational** | Change the rules of the space itself | Dropping the assumption that training requires labels (self-supervised learning) |
+
+**Transformational creativity is the rarest and highest-impact.** It happens when you change what is even considered a valid solution.
+
+**Constraint Analysis Workflow**:
+
+1. **List the constraints** of your current approach (5-10 constraints):
+   - Computational: "Must fit in GPU memory"
+   - Methodological: "Requires labeled data"
+   - Architectural: "Uses fixed-length context"
+   - Evaluative: "Measured by accuracy on benchmark X"
+2. **Classify each constraint**:
+   - **Hard**: Physically or logically necessary (cannot violate)
+   - **Soft**: Convention or historical accident (can question)
+   - **Hidden**: Not stated but implicitly assumed (most fertile for innovation)
+3. **For each soft/hidden constraint**, ask:
+   - What if we relaxed it? (streaming algorithms from relaxing "fits in memory")
+   - What if we tightened it? (efficiency research from tightening compute budgets)
+   - What if we replaced it with a different constraint entirely?
+4. **The most productive move** is often exposing and dropping a hidden constraint
+
+**Classic Examples of Constraint Transformation**:
+- "Data must fit in memory" → dropped → streaming algorithms, external memory
+- "Training requires human labels" → dropped → self-supervised learning
+- "Models must be deterministic" → dropped → variational methods, diffusion
+- "Inference must happen in one pass" → dropped → iterative refinement, chain-of-thought
+
+---
+
+## Framework 5: Negation and Inversion
+
+Take a core assumption in your field and negate it. This is formalized in De Bono's lateral thinking and the **TRIZ methodology** from engineering.
+
+**The Pattern**: "What if [widely held assumption] is wrong, unnecessary, or invertible?"
+
+**Systematic Negation Workflow**:
+
+1. **List 5-10 core assumptions** in your subfield (the things "everyone knows")
+2. **Negate each one** and ask: What system would you build?
+3. **Evaluate each negation**:
+   - Incoherent → discard
+   - Already explored → check if conditions have changed (see brainstorm skill, Framework 5)
+   - Unexplored and coherent → potential research direction
+
+**Negation Hall of Fame in CS**:
+
+| Assumption | Negation | Result |
+|-----------|----------|--------|
+| "We need strong consistency" | What if we don't? | Eventual consistency, CRDTs |
+| "We need exact answers" | What if approximate is fine? | Sketches, LSH, approximate nearest neighbors |
+| "Labels are necessary" | What if we learn without them? | Self-supervised learning, contrastive methods |
+| "More parameters = more compute" | What if we don't use all parameters? | Mixture of Experts, sparse models |
+| "Training and inference are separate" | What if the model keeps learning? | Online learning, test-time training |
+| "Errors must be prevented" | What if we embrace and correct them? | Speculative decoding, self-correction |
+
+**TRIZ-Inspired Principles for CS**:
+
+| TRIZ Principle | CS Application |
+|---------------|----------------|
+| **Inversion** | Reverse the process (generative vs. discriminative) |
+| **Segmentation** | Break monolithic into modular (microservices, mixture of experts) |
+| **Merging** | Combine separate steps (end-to-end learning) |
+| **Universality** | One component serves multiple functions (multi-task models) |
+| **Nesting** | Place one system inside another (meta-learning) |
+| **Dynamization** | Make static things adaptive (dynamic architectures, adaptive computation) |
+
+---
+
+## Framework 6: Abstraction and Generalization Laddering
+
+Moving up and down the abstraction ladder is a fundamental creative act. Polya's heuristics formalize this: *"Can you solve a more general problem? A more specific one? An analogous one?"*
+
+**Three Moves**:
+
+| Move | Question | Outcome |
+|------|----------|---------|
+| **Generalize** | "Is my solution a special case of something broader?" | Framework papers, unifying theories |
+| **Specialize** | "What happens when I add extreme constraints?" | Niche applications, surprising edge cases |
+| **Analogize** | "Where else does this abstract pattern appear?" | Cross-domain transfer (see Framework 3) |
+
+**Generalization Workflow**:
+1. State your specific result
+2. Replace each specific element with a variable: "ResNet works for ImageNet" → "Architecture X works for distribution Y"
+3. Ask: Under what conditions does this hold? What is the general principle?
+4. If the general principle is novel → that is the contribution
+
+**Specialization Workflow**:
+1. Take a general method
+2. Add extreme constraints: tiny data, huge dimensionality, adversarial inputs, real-time requirements
+3. Ask: Does the method still work? If not, why not?
+4. The failure case often reveals the method's true assumptions
+
+**When to Generalize vs. Specialize**:
+- Generalize when you have results but no explanation
+- Specialize when you have theory but no grounding
+- Analogize when you are stuck in either direction
+
+---
+
+## Framework 7: The Adjacent Possible (Kauffman / Johnson)
+
+Stuart Kauffman's concept, popularized by Steven Johnson: innovation happens at the boundary of what is currently reachable — the **adjacent possible**. New ideas become thinkable once their prerequisites exist. This explains why simultaneous independent discovery is so common — multiple people reach the same boundary.
+
+**Practical Implication**: Map what has recently become possible and explore the space those enablers open.
+
+**Adjacent Possible Mapping Workflow**:
+
+1. **List recent enablers** (last 1-3 years):
+   - New hardware capabilities (longer context, faster inference, new accelerators)
+   - New datasets or benchmarks
+   - New open-source tools or frameworks
+   - New theoretical results
+   - New regulatory or social conditions
+2. **For each enabler, ask**: "What was previously impossible or impractical that this now permits?"
+3. **Combine enablers**: The most powerful adjacent possibles arise from the intersection of multiple new enablers
+4. **Check for competition**: If many people can see the same adjacent possible, speed or a unique angle matters
+
+**Current Adjacent Possibles (2025-2026)**:
+
+| Enabler | Newly Possible |
+|---------|---------------|
+| 1M+ token context windows | Full-codebase reasoning, book-length analysis |
+| Inference cost drops (100x in 2 years) | Real-time agentic loops, always-on AI assistants |
+| Open-weight models at GPT-4 level | Reproducible research on frontier capabilities |
+| Multimodal models (vision + language + audio) | Unified perception-reasoning systems |
+| Synthetic data at scale | Training data for domains with no natural data |
+| Tool-using models | Research automation, self-improving systems |
+
+**Timing Signal**: If your idea requires technology that doesn't exist yet, it's beyond the adjacent possible — park it. If your idea could have been done 5 years ago, someone probably did — check the literature. The sweet spot is ideas that became feasible in the last 6-18 months.
+
+---
+
+## Framework 8: Janusian and Dialectical Thinking
+
+Albert Rothenberg's studies of eminent creators found that **holding two contradictory ideas simultaneously** is a hallmark of creative thinking. Named after Janus, the two-faced Roman god, this mode of thinking doesn't resolve contradictions by choosing a side — it generates new frameworks that transcend the opposition.
+
+**In CS**: The most influential results often emerge from tensions previously thought irreconcilable.
+
+| Contradiction | Resolution | Impact |
+|--------------|------------|--------|
+| Consistency AND Availability (distributed systems) | CAP theorem: formalized the trade-off, then Raft/CRDTs found practical middle grounds | Foundation of distributed systems theory |
+| Security AND Usability | Zero-knowledge proofs: prove knowledge without revealing it | Enabled private computation |
+| Expressiveness AND Tractability | Probabilistic programming: express complex models, automate inference | New programming paradigm |
+| Memorization AND Generalization | Grokking: models memorize first, then generalize with more training | New understanding of learning dynamics |
+| Compression AND Quality | Neural codecs that compress beyond information-theoretic limits via learned priors | Redefined compression research |
+
+**Dialectical Thinking Workflow**:
+
+1. **Identify a binary** in your field: A vs. B (two approaches, goals, or paradigms treated as opposites)
+2. **Resist choosing a side**. Instead ask:
+   - "What would a system look like that achieves both A and B?"
+   - "Under what conditions is the A-B trade-off not fundamental?"
+   - "Is the opposition an artifact of how we formalized the problem?"
+3. **Seek synthesis**: The resolution often requires a new abstraction that reframes the relationship
+4. **Test the synthesis**: Can you demonstrate empirically that both goals are achievable?
+
+**Self-Check**:
+- [ ] Am I holding the contradiction genuinely (not prematurely resolving it)?
+- [ ] Is the synthesis a new idea, not just a compromise (splitting the difference)?
+- [ ] Does the resolution change how people think about the problem, not just the solution?
+
+---
+
+## Combining Frameworks: A Creative Thinking Protocol
+
+These frameworks are most powerful in combination. Here is a systematic protocol for a deep creative thinking session:
+
+### Phase 1: Map the Space (15 min)
+1. **Constraint Manipulation** (F4): List all constraints of the current paradigm. Mark which are hard, soft, hidden.
+2. **Adjacent Possible** (F7): List recent enablers that change the feasibility landscape.
+
+### Phase 2: Generate Disruptions (30 min)
+3. **Negation** (F5): Negate 3 soft/hidden constraints. What systems emerge?
+4. **Bisociation** (F1): Pick a distant field and create a cross-product matrix with your domain.
+5. **Problem Reformulation** (F2): Restate your problem 3 different ways (change objective, formalism, agent).
+
+### Phase 3: Deepen Promising Leads (30 min)
+6. **Analogical Reasoning** (F3): For each promising idea, find a structural analogy and extract predictions.
+7. **Abstraction Laddering** (F6): Move each idea up (generalize) and down (specialize).
+8. **Janusian Thinking** (F8): Identify any tensions. Can you synthesize rather than choose?
+
+### Phase 4: Evaluate (15 min)
+Apply the two-sentence test (from the brainstorm skill):
+> "**[Domain] currently struggles with [problem] because [reason].** We [approach] by [mechanism], which works because [insight]."
+
+Any idea that survives all four phases and passes the two-sentence test is worth pursuing.
+
+---
+
+## Common Creative Blocks and Unblocking Strategies
+
+| Block | Symptom | Framework to Apply |
+|-------|---------|-------------------|
+| **Fixation** | Cannot stop thinking about the problem one way | Problem Reformulation (F2) — force a different representation |
+| **Tunnel vision** | All ideas come from the same subfield | Bisociation (F1) or Analogical Reasoning (F3) — import from elsewhere |
+| **Self-censoring** | Dismissing ideas as "too weird" before exploring | Negation (F5) — weird is the point; evaluate after generating |
+| **Incrementalism** | Every idea is "+2% on benchmark X" | Constraint Manipulation (F4) — change the rules, not the parameters |
+| **Analysis paralysis** | Too many options, cannot commit | Adjacent Possible (F7) — what is feasible right now? |
+| **False dichotomy** | Stuck choosing between two approaches | Janusian Thinking (F8) — seek synthesis, not selection |
+
+---
+
+## Usage Instructions for Agents
+
+When a researcher asks for help with creative thinking or novel ideation:
+
+1. **Assess the block**: What kind of thinking are they stuck in? (See Common Creative Blocks table)
+2. **Select 2-3 frameworks** based on the block type
+3. **Walk through each framework interactively**, asking the researcher to supply domain-specific content
+4. **Push for structural depth**: If an analogy or combination is surface-level, probe deeper
+5. **Maintain a running list** of all generated ideas, even unusual ones
+6. **Apply the two-sentence test** to candidates that survive exploration
+7. **Hand off to the brainstorm skill** for systematic evaluation (diverge → converge → refine)
+
+**Key Principles**:
+- Generative mode first, evaluative mode second — do not filter prematurely
+- Distant analogies are more valuable than nearby ones, but require more validation
+- The researcher's domain expertise is essential — the agent provides the cognitive scaffolding, not the domain knowledge
+- Encourage the researcher to sit with contradictions rather than resolve them quickly

package/skills/ai-research/22-agent-native-research-artifact/compiler/SKILL.md

@@ -0,0 +1,245 @@
+---
+name: ara-compiler
+description: Compiles any research input — PDF papers, GitHub repositories, experiment logs, code directories, or raw notes — into a complete Agent-Native Research Artifact (ARA) with cognitive layer (claims, concepts, heuristics), physical layer (configs, code stubs), exploration graph, and grounded evidence. Use when ingesting a paper or codebase into a structured, machine-executable knowledge package, building an ARA from scratch, or converting research outputs into a falsifiable, agent-traversable form.
+version: 1.0.0
+author: Orchestra Research
+license: MIT
+tags: [ARA, Research Artifacts, Knowledge Extraction, Paper Ingestion, Exploration Graph, Provenance, Research Tooling, Epistemic Compilation]
+dependencies: []
+---
+
+# Universal ARA Compiler
+
+You are the ARA Universal Compiler. Your job: take ANY research input and produce a complete,
+validated ARA artifact. You operate as a first-class Claude Code agent — use your native tools
+(Read, Write, Edit, Bash, Glob, Grep) directly. No API wrapper needed.
+
+## Input Philosophy
+
+The compiler is **open-ended**. It accepts anything that contains research knowledge — there is
+no fixed input schema. Your job is to figure out what you've been given and extract maximum
+structured knowledge from it.
+
+Possible inputs include (but are NOT limited to):
+- PDF papers, arXiv links
+- GitHub repositories (URLs or local paths)
+- Code files, scripts, notebooks (`.py`, `.ipynb`, `.rs`, `.cpp`, etc.)
+- Experiment logs, training outputs, evaluation results
+- Configuration files, hyperparameter sweeps
+- Raw research notes, brainstorm transcripts, meeting notes
+- Data directories with results, checkpoints, figures
+- Slack/email threads describing research decisions
+- Combinations of the above
+- A verbal description or conversation with the user about their research
+- Nothing at all — the user may want to build an ARA interactively through dialogue
+
+When arguments are provided (`$ARGUMENTS`), interpret them flexibly:
+- File/directory paths → read them
+- URLs → fetch or clone them
+- `--output <dir>` → where to write the ARA (default: `./ara-output/`)
+- `--rubric <path>` → PaperBench rubric for coverage mapping
+- Anything else → treat as context or ask the user for clarification
+
+### Input Reading Strategy
+
+Adapt to whatever you receive:
+1. **Identify what you have.** Glob, read, and explore the provided paths. Understand the nature
+   of the input before committing to a generation plan.
+2. **Maximize coverage.** Cross-reference all available sources. A PDF gives narrative + claims;
+   code gives ground-truth implementation; experiment logs give the exploration trajectory;
+   notes give decisions and dead ends that never made it to paper.
+3. **Ask when stuck.** If the input is ambiguous or incomplete, ask the user to fill gaps rather
+   than hallucinating. The user is a collaborator, not a passive consumer.
+4. **Handle partial inputs gracefully.** Not every ARA field will be fillable from every input.
+   Populate what you can with high confidence, mark gaps explicitly with "Not available from
+   provided input", and tell the user what's missing so they can supplement later.
+
+## Workflow
+
+```text
+1. READ all inputs
+2. REASON through the 4-stage epistemic protocol (see below)
+3. GENERATE all ARA files using Write tool
+4. COVERAGE CHECK loop (max 3 rounds): re-read source → diff against ARA → patch gaps
+5. VALIDATE by running Seal Level 1
+6. FIX any failures, re-validate
+7. REPORT summary to user
+```
+
+### Step 1: Read Inputs
+
+Read ALL provided inputs thoroughly before generating anything. For PDFs, read every page,
+**including appendices** — appendices often carry reproduction-critical content and should
+be treated with the same priority as main-text pages.
+
+For repos, prioritize: README → core algorithm files → configs → environment files.
+
+### Step 2: 4-Stage Epistemic Chain-of-Thought
+
+Before writing any files, reason through these 4 stages. Think carefully about each stage.
+
+**Stage 1 — Semantic Deconstruction**
+Strip narrative framing. Extract the raw knowledge atoms:
+- Mathematical formulations and equations
+- Architectural specifications and component descriptions
+- Experimental configurations (hyperparameters, hardware, datasets, seeds)
+- ALL numerical results and benchmarks (exact values, never rounded)
+- Citation dependencies and their roles (imports, extends, bounds, refutes)
+- Negative results, ablation findings, rejected alternatives
+- Implementation tricks, convergence hacks, sensitivity observations
+
+Before moving on, perform an **evidence capture pass**:
+- For every source table or figure you plan to cite, first capture the original source identifier and caption exactly (`Table 2`, `Figure 4`, etc.)
+- Transcribe the raw table/figure content before making any claim-specific summary
+- If you create a filtered view for one claim, store it as a **derived subset**, not as the original table itself
+- Never label a subset or merged summary as `Table N` unless it reproduces the original source table faithfully
+- If PDF extraction is ambiguous, re-read the page with layout preserved or inspect the page manually before writing evidence files
+
+**Stage 2 — Cognitive Mapping**
+Map extracted atoms to `/logic/`:
+- **problem.md**: observations (with numbers) → gaps → key insight → assumptions
+- **claims.md**: falsifiable claims with proof pointers to experiment IDs (E01, E02...), plus a separation between direct evidence basis and higher-level interpretation
+- **concepts.md**: ≥5 formal definitions with notation and boundary conditions
+- **experiments.md**: ≥3 declarative verification plans (NO exact numbers — directional only)
+- **solution/**: architecture (component graph), algorithm (math + pseudocode), constraints, heuristics
+- **related_work.md**: typed dependency graph (imports/extends/bounds/baseline/refutes)
+
+Appendix content (worked examples, prompt templates, enumerated taxonomies, annotation
+schemas, extended analyses, prescriptive content) should be routed into the ARA layers
+where it fits best, preserving the granularity the source uses. Never silently drop an
+appendix section.
+
+When writing claims:
+- Phrase the main `Statement` at the strongest level directly supported by the cited evidence
+- Put raw support in `Evidence basis`
+- Put any broader synthesis in `Interpretation`
+- If the evidence only shows validation metrics, do not upgrade the claim to training dynamics or optimization quality unless training-side evidence is also captured
+
+`related_work.md` should reflect the paper's full citation footprint, not only the
+closest predecessors. Works with a specific technical delta get full `RW` blocks; remaining
+citations from the paper's References list should still be captured (more briefly) so the
+intellectual neighborhood is preserved.
+
+**Stage 3 — Physical Stubbing**
+Generate `/src/`:
+- **configs/**: exact hyperparameter values with rationale and sensitivity
+- **execution/**: ≥1 Python code stub implementing the NOVEL contribution (typed signatures, no boilerplate)
+- **environment.md**: Python version, framework, hardware, dependencies, seeds
+- If repo available: use actual code to improve stub precision
+- If rubric provided: produce `rubric/requirements.md` mapping every leaf node
+
+**Stage 4 — Exploration Graph Extraction**
+Reconstruct the research DAG for `/trace/exploration_tree.yaml`:
+- Root nodes = central research questions
+- Experiments and decisions nest as children
+- Dead ends from ablations/rejected alternatives = typed leaf nodes
+- ≥8 nodes, must include dead_end and decision types
+- Use `also_depends_on` for DAG convergence points
+- Every node must declare whether it is `explicit` from source material or `inferred` from reconstruction
+- Explicit nodes should carry source references (table/figure/section labels)
+- Inferred nodes are allowed only when they help reconstruct the paper's logic without pretending to be literal session logs
+
+### Step 3: Generate Files
+
+Write ALL mandatory files. See [references/ara-schema.md](references/ara-schema.md) for the complete
+directory structure and field-level requirements for every file.
+
+**Mandatory files** (all must exist and be non-trivial):
+- `PAPER.md` — YAML frontmatter (title, authors, year, venue, doi, ara_version, domain, keywords, claims_summary, abstract) + Layer Index
+- `logic/problem.md` — Observations (O1, O2...), Gaps (G1, G2...), Key Insight, Assumptions
+- `logic/claims.md` — Claims (C01, C02...) each with Statement, Status, Falsification criteria, Proof, Evidence basis, Interpretation, Dependencies, Tags
+- `logic/concepts.md` — ≥5 concepts each with Notation, Definition, Boundary conditions, Related concepts
+- `logic/experiments.md` — ≥3 experiments (E01, E02...) each with Verifies, Setup, Procedure, Metrics, Expected outcome (directional only!), Baselines, Dependencies
+- `logic/solution/architecture.md` — Component graph with inputs/outputs
+- `logic/solution/algorithm.md` — Math formulation + pseudocode + complexity
+- `logic/solution/constraints.md` — Boundary conditions and limitations
+- `logic/solution/heuristics.md` — Heuristics (H01, H02...) each with Rationale, Sensitivity, Bounds, Code ref, Source
+- `logic/related_work.md` — Related work (RW01, RW02...) each with DOI, Type, Delta, Claims affected
+- `src/configs/training.md` — Hyperparameters with Value, Rationale, Search range, Sensitivity, Source
+- `src/configs/model.md` — Model/architecture configs
+- `src/execution/{module}.py` — ≥1 code stub with typed signatures
+- `src/environment.md` — Python version, framework, hardware, dependencies, seeds
+- `trace/exploration_tree.yaml` — Research DAG (≥8 nodes, nested YAML)
+- `evidence/README.md` — Index table mapping every evidence file to claims
+- `evidence/tables/*.md` — ALL result tables (exact cell values, never rounded)
+- `evidence/figures/*.md` — ALL quantitative figures (extracted data points)
+
+Evidence-generation rules:
+- Preserve **raw source tables** separately from any **derived subset** views
+- A file named after a source object (for example `table3_...`) must match that source object's caption and contents
+- If only a subset is included, the filename must say `derived_`, `subset_`, or equivalent, and the file must state what it was derived from
+- Do not merge rows from different source tables into one evidence file unless the file is explicitly labeled as a derived comparison
+
+### Step 4: Coverage Check Loop (max 3 rounds)
+
+Before running Seal validation, verify that the ARA faithfully covers the source material.
+Repeat up to **3 rounds**; stop early if a round produces no patches.
+
+**Each round:** re-read the source, identify anything not yet captured or only shallowly
+captured in the ARA, patch those gaps, then note how many fixes were made. If zero, exit
+early. Pay particular attention to appendix content and to citations from the paper's
+References list, which are easy to miss on the first pass.
+
+The coverage loop does not replace validation — it ensures the ARA is semantically complete
+before structural checks run.
+
+### Step 5: Validate
+
+Run ARA Seal Level 1 validation. Perform these checks:
+- All mandatory dirs exist: `logic/`, `logic/solution/`, `src/`, `src/configs/`, `trace/`, `evidence/`
+- All mandatory files exist and are non-empty
+- PAPER.md has YAML frontmatter with title, authors, year
+- PAPER.md has Layer Index section
+- claims.md has C01+ blocks with Statement, Status, Falsification criteria, Proof fields
+- experiments.md has E01+ blocks with Verifies, Setup, Procedure, Expected outcome fields
+- heuristics.md has H01+ blocks with Rationale, Sensitivity, Bounds fields
+- concepts.md has ≥5 concept sections
+- experiments.md has ≥3 experiment plans
+- exploration_tree.yaml parses as valid YAML with ≥8 nodes, has dead_end and decision types
+- Claim Proof references (E01, E02...) resolve to experiments.md
+- Experiment Verifies references (C01, C02...) resolve to claims.md
+- Heuristic Code ref paths resolve to actual files in src/execution/
+- Evidence files contain Markdown tables with **Source** fields
+- Evidence file names, source labels, and captions agree on the original table/figure identifier
+- Any file named like a raw source table is a faithful transcription rather than a filtered subset
+- Claims only cite experiments whose evidence actually contains the compared rows or measurements
+- Claim wording does not outrun the evidence type (for example, validation tables alone should not be used to claim training-dynamics improvements)
+- Trace nodes declare `support_level: explicit|inferred`
+- Trace nodes with `support_level: explicit` include source references
+
+### Step 6: Fix & Iterate
+
+For each validation failure:
+1. Read the failing file
+2. Apply targeted edits (prefer Edit over full rewrite to preserve correct content)
+3. Re-validate after all fixes
+
+Typically converges in 2-3 rounds.
+
+### Step 7: Report
+
+Print a summary:
+- Artifact location
+- File count and total size
+- Validation result (pass/fail with details)
+- Key statistics: number of claims, experiments, heuristics, concepts, tree nodes, evidence files
+
+## Critical Rules
+
+1. **Exact numbers**: All numerical values copied EXACTLY from source — never round or approximate
+2. **No hallucination**: Never invent claims, results, or heuristics not in the source material
+3. **Experiments have NO exact numbers**: `experiments.md` contains only directional/relative expected outcomes. Exact numbers go in `evidence/`
+4. **Every claim has proof**: Proof field references experiment IDs (E01, E02), not file paths
+5. **Cross-layer binding**: Claims ↔ Experiments ↔ Evidence ↔ Code refs must all resolve
+6. **Dead ends matter**: Include failed approaches, rejected alternatives, ablation findings
+7. **"Not specified"**: If information is genuinely unavailable, write "Not specified in paper" — never guess
+8. **No fake source labels**: Never call a derived subset `Table N` or `Figure N` unless it faithfully reproduces the original source object
+9. **No synthetic trace history**: Do not invent decisions, dead ends, or experiments that are not explicit in the provided inputs; if a trajectory is inferred, mark it as inferred or omit it
+10. **Evidence-limited wording**: Do not use stronger language than the evidence supports; separate direct observations from interpretation
+
+## Reference Files
+
+For detailed schema specifications, load these on demand:
+- [references/ara-schema.md](references/ara-schema.md) — Complete ARA directory schema with field-level format for every file
+- [references/exploration-tree-spec.md](references/exploration-tree-spec.md) — Detailed exploration tree YAML specification with examples
+- [references/validation-checklist.md](references/validation-checklist.md) — All Seal Level 1 checks (what the validator looks for)