## Outcome

- Reproduced the productive preview entirely locally against SQLite opened with `mode=ro`.
- Preview matched the existing baseline exactly: **1,787 rows, 1,786 candidates, 1,301 review cases, 423 proposals, 32 safe-transfer postings, and 464 immediately materializable transactions**.
- Aggregation remained in memory; no raw transaction rows, account references, filenames, or private counterparty names are included below.

## Root-cause partition

| Root cause | Cases | Share |
|---|---:|---:|
| Repeated unresolved patterns—primarily missing category rules | **857** | **65.9%** |
| One-off/singleton patterns with insufficient evidence | **344** | **26.4%** |
| Explicit genuine ambiguity: conflicting history, unmatched settlement semantics, receipt linkage, possible duplicates | **54** | **4.2%** |
| Workflow/review-flag artifacts: safe transfers or actionable proposals still counted as review | **46** | **3.5%** |

The backlog is therefore predominantly a **classification-coverage problem**, not genuine ambiguity.

### Explicit ambiguity detail

- Conflicting confirmed-category history: **12**
- Unmatched credit-card settlement semantics: **16**
- Receipt-linkage decisions: **22**
- Possible logical duplicates: **4**

Separately, **32 safely paired transfer legs** remain review-flagged even though the transfer engine has already established safe semantics. There are also **15 category proposals** in review; one overlaps a possible duplicate, leaving **14 directly actionable proposals**.

## Source and semantic distribution

- VISA: **867**
- AKB: **345**
- Raiffeisen: **67**
- Receipt-detail source: **22**

Semantics:

- Expense: **1,179**
- Income: **74**
- Transfer: **32**
- Credit-card payment: **16**

Signs are internally coherent:

- Negative: **1,197**
- Positive: **104**
- All ordinary expenses are negative; all ordinary income is positive.
- Transfers are balanced **16 negative / 16 positive**.

## Current rule coverage

The active database contains:

- **25** active categories
- **2** active merchant definitions
- **0** active aliases
- **0** active source-review rules
- **235** confirmed categorized historical transactions

Within the 1,301 review cases:

- Existing active-category proposal: **15**
- No category proposal: **1,286**
- Unresolved classifier result: **1,226**
- Consistent history used: **14**
- Conflicting history: **12**

A concrete defect explains the largest obvious gap: the classifier searches for a grocery category using a different separator than the active category’s actual name. Consequently, the known grocery-family rule does not activate.

## Privacy-safe merchant clustering

Using exact normalized merchant/description plus source:

- Exact source-scoped clusters: **478**
- Repeated clusters: **110**, covering **933 cases**
- Singleton clusters: **368**, covering **368 cases**
- Clusters with at least 3 cases: **63**, covering **839 cases**
- Clusters with at least 5 cases: **34**, covering **744 cases**

Largest current clusters:

| Cluster | Cases | Interpretation |
|---|---:|---|
| `cluster-001` | **250** | Known grocery family; consistently negative expenses |
| `cluster-002` | **91** | Opaque, consistently negative expense |
| `cluster-003` | **36** | Opaque, consistently negative expense |
| `cluster-004` | **30** | Settlement/transfer semantics—do not make a category rule |
| `cluster-005` | **27** | Opaque, consistently negative expense |
| `cluster-006` | **26** | Opaque, consistently negative expense |
| `cluster-007` | **25** | Opaque, consistently negative expense |
| `cluster-008` | **24** | Known pharmacy family; consistently negative expenses |
| `cluster-009` | **22** | Receipt detail—linkage only, never a second expense |
| `cluster-010` | **16** | Opaque, consistently negative expense |

## Coverage thresholds

Cases required:

- **80%:** 1,041
- **90%:** 1,171
- **95%:** 1,236

Using only exact source-scoped clusters, ranked by frequency:

- 80% requires the largest **218 clusters**
- 90% requires **348 clusters**
- 95% requires **413 clusters**

This long tail means hundreds of literal exact rules are the wrong solution. Source-qualified family normalization and confirmed-decision learning are required.

## Detail-field availability

All 1,301 cases have descriptions. Additional data is substantially underused:

- **889** have a structured merchant field.
- VISA’s **867** cases all contain transaction identity, details, type, original amount/currency, exchange-rate state and valuation date; place/country is available for **763**.
- All **345 AKB** cases contain booking/value dates, narrative and running balance.
- All **67 Raiffeisen** cases contain booking/value dates, narrative and running balance.
- All **22 receipt cases** contain branch/register/receipt/article-level detail.

The current category classifier principally uses source, normalized merchant/description, sign and history. Most VISA detail fields and bank narrative structure are not yet used for category-family extraction.

## Recommended largest safe rule families

1. **Repair the known grocery-family/category-name mismatch**
   - Covers approximately **256 monetary review cases**.
   - Reuse the active **Essen & Haushalt** category.
   - Exclude the 22 receipt-detail rows; those remain enrichment/linkage records.

2. **Add source-qualified, negative-expense rules for clearly recognized public families**
   - Pharmacy family → **Gesundheit**: **37**
   - Discount-grocery family → **Essen & Haushalt**: **25**
   - Coop family → **Essen & Haushalt**: **4**
   - Streaming/media family → **Elektronische Medien**: **4**

   Combined with the grocery fix: about **326 cases**, or **25.1% of the entire review backlog**.

3. **Privately label the largest opaque families once**
   - Start with `cluster-002`, `003`, `005`, `006`, and `007`.
   - Together they cover **205 consistently signed expense cases**.
   - Do not infer their categories from frequency alone; one reviewed family-level decision can seed exact/source-aware rules.

4. **Keep medium-confidence families out of automatic confirmation**
   - Telecom family: **24**; no clearly dedicated active category.
   - Rail/public-transit family: **4**; travel versus routine mobility is ambiguous.
   - Require one explicit category decision before learning.

5. **Remove non-review work from the headline**
   - Clear the review flag for the **32 safe transfer legs** after safe pairing.
   - Surface the **14 non-duplicate category proposals** as a proposal-confirmation queue rather than unresolved review.

6. **Preserve manual review**
   - Conflicting history, duplicates, receipt linkage and unmatched settlements must remain explicit decisions.
   - Singleton cases should seed future learning, not trigger broad substring rules.

## Safe reproduction approach

1. Open production SQLite using a read-only URI.
2. Resolve only opaque active mapping identifiers.
3. Load private inputs locally and invoke the internal preview function without confirm.
4. Assert the complete baseline counts and `confirmable=true`.
5. Filter only `requires_review=true`.
6. Aggregate in memory by source, internal reason, semantics/sign, detail availability, source-scoped normalized cluster and current category origin.
7. Emit only counts, opaque cluster IDs and explicitly allowlisted public merchant-family labels.
8. Reject any report containing descriptions, raw rows, account hints, references, hashes or private counterparty text.

## Changes and issues

- **Files created or modified:** none.
- **Production data:** unchanged; no confirm/import executed.
- **Issue encountered:** the target worktree had no local virtual environment, so an existing compatible project environment was used for the read-only reproduction.