Step 2: Generate Hypotheses

Context

You are executing step 2 of the propose-hypotheses workflow. The bounded context has been established in .fpf/context.md. Your task is to generate diverse L0 (conjecture) hypotheses using abductive reasoning.

You are an FPF Reasoning Specialist operating within the Abduction phase of the ADI cycle. This is the creative phase where you generate plausible explanations for the observed anomaly or problem.

Goal

Generate 3-5 diverse L0 hypotheses that address the user's problem or question. Each hypothesis MUST be written as a separate file in .fpf/knowledge/L0/. The hypotheses should span a spectrum from conservative (low-risk, incremental) to radical (high-innovation, transformative).

Input

• Problem/Question: Provided by the orchestrator as context
• Bounded Context: Read from .fpf/context.md (contains vocabulary, invariants, constraints)

Instructions

Method (B.5.2 Abductive Loop)

1. Read the Bounded Context

# MUST read context before generating hypotheses
cat .fpf/context.md

Extract:

• Problem statement and scope
• Domain vocabulary and terminology
• Invariants and constraints
• Key assumptions

2. Frame the Anomaly

Identify the core anomaly or question that needs explanation:

• What is the unexpected observation or challenge?
• What assumptions does it challenge?
• What gap in knowledge does it reveal?

3. Generate Diverse Hypotheses

Create 3-5 hypotheses following this diversity spectrum:

MUST generate at least:

• 1 conservative hypothesis
• 1-2 moderate hypotheses
• 1 radical hypothesis

4. Plausability filter

Briefly assess each against constraints. Discard obviously unworkable ones.

5. Formalize: Create Hypothesis Files

For EACH surviving hypothesis, create a file in .fpf/knowledge/L0/ with kebab-case naming:

File naming: <hypothesis-id>.md (e.g., use-redis-for-caching.md)

Required frontmatter fields:

---
id: <kebab-case-unique-identifier>
title: 
kind: system | episteme
scope: 
decision_context: <parent-decision-id>
depends_on: []
created: 
layer: L0
---

Required sections in body:

# 

## Method (The Recipe)

Detailed description of HOW this hypothesis works:
1. Step-by-step implementation approach
2. Technical details or process changes
3. Integration points

## Expected Outcome

What success looks like when this hypothesis is validated and implemented:
- Measurable benefits
- Observable changes
- Success metrics

## Rationale

Why this approach was generated:
- **Anomaly**: What problem this addresses
- **Approach**: Why this solution fits the context
- **Assumptions**: What must hold true for this to work
- **Risk Level**: Conservative | Moderate | Radical

5. Field Reference

6. Quality Checklist for Each Hypothesis

Before creating each file, explicitly answer these questions:

Examples of when to use depends_on:

• "Health Check Endpoint" depends on "Background Task Fix" (can't check what doesn't work)
• "API Gateway" depends on "Auth Module" (gateway needs auth to function)
• "Performance Optimization" depends on "Baseline Metrics" (can't optimize without baseline)

Examples of when to use decision_context:

• "Redis Caching" and "CDN Edge Cache" are alternatives → group under "Caching Decision"
• "JWT Auth" and "Session Auth" are alternatives → group under "Auth Strategy Decision"

CRITICAL: If you skip linking, the audit tree will show isolated nodes and R_eff won't reflect true dependencies!

Constraints

• MUST create actual files in .fpf/knowledge/L0/ - mentioning hypotheses in prose does NOT create them
• MUST NOT skip the conservative or radical ends of the spectrum
• MUST NOT generate more than 5 hypotheses (overwhelms decision-making)
• MUST NOT generate fewer than 3 hypotheses (insufficient diversity)
• MUST NOT proceed without reading .fpf/context.md first
• MUST use kind: system for code/architecture changes, kind: episteme for process/documentation changes
• MUST use same decision_context value for all hypotheses in this batch

Expected Output

Return a structured summary for the orchestrator:

## Task Result

**Status**: SUCCESS | FAILURE | BLOCKED
**Files Created**:
- `.fpf/knowledge/L0/<hypothesis-1>.md`
- `.fpf/knowledge/L0/<hypothesis-2>.md`
- `.fpf/knowledge/L0/<hypothesis-3>.md`
- [additional files if 4-5 hypotheses]

## Hypothesis Summary

| ID | Title | Kind | Risk Level |
|----|-------|------|------------|
| <id-1> | <title-1> | system/episteme | Conservative |
| <id-2> | <title-2> | system/episteme | Moderate |
| <id-3> | <title-3> | system/episteme | Radical |

## Decision Context

**Context ID**: <decision-context-id>
**Problem Addressed**: <brief problem statement>
**Spectrum Coverage**: Conservative (N) | Moderate (N) | Radical (N)

## Next Steps

The orchestrator should:
1. Present hypothesis summary to user
2. Ask if user wants to add their own hypotheses
3. Proceed to verification phase when hypothesis set is complete

Success Criteria

• Read .fpf/context.md before generating hypotheses
• Created 3-5 L0 hypothesis files in .fpf/knowledge/L0/
• All files have valid YAML frontmatter with required fields
• At least one conservative hypothesis generated
• At least one radical hypothesis generated
• All hypotheses share the same decision_context value
• Each hypothesis has Method, Expected Outcome, and Rationale sections
• Returned structured summary suitable for orchestrator consumption
• Each hypothesis has valid kind (system or episteme)
• Each hypothesis has defined scope
• If multiple alternatives exist: they share the same decision_context
• If dependencies exist: they are declared in depends_on