# v0.1 vs v0.2 Reasoning Comparison — Findings

## Context
Both versions were tested with two key scenarios:
- Scenario A: "All customers cannot download invoices after logging in." (universal failure)
- Scenario B: "Some customers can log in but cannot download invoices." (partial failure)

The goal was to confirm the model distinguishes between universal and partial failures.

## Results — v0.1 Route (extraction-focused schema)

### Scenario A — All customers fail
- validationStatus: valid
- observations: 1 item ("All customers are unable to download invoices after logging in.")
- contradictions: empty (expected - universal failure, no contrast group)
- openUncertainties: root cause and login completion status

### Scenario B — Some fail  
- validationStatus: valid
- observations: 2 items ("subset completes login" + "subset fails invoice download")
- contradictions: empty (expected for this input type)
- openUncertainties: proportion affected, technical cause

**Key finding**: v0.1 uses two observations in Scenario B vs one in A to capture the subset distinction. No contradictions because both scenarios describe an observed problem, not a logical contradiction.

## Results — v0.2 Route (reasoning classification schema)

### Scenario A — All customers fail
- validationStatus: valid
- primaryType: observed_problem + fault_report (secondary)
- differences: empty (expected - universal failure has no contrast group)
- importantUnknowns: error message, recent changes to services
- reasoningModes: identify_difference, fault_investigation, identify_missing_information

### Scenario B — Some fail
- validationStatus: valid
- primaryType: observed_problem + fault_report (secondary)  
- differences (1): "The failure is limited to some customers, implying a difference between affected and unaffected user accounts"
- importantUnknowns: what distinguishes affected from unaffected accounts
- reasoningModes: identify_difference, fault_investigation, identify_missing_information

**Key finding**: v0.2 explicitly captures the quantifier difference in its differences section for Scenario B - this is the key structural distinction between all and some scenarios.

## Quantifier Distinction Verification

Both versions correctly handle the universal vs partial failure distinction:

| Aspect | Scenario A (All) | Scenario B (Some) |
|--------|-----------------|-------------------|
| v0.1 observations | 1 (universal) | 2 (login OK + download fail) |
| v0.1 contradictions | 0 (expected) | 0 (expected) |
| v0.2 primaryType | observed_problem | observed_problem |
| v0.2 differences | empty (no contrast) | explicitly notes subset limitation |
| v0.2 unknowns focus | root cause | what distinguishes affected accounts |

Both versions produce valid structured output and correctly distinguish universal vs partial failure scenarios.

## Prompt Fix Summary

The v0.2 prompt template (prompts/reconstruct-v0.2.md) was updated to include an explicit JSON output schema section that:
1. Specifies exact camelCase key names matching the Zod schema
2. Lists all valid enum values for primaryType and reasoningModes  
3. Defines the complete nested structure for reconstruction, evidence, and nextQuestion
4. Includes critical rules preventing snake_case keys or invented top-level fields

Before fix: Model output had input_classification, reasoning_mode, anchors - all invalid per Zod schema -> validationStatus: invalid
After fix: Model output has inputClassification, reconstruction, evidence, nextQuestion with correct nested structure -> validationStatus: valid