KakeFlow

01 · Production problem

Imported financial records are suggestions until source, amount and balance are reviewable.

Bank exports, card statements, receipts, PDFs and brokerage files disagree in format and sometimes omit critical facts. Treating OCR or parser output as confirmed accounting can create duplicates, fabricated dates and unbalanced records.

KakeFlow keeps extracted data and evidence outside the canonical ledger until review. It then posts balanced double-entry transactions with source lineage. This is a product implementation for a real failure class; there is no published user-adoption claim.

02 · Architecture and trade-offs

Separate capture, evidence, approval and accounting.

1. User-provided sources enter local parsers and bundled PP-OCRv5 receipt processing.
2. Encrypted evidence and normalized candidates remain reviewable before posting.
3. Explicit approval produces balanced double-entry entries with row-level provenance.
4. Budgets, reconciliation, reports and investments consume the approved ledger.

The desktop uses a local SQLCipher ledger. The PWA stores encrypted events and projections in IndexedDB and encrypted evidence in OPFS where available, with encrypted IndexedDB fallback. Local processing protects privacy and offline use, but the PWA intentionally lacks desktop connectors, multi-device sync and full native feature parity.

Architecture · Operations · Security

03 · Benchmark or failure case

Missing evidence remains blocked instead of becoming a plausible transaction.

The receipt normalizer accepts wide-spaced yen amounts and tax-marked prices, but it does not invent a transaction date when the image has none. An incomplete candidate remains outside the ledger for review. The public receipt-to-provenance story uses a synthetic Tanaka-family example and shows local OCR, source comparison, approval, balanced posting and provenance.

The exact release revision 6bd7bfc passed public Quality and Pages deployment.

04 · Reproduce in under five minutes

Follow receipt evidence to one approved posting in 90 seconds.

1. Watch the receipt-to-provenance video.
2. Open the account-free PWA and create a local encrypted vault.
3. Use the reviewed flow to compare source evidence before approving a balanced entry.

Expected result: a candidate is visibly separate from the ledger until approval, and the posted entry retains provenance. No personal financial data is required.

05 · What I designed and led

I designed the local trust boundary and the source-to-ledger product flow.

I own the review-first architecture, provenance model, parser/OCR failure behavior, balanced posting boundary, encrypted PWA foundation, offline behavior, localization contract and release qualification. The work demonstrates end-to-end product engineering; it does not establish management of a production customer team.

06 · Limitations and missing evidence

The release is public; distribution and adoption evidence remain bounded.

• No published customer adoption, retention or real-household outcome evidence.
• The PWA lacks desktop connectors, multi-device sync, native backup compatibility and full desktop parity.
• The macOS release is not represented here as Apple-notarized without external proof.
• As of 28 August 2026, the exact-head CodeQL run ended in startup failure and one medium-severity glib dependency alert remained open.
• KakeFlow does not initiate payments or treat extracted records as confirmed accounting.