Rail #1 turned an inbox into evidence-backed life records (receipts, subscriptions, renewals, bookings) with no model calls and excerpts only (docs/LIFE_IMPORT.md). Rail #2 is statements: the same subscription audit and renewals radar, but with authoritative amounts.
The spike, not the feature: pick two real formats (one bank CSV, one OFX), write a throwaway parser, and answer in this issue: which fields are reliable across banks, how to dedupe against the email-derived records, what the life_records row looks like with an amount that is authoritative rather than estimated, and what must not be stored (account numbers, balances). The three refusals in ADR-21 still hold: no archive of the statement, no connectors or credentials, no model calls.
Done when: the findings are written up here with a proposed schema change, and we decide whether to build it.
Rail #1 turned an inbox into evidence-backed life records (receipts, subscriptions, renewals, bookings) with no model calls and excerpts only (
docs/LIFE_IMPORT.md). Rail #2 is statements: the same subscription audit and renewals radar, but with authoritative amounts.The spike, not the feature: pick two real formats (one bank CSV, one OFX), write a throwaway parser, and answer in this issue: which fields are reliable across banks, how to dedupe against the email-derived records, what the
life_recordsrow looks like with an amount that is authoritative rather than estimated, and what must not be stored (account numbers, balances). The three refusals in ADR-21 still hold: no archive of the statement, no connectors or credentials, no model calls.Done when: the findings are written up here with a proposed schema change, and we decide whether to build it.