Theory Design

Theory-Design — Paper-Type-Aware Theoretical Framework Design

🔬 Model Recommendation: Run this skill on Claude Opus for best results. Framework design requires deep reasoning across mathematical and methodological dimensions. If your session is not on Opus, run /model opus.

Goes from "I have a new research topic" to a structured FRAMEWORK_DESIGN.md that downstream skills can consume. The skill's central insight: the logical order of theoretical-framework design depends on what kind of paper you're writing.

Context: $ARGUMENTS

Pipeline Position

research-refine  →  /theory-design  →  /proof-writer  →  /theory-simulation  →  /proofcheck  →  /theory-sharpen  →  /proof-repair
(rough idea)        (framework)        (theorems)        (verify)              (audit)         (improve)           (fix)

This skill is the planning layer — chooses the framework, declares assumptions, sets target results — before any theorem is written or experiment run.

Step 0: Declare paper type (MANDATORY first decision)

Statistics papers come in three types with fundamentally different logical orders. The skill REFUSES to proceed until the user declares type. If unsure, the skill helps classify based on the topic description.

The three paper types

Decision aid (if user is unsure)

Ask in order:

1. Is your contribution primarily:

   • a new mathematical insight / theorem / theoretical tool → THEORY
   • a new procedure / algorithm / estimator → METHODOLOGY
   • a new finding from analyzing real data → APPLICATION

2. What would the "main result" section show?

   • A theorem (rate, distribution, lower bound, characterization) → THEORY
   • Properties of a procedure (consistency, rate, coverage of the procedure) → METHODOLOGY
   • Tables/figures of empirical estimates and p-values from real data → APPLICATION

3. What does the reviewer most care about?

   • Mathematical novelty and proof rigor → THEORY
   • Whether the method works better than competitors + has theoretical backing → METHODOLOGY
   • Substantive scientific conclusion + valid inference → APPLICATION

If still unclear: the topic might be a hybrid; force a choice and revisit.

Mode routing

Based on declared type, the skill runs ONE of three workflows:

• Theory mode → Step T1-T7
• Methodology mode → Step M1-M7
• Application mode → Step A1-A7

But FIRST, regardless of mode, run Step 0.5.

Step 0.5: MANDATORY Literature Anchoring

This step is NON-NEGOTIABLE. A theoretical framework designed without literature context is almost certainly either:

• Reinventing what's already done
• Deviating from field conventions for no reason
• Missing the "theoretical inertia" — how the community frames this problem
• Unpositioned — making it hard to assess the contribution

Build the literature anchor BEFORE any phase decision. Every subsequent phase must reference back to this anchor when making a choice.

0.5.cache: Cache-consult first (mandatory)

Before invoking any web search, consult the durable literature cache at ~/.claude/literature_cache/. The protocol lives in ../stat-shared-references/literature-cache-protocol.md (router with Minimum Load Map). For theory-design Step 0.5 the typical loads are:

• literature-cache-protocol.md (router) — always.
• citation-purpose-protocol.md — for lineage_positioning and benchmark_claim role identification of the anchor papers.
• applicability-axes.md — when matching cached papers to the topic signature's axis declarations (data structure, regime, framework, etc.).

Procedure: read the INDEX (and any relevant domain shards under ~/.claude/literature_cache/domains/) to identify which papers in the topic's theoretical line are already cached at source_checked or higher. Result-scoped loads only. The cache hits become the starting set; the four parallel-agent searches in 0.5B target only the cache misses.

Cache hits at independently_checked or higher are admissible as lineage anchors and benchmarks without a fresh fetch. Cache hits at source_checked are admissible for background and prose-only positioning; promotion to independently_checked is required if the paper enters the positioning argument as a benchmark.

0.5A: Topic signature for search

Build a structured topic signature for the search queries:

Topic signature:
- Primary subject:     [1-3 word phrase, e.g., "treatment effect estimation"]
- Method/technique:    [e.g., "doubly robust", "Poisson equation", "lasso", "M-estimation"]
- Data structure:      [iid / TS / mixing / Markov / panel / spatial / sequential / network]
- Modeling framework:  [parametric / semiparametric / nonparametric]
- Regime:              [classical / proportional / high-d / non-asymptotic / online]
- Application area (if applicable): [causal inference / genomics / finance / etc.]

0.5B: Multi-source T1 literature search (parallel)

Run in parallel — use Agent tool for each search agent:

Agent 1: T1 statistics journals (last 5 years preferred)

Search Semantic Scholar API:
  query = [topic signature components]
  year = current_year - 5 .. current_year
  venue ∈ {Annals of Statistics, JASA T&M, JASA ACS, AOAS, JRSS-B, Biometrika,
            Bernoulli, EJS, Statistica Sinica, Biostatistics, JCGS}
  fields = title, authors, year, abstract, venue, citationCount, externalIds

Apply filters:
  - Sort by recency; prefer last 3 years
  - Drop low-citation older papers
  - Keep top 10-15 most-relevant

Agent 2: T1 ML/AI conferences (last 5 years preferred)

WebSearch + Semantic Scholar:
  query = [topic signature components]
  venue ∈ {NeurIPS, ICML, ICLR, COLT, AISTATS, JMLR, UAI}
  
Same filtering rules.

Agent 3: T1 econometrics journals (if applicable)

Search:
  venue ∈ {Econometrica, Journal of Econometrics (JOE), Review of Economic Studies,
            Quantitative Economics, JBES, Econometric Theory, RFS, JF}

Agent 4: Highly-cited "consensus" papers (last 10 years)

Search:
  query = broader topic signature
  sort = citationCount desc
  year = current_year - 10 .. current_year
  limit = 10

Purpose: identify what the field considers CANONICAL recent work
(papers that define the current framework).

0.5C-0.5F: Extract, summarise inertia, choose positioning, derive constraints

For each anchor paper, record: problem framing, theoretical anchor, assumption profile, result type, proof technique, and position in the literature. Write the results to LITERATURE_ANCHOR.md.

Then produce three things, in order, because each constrains the next:

1. Theoretical inertia of the field — the default data structure, the default assumption set, the default result type, and the technique the field currently reaches for. This is what a referee will unconsciously expect. Name the classical machinery cluster the framework extends (minimax lower bounds, empirical process theory, semiparametric efficiency, local asymptotics, high-dimensional regularization, Bayesian asymptotics) or declare it frontier-native (conformal inference, e-values, computational-statistical trade-offs); naming neither is usually a sign the literature search missed the field's actual machinery.
2. Positioning options — INCREMENTAL (accept the inertia, push one dimension), LATERAL (change the object or the setting), or DISRUPTIVE (reject a default the field has stopped questioning). Name the cost of each; disruptive positioning buys novelty and spends referee goodwill.
3. Constraints derived from the anchor — what the chosen positioning now forbids. These bind every later phase decision; a framework that violates its own anchor constraints is incoherent, and the X-series checks will catch it.

Filled specimens for all four artifacts: ../stat-shared-references/examples/literature-anchor-example.md.

THEORY MODE (T1-T7)

Centerpiece: the theorem itself. Estimator often degenerate or absent.

T1: Phenomenon / object identification

Q1.1: What mathematical phenomenon, object, or impossibility are you trying to
      characterize, explain, or formalize?
      (Examples: BBP transition in high-dim regression; new concentration
       inequality for dependent data; minimax lower bound for a new class)

Q1.2: Is this an explanation of an observed effect, the introduction of a new
      abstraction, or both?

Q1.3: Why is the current theoretical toolkit insufficient?
      State precisely the technical step that cannot be handled by existing tools.

T2: Mathematical landscape mapping

Q2.1: What existing theoretical frameworks are most relevant?
      (Empirical process / RKHS / random matrix / convex analysis / information
       theory / Markov chains / ...)

Q2.2: Which tools from each framework can be reused?
      Which need extension or replacement?

Q2.3: Are there sibling results in adjacent fields (probability, optimization,
      info theory) that solved analogous structures?

Q2.4: Do a quick T1 literature scan for related results in the last 5 years.
      Save findings to FRAMEWORK_DESIGN.md as the "landscape" section.

T3: Conceptual framework & notation

Q3.1: At what level of abstraction does the theory live?
      (Pointwise theorem / parameter class / function class / operator level)

Q3.2: What is the right notation system?
      Compatible with which existing literature?
      Where to introduce new notation? (do so sparingly)

Q3.3: What is the underlying probability space / σ-algebra / filtration setup
      if dependence or sequential structure is involved?

T4: Formal problem setup

Q4.1: Define the spaces, parameter classes Θ, function classes F, etc.
      Be explicit about: domain, range, topology, measure.

Q4.2: Regularity on the PROBLEM (not on methods):
      - Smoothness of underlying object?
      - Identifiability conditions?
      - Boundedness / tail behavior?

Q4.3: Asymptotic regime (which path is taken to ∞?)
      Same axes as theory-sharpen: classical / proportional / sparse / non-asymptotic / online.

T5: Target theorems (conjectures + impossibility)

This is where theory papers differ most from methodology: both upper and lower bounds are equally first-class citizens.

Q5.1: Upper-bound conjecture: what positive result do you AIM to prove?
      Write a placeholder theorem statement.

Q5.2: Lower-bound conjecture: what impossibility result is needed to certify the
      rate / characterization is sharp?
      (Minimax via Fano / Le Cam / Assouad; or worst-case lower bound)

Q5.3: Are upper and lower bounds going to match? (If not, the gap is itself a
      contribution or a future-work problem.)

Q5.4: Auxiliary theorems: are there secondary results (consistency, structural
      characterization, phase transitions) that strengthen the paper?

Q5.5: For each target theorem: sketch the regime / parameter range where it should hold.

T6: Proof strategy & lemma scaffold

Q6.1: High-level path: direct / contradiction / induction / coupling /
      reduction / construction / variational?

Q6.2: Major decomposition (if any): e.g., bias + variance, oracle + remainder,
      martingale + drift, signal + noise, low-rank + sparse.

Q6.3: Key tools needed: chaining / localization / Bernstein / Poisson equation /
      decoupling / spike-and-slab / random matrix concentration / etc.

Q6.4: Anticipated hardest step: where do you expect the proof to fight back?
      Have related papers handled similar difficulties?

Q6.5: Lemma scaffold: list 3-8 auxiliary lemmas you anticipate needing.
      (proof-writer can later be invoked to draft each)

Q6.6: Sketch a proof outline (≤ 1 page) BEFORE detailed proving.

T7: Connections (open to downstream)

Q7.1: What method designs does this theory enable / inform?
      (Theory paper authors should NOT design the method here; they should
       enumerate what becomes possible.)

Q7.2: Who will cite this paper? (theorists / methodologists / applied users)
      What is the chain of impact?

Q7.3: Open problems your theory raises but doesn't solve.
      These go in the Discussion section and seed future papers.

After T1-T7, FRAMEWORK_DESIGN.md is complete. Hand off:

• T5 conjectures → /proof-writer to draft theorem statements
• T6 lemma scaffold → /proof-writer to draft each lemma
• Optional simulation illustration → /theory-simulation (lightweight DESIGN mode)
• After proofs drafted → /proofcheck

METHODOLOGY MODE (M1-M7)

Centerpiece: a new method. Theory exists to guarantee the method.

M1: Practical problem & method gap

Q1.1: What practical statistical problem motivates the new method?
      (Examples: causal inference under unmeasured confounding; high-dim variable
       selection with grouped sparsity; nonparametric test for monotonicity)

Q1.2: What can existing methods NOT do, or do poorly?
      Be precise: name the existing methods and the specific gap.

Q1.3: Who needs the new method? (Sub-discipline / data modality / problem class)

M2: Method design (CENTERPIECE — differs most from theory papers)

Q2.1: Define the estimator / algorithm / procedure precisely.
      Pseudo-code or formula.

Q2.2: Tuning parameters: list each (λ, h, K, ...).
      How will each be chosen in practice? (CV, plug-in, BIC, oracle?)

Q2.3: Computational considerations:
      - Closed-form vs iterative?
      - Complexity in n, d?
      - Scalability claim — paper will need /theory-simulation computational audit
        if claimed.

Q2.4: Does the method use cross-fitting / sample splitting / debiasing?

Q2.5: Sanity checks: can the method be a wrong choice?
      Are there degenerate inputs where it fails?

M3: Model setup for analysis

Q3.1: Under what DGP / model class will you ANALYZE the method?
      (Should be realistic enough to be useful, not so general that proofs become
       impossible.)

Q3.2: Data structure (i.i.d. / mixing / Markov / panel / spatial / sequential)?

Q3.3: Asymptotic regime to target (n→∞, d→∞, sparsity, ...)?

Q3.4: Pre-declare which assumptions will likely show up in analysis (without
      committing yet — this is the rough plan).

M4: Identification

Q4.1: Is the target estimand identified under your model?
      What conditions are needed?

Q4.2: Can identification fail for plausible data configurations?
      Address weak / partial / no identification explicitly.

Q4.3: Are identification conditions VERIFIABLE in data, or only theoretical?
      (E.g., positivity in causal inference is verifiable; no-unobserved-confounding
       is not.)

M5: Theoretical guarantees needed

Q5.1: Required guarantees (in order of necessity):
      - Consistency? (almost always required)
      - Rate of convergence? (required for parametric / nonparametric / high-dim)
      - Asymptotic distribution / CLT? (required for inference)
      - Coverage of CIs? (if paper claims inference)
      - Uniformity over Θ? (if claimed; otherwise weaker pointwise suffices)
      - Structural recovery? (if claimed)

Q5.2: Robustness guarantees:
      - To misspecification?
      - To contamination / outliers?
      - To dependence violations?

Q5.3: What's the MINIMAL assumption set that gives the guarantees?
      Iterate this — start broad, narrow down.

Q5.4: Computational guarantees if relevant:
      - Convergence of iterative procedure?
      - Step size conditions?
      - Local-vs-global optimum?

M6: Simulation + real-data validation plan

(Methodology papers REQUIRE both. Application is mostly demonstration.)

Q6.1: Simulation plan: hand off to /theory-simulation DESIGN mode
      - rate verification along asymptotic path
      - inference diagnostics (coverage, size, power, EmpSE/ModSE)
      - stress tests on each critical assumption
      - paired comparison against ≥1 competitor

Q6.2: Real data application:
      - Which dataset? Why is it the right test case?
      - Is the application demonstrating practicality, not proving anything new?
      - What assumption-checking will be done on the data?

M7: Proof strategy

Q7.1: Proof approach: M-estimation framework / influence function expansion /
      empirical process / regularization theory / etc.

Q7.2: Decomposition: typically bias + variance, or oracle + remainder for
      cross-fitting.

Q7.3: Key technical lemmas (often more "technical labor" than in theory papers):
      list 3-10 lemmas needed.

Q7.4: Are you proving NEW theory, or using EXISTING theory?
      For methodology papers, the proof is usually technical labor applying
      existing theory to your specific method. State this honestly.

After M1-M7, hand off:

• M2 method definition → can be implemented in code
• M5 target guarantees → /proof-writer to write theorem statements
• M6 validation plan → /theory-simulation (DESIGN mode)
• M7 proof strategy → /proof-writer for each guarantee
• After proofs → /proofcheck

APPLICATION MODE (A1-A7)

Centerpiece: the empirical insight. Method is chosen, not invented.

A1: Scientific question & data

Q1.1: What scientific / economic / medical question motivates this paper?
      Articulate as a sharp hypothesis or estimation target.

Q1.2: What data answers this question?
      - Source, size, structure
      - Strengths and weaknesses
      - Why this data and not other data?

Q1.3: Who is the audience? (Domain experts? Statisticians?)
      Tone and depth of statistical detail varies.

Q1.4: What is the substantive prior? (Effect direction, magnitude, mechanism?)

A2: Existing-method selection

Q2.1: Which existing methods match (data structure, question)?
      List 2-3 candidates with pros/cons.

Q2.2: Why this specific method?
      State the trade-off and justify.

Q2.3: Is any method modification needed?
      If yes — this might be METHODOLOGY mode, not APPLICATION; reconsider.

Q2.4: What recent methodological developments could improve this analysis?
      (Don't necessarily use them — but show awareness.)

A3: Assumption verification on THIS dataset (distinguishes APP from METH)

This is the central technical content of application papers.

Q3.1: For each assumption of the chosen method, ask:
      - Is it VERIFIABLE in the data? How?
      - If verifiable: what is the test/diagnostic? What's the result?
      - If not: what plausibility argument substitutes for verification?

Q3.2: Standard checks for common methods:
      - Causal inference: positivity (verifiable), no-unmeasured-confounding (sensitivity)
      - Regression: linearity (residual plots), homoskedasticity (Breusch-Pagan), normality (QQ)
      - Time series: stationarity (KPSS), mixing structure
      - High-dim: sparsity heuristics, RE condition (approximate check)

Q3.3: For untestable assumptions: design sensitivity analyses (Rosenbaum-style,
      E-value, partial identification bounds, etc.)

A4: Empirical findings (the main result)

Q4.1: Primary estimand and its estimate; effect size, direction.

Q4.2: Comparison: does this estimate confirm, refine, or contradict prior literature?

Q4.3: Subgroup / heterogeneity analyses: preregistered or exploratory?
      Multiplicity correction if exploratory.

Q4.4: Reporting standards for the field (CONSORT, STROBE, REMARK, etc.)

A5: Inference & uncertainty quantification

Q5.1: What standard error / confidence interval procedure is used?
      Does the chosen method's theoretical assumptions for inference hold here?

Q5.2: Bootstrap, asymptotic, or finite-sample?
      Validity check: does the inference procedure have theoretical backing in
      the regime of this data (n, d, structure)?

Q5.3: Multiple testing strategy if applicable.

Q5.4: Coverage / size diagnostics on simulated data calibrated to the real data
      (optional but strengthens the paper).

A6: Sensitivity analyses

Q6.1: To untestable assumptions:
      - Causal: unmeasured confounding (Rosenbaum sensitivity, E-value)
      - Missing data: NMAR scenarios
      - Model: alternative specifications

Q6.2: To outliers / influential observations:
      - Influence diagnostics
      - Trimmed / robust estimators as comparison

Q6.3: To pre-processing decisions:
      - Variable transformations
      - Sample inclusion / exclusion

Q6.4: Pre-specify which sensitivity results would CHANGE the conclusion.

A7: Connection to literature & implications

Q7.1: How do findings update the scientific literature?
      Specific claims that this paper supports, modifies, or refutes.

Q7.2: Policy / clinical / scientific implications.
      Be honest about external validity.

Q7.3: Open questions and future-work directions.

After A1-A7, hand off:

• A3 verification → coded diagnostics
• A4-A5 main analysis → coded analysis pipeline
• A6 sensitivity → coded sensitivity analyses
• Optional methodology gap notes → could spawn a METHODOLOGY paper later

Step X: Cross-type quality checks (run for ALL modes)

After the type-specific workflow, run these universal checks:

X1: Internal consistency

- Does the model in Step 3/4 (depending on mode) match what the assumptions reference?
- Does the target result (T5 / M5 / A4) align with what the proof / method / data
  can actually deliver?
- Is the asymptotic regime consistent throughout?

X2: Novelty / contribution audit (literature-anchored)

- Is the contribution clearly stated in 1-2 sentences?
- Does it match the paper-type's expected contribution kind?
- Cross-reference against LITERATURE_ANCHOR.md:
  * Is the contribution genuinely distinct from the 10-15 recent T1 papers?
  * Is there a "kill shot" risk — a recent paper that scoops 80% of this?
  * Is the contribution magnitude appropriate for the positioning chosen
    (incremental / lateral / disruptive)?
- For DISRUPTIVE positioning: does the framework actually justify the deviation?
- For INCREMENTAL positioning: is the refinement substantial enough to publish?

Cross-check with /novelty-check or /research-lit if available.

X2.5: Positioning audit (literature-anchored)

Re-examine the positioning from Step 0.5E against the now-detailed framework:

## Positioning Verification

### Chosen positioning: [INCREMENTAL / LATERAL / DISRUPTIVE]

### Coherence check
- Does each phase decision match the positioning?
  * INCREMENTAL: Did you adopt the inertia's defaults except where you refine?
  * LATERAL: Did you justify the angle change?
  * DISRUPTIVE: Did you build the case for the new framework?

### Drift check
- During T1-T7 / M1-M7 / A1-A7, did the framework drift from the chosen positioning?
  Example: started INCREMENTAL but ended up using a non-standard regime — should
  either re-route to LATERAL or revert.

### Citation strategy alignment
- Which 5-10 papers from LITERATURE_ANCHOR.md will be cited prominently?
- Citation structure: predecessors → competitors → adjacent → applications
- For each, what role do they play?
  * "Our paper extends [predecessor] by..."
  * "Unlike [competitor], we..."
  * "[Adjacent] uses similar tools in a different setting..."
  * "[Application] motivates the practical need..."

If positioning has drifted, decide: revert framework to match original positioning, or update positioning to match what framework evolved into. Either is fine; the mismatch is the problem.

X3: Reviewer hot-button check

What will a top-stat-journal referee almost certainly ask?

• For THEORY: matching lower bound? Adaptive version? Connections to known frameworks?
• For METHODOLOGY: tuning robustness? Computational feasibility? Realistic assumptions?
• For APPLICATION: assumption verifiability? Sensitivity? Pre-registration?

Pre-empt these in the framework.

X4: Codex independent review — discussion, not acceptance

Send the draft framework to Codex per ../stat-shared-references/codex-protocol.md. Codex is an adversarial reviewer to discuss with, never an oracle to defer to.

Every finding gets an explicit disposition — ACCEPT, PUSH BACK, or REQUEST CLARIFICATION — with reasoning recorded. A framework decision is not changed because Codex asserted it; it is changed because the argument holds. Escalate to the user any finding that would change the paper type, the positioning, or a headline claim.

Record the exchange in FRAMEWORK_REVIEW.md: one row per finding (finding, severity, Codex position, disposition, reasoning), plus the round-by-round history and any escalations.

Per-finding evaluation shape and a worked dialogue: ../stat-shared-references/examples/theory-design-codex-dialogue-example.md.

Output: FRAMEWORK_DESIGN.md

Final structure of the document this skill produces:

# Framework Design: [Topic]

## Paper type: [THEORY / METHODOLOGY / APPLICATION]
## Justification: [why this type]

## Phase 1: [paper-type-specific phase 1 — Phenomenon / Practical-problem / Scientific-question]
...

## Phase 2: [...]
...

## Phase 7: [...]

## Cross-type checks
- Internal consistency: ...
- Novelty audit: ...
- Reviewer hot-button: ...
- Codex review: ... (if run)

## Handoff plan
- [downstream skill] receives [artifact] for [purpose]
- ...

Assumption lock initialization (all modes)

The framework shares one assumption system, not a fresh set per theorem. After the assumption profile is settled (T-mode Step T5/T6, M-mode Q5.3 minimal set, A-mode A3), promote those prose assumptions into a canonical, ID-addressable store assumptions.lock.md, per ../stat-shared-references/assumptions-lock-protocol.md. Write the ## Assumption Registry table (assign A1, A2, …, tag each with an applicability-axes.md axis and a strength/regime class, and set Relation to other IDs for any variant) and seed an empty ## Theorem Invocation Matrix for proof-writer to fill.

This is the single source of truth every downstream package invokes by ID. Do not state a maximal assumption set that every theorem inherits — the store is a registry, not a global premise; each theorem later lists only the subset it uses.

Hand assumptions.lock.md to /proof-writer alongside FRAMEWORK_DESIGN.md.

Quick start (single command)

/theory-design "doubly robust estimator for treatment effect under unmeasured confounding"

Skill will:

1. Help classify (likely METHODOLOGY)
2. Walk M1-M7 with interactive Q&A
3. Run cross-type checks
4. Output FRAMEWORK_DESIGN.md
5. Recommend next skill (most likely /proof-writer for the consistency theorem)

Output Summary

Framework design complete for [Topic].

Paper type: [TYPE]
Phases completed: 7 + cross-type checks
Codex review: [done / skipped]

Key decisions made:
- [decision 1]
- [decision 2]
- ...

Files created:
- FRAMEWORK_DESIGN.md — the design document
- (optional) NOVELTY_NOTES.md — what's new vs literature
- (optional) codex_review.md — independent assessment

Next steps:
- Run /proof-writer for target theorem T5/M5
- Run /theory-simulation DESIGN mode for validation plan (if methodology)
- Run /proofcheck after first draft of proofs
- Run /theory-sharpen periodically to assess sharpenability