# State Reconstruction Correctness Analysis

**Finding ID:** 55
**Date:** 2026-05-09
**Document:** gargoyle/docs/domain/contexts/market-data/corporate-actions.md (~120 lines)
**Task type:** State reconstruction correctness analysis — a NEW analytical lens
**Prompt:** "Can the system correctly reconstruct its state at any arbitrary point in time given only the event stream?"
**Models compared:** GPT-5, Claude Sonnet 4.6, Claude Opus 4.6

## Experiment Design

This experiment tests a novel analytical lens: **state reconstruction correctness**. Unlike previous lenses that focus on gaps, race conditions, or implementation ambiguities, this lens asks whether the system's event stream is sufficient for:

1. **Time-travel queries:** Answering "what was position X at timestamp T?"
2. **Retroactive truth:** Handling actions whose effective date precedes detection/application
3. **Event ordering:** Determining which temporal dimension orders events for replay
4. **Audit trail completeness:** Enabling an auditor to reconstruct exact before/after states
5. **Snapshot consistency:** Ensuring snapshot + replay events converges to the same state

This lens is particularly relevant for systems that claim to be event-sourced or must satisfy regulatory audit requirements.

## Performance Metrics

| Model | Time | Input Tokens | Output Tokens | Reasoning Tokens | Findings |
|-------|------|--------------|---------------|------------------|----------|
| GPT-5 | 83s | 1,294 | 6,275 | 3,968 | 10 |
| Claude Sonnet 4.6 | 74s | 1,485 | 3,890 | (internal) | 10+ (truncated) |
| Claude Opus 4.6 | 55s | 1,485 | 2,579 | (internal) | 10 |

## Key Findings by Model

### All Three Identified (Common Ground)

All models converged on these CRITICAL issues:

1. **Missing effective_date in action.applied event** — The telemetry event schema shows no effective_date, making it impossible to answer time-travel queries correctly
2. **Undefined `details` field** — The document says "Record immutable adjustment events capturing before/after state" but the event schema uses an unstructured `details` blob with no contract
3. **Three-timeline conflation** — Effective date, detection time, and application time are distinct concepts but not preserved separately in events
4. **No before/after lot-level state in events** — Cannot reconstruct exact lot mutations from the event stream alone

### GPT-5 Unique Findings

GPT-5 produced the most exhaustive analysis with specific operational concerns:

- **Currency and numeric precision unspecified** — Cost basis calculations need explicit rounding rules for deterministic replay
- **No idempotency key for per-user/per-lot adjustments** — Crash-retry could produce duplicates
- **Cash postings (dividends, cash-in-lieu) lack event modeling** — Pay date vs. ex-date vs. record date semantics missing
- **Instrument identity changes lack time-indexed mapping events** — Old→new symbol transitions not replayable
- **Cross-reference normative authority undefined** — Which document is source of truth when specs conflict?

GPT-5's recommendations section was exceptionally actionable, specifying exact event schema additions.

### Sonnet Unique Findings

Sonnet provided the clearest framing of the bi-temporal problem:

- **Bi-temporal data model missing** — System needs both valid time (when world changed) and transaction time (when we recorded it)
- **Silent deduplication is invisible in event stream** — No way to know if duplicates were suppressed
- **Delisting leaves phantom lots with no terminal state event** — Lots exist forever in "delisted" state with no resolution path
- **Source accountability lost for manual entries** — No operator audit trail

Sonnet's analysis was remarkably structured with clear severity justifications.

### Opus Unique Findings

Opus excelled at identifying architectural category errors:

- **Events are telemetry, not sourcing events** — The document explicitly says "Naming follows the telemetry event convention," which is fundamentally incompatible with state reconstruction
- **State mutations with notification events ≠ event-sourced state transitions** — Core architectural mismatch
- **Spinoff basis allocation is non-deterministic without captured FMV parameters** — Replaying with different market data produces different results
- **"Mark the action as applied" has no corresponding event** — Completion tracking is stateful, not event-based

Opus's concluding insight was the most architecturally significant: "This system treats corporate actions as state mutations with notification events rather than as event-sourced state transitions."

## Comparative Analysis

| Dimension | GPT-5 | Sonnet | Opus |
|-----------|-------|--------|------|
| Finding count | 10 | 10+ | 10 |
| CRITICAL findings | 4 | 3 | 3 |
| Unique insights | 5 | 4 | 4 |
| Tokens per finding | 628 | 389 | 258 |
| Structural clarity | Good | Excellent | Excellent |
| Actionability | Highest | High | Medium |
| Architectural depth | Medium | High | Highest |

### Pattern Observations

**GPT-5** approaches state reconstruction as a specification completeness problem. It enumerates every field that should exist but doesn't, every timestamp that should be captured, every edge case in the replay logic. The output is a comprehensive implementation checklist.

**Sonnet** approaches it as a systems design problem. It frames the issues in terms of well-known patterns (bi-temporal modeling, event sourcing vs. CRUD) and explains *why* each gap matters for reconstruction. The output is a design review.

**Opus** approaches it as an architectural coherence problem. It identifies the fundamental category error — the document conflates telemetry events with sourcing events — and traces most specific issues back to this root cause. The output is an architectural critique.

## Novel Lens Validation

"State reconstruction correctness" proved to be a valuable analytical lens distinct from previous experiments:

1. **It requires temporal reasoning** — Unlike gap-finding or ambiguity detection, this lens specifically tests whether events can be replayed in time order to reproduce state
2. **It tests architectural properties, not just specification gaps** — The question isn't "what's missing?" but "does this design support a specific capability?"
3. **It's domain-independent** — Applicable to any event-driven system, not just financial platforms
4. **All three models found substantive issues** — The 120-line document had no obvious event-sourcing defects, yet all models identified CRITICAL reconstruction problems

## Practical Implications

**For state reconstruction review, use this pipeline:**

1. **Opus first** — Identifies architectural category errors (is this actually event-sourced or just event-logged?)
2. **Sonnet second** — Frames specific gaps in terms of standard patterns (bi-temporal, CQRS, etc.)
3. **GPT-5 third** — Produces actionable implementation checklist for remediation

**Cost-effectiveness for this lens:**
- Opus: 10 findings in 55s at 2,579 tokens = **258 tokens/finding** (best efficiency)
- Sonnet: 10+ findings in 74s at 3,890 tokens = ~389 tokens/finding
- GPT-5: 10 findings in 83s at 6,275 tokens = 628 tokens/finding (but includes recommendations)

For this specific task type, Opus delivers the most insight per token, but GPT-5's recommendations section adds significant implementation value.

## Lessons Learned

1. **"State reconstruction correctness" is a distinct analytical task** — It complements but doesn't overlap with gaps, races, or ambiguities
2. **Telemetry events ≠ sourcing events** — This is a common architectural confusion; the lens is good at detecting it
3. **All three models caught the core issue** — Multi-model review had ~70% overlap on CRITICAL findings, suggesting the lens is model-stable
4. **Opus identified the root cause most clearly** — Its "telemetry vs. sourcing" framing explains most specific findings

## Conclusion

The state reconstruction correctness lens is a valuable addition to the analytical toolkit. It's particularly useful for:

- Event-driven system design review
- Audit trail compliance assessment
- Data migration/replay planning
- Regulatory submission documentation review

For documents claiming event-sourcing or audit trail capabilities, this lens should be part of standard review — all three models found CRITICAL issues in a document that passed previous analytical lenses without major findings.