Fpf Methodology

Then, audit for bias, decide, and document the rationale in a durable record.

Assurance Levels

Knowledge claims are tracked at different assurance levels:

Commands

Use the following slash commands in order:

Key Concepts

WLNK (Weakest Link)

Assurance = min(evidence), never average. A chain is only as strong as its weakest link.

Congruence

External evidence must match our context (high/medium/low). Evidence from a different context may not apply.

Validity

Evidence expires — check with /q-decay. Stale evidence creates epistemic debt.

Scope

Knowledge applies within specified conditions only. Document the boundaries.

Workflow Example

User: How should we implement caching for our API?

/q0-init                           # Initialize knowledge base
/q1-hypothesize "API caching"      # Generate hypotheses

Hypotheses generated:
- H1: Redis with TTL-based invalidation (Conservative)
- H2: CDN edge caching (Novel)
- H3: In-memory cache with pub/sub invalidation (Hybrid)

/q2-verify H1                      # Verify Redis approach logic
/q3-validate H1                    # Test Redis in development

/q4-audit                          # Check for biases, weakest links
/q5-decide H1                      # Create Design Rationale Record

Design Rationale Record (DRR)

The /q5-decide command generates a DRR with:

• Context: The initial problem
• Decision: The chosen hypothesis
• Rationale: Why it won (citing evidence and R_eff)
• Consequences: Trade-offs and next steps
• Validity: When should this be revisited?

State Location

All FPF state is stored in .quint/ directory (git-tracked):

.quint/
├── context.md           # Project context and constraints
├── knowledge/
│   ├── L0/              # Unverified hypotheses
│   ├── L1/              # Logically verified claims
│   ├── L2/              # Empirically verified claims
│   └── invalid/         # Disproved claims
└── decisions/           # Design Rationale Records

Transformer Mandate

Critical Principle: You (Claude) generate options with evidence. Human decides.

A system cannot transform itself — the human partner makes final architectural decisions. Generate high-quality options, present evidence, but don't autonomously choose major architectural directions.

Integration with Code Review

After FPF-driven implementation:

1. Generate hypotheses for approach
2. Verify and validate the chosen approach
3. Implement with the structured reasoning as documentation
4. Code review references the DRR for context
5. Future developers understand why decisions were made

Benefits

• Auditability: Every decision has a documented trail
• Reduced Bias: Multiple hypotheses prevent anchoring
• Knowledge Retention: Project learnings persist
• Team Alignment: Clear rationale for decisions
• Technical Debt Prevention: Bad decisions caught early