Your money should not have to leave your phone.

Decision 04

Constrain the generation, then validate it anyway

Model output is forced into valid JSON matching the app's schema using a grammar at generation time — the model cannot emit malformed structure because the grammar will not let it.

And then a schema-validation pass runs afterwards regardless. That is belt and braces, and it is deliberate: a grammar constrains shape, not sense, and model output that is about to be written into someone's financial record is not data I am willing to trust on one guarantee.

Decision 05

Give the memory back when the model is idle

An idle-unload policy releases the model from memory when it is not actively being used. On a RAM-constrained Android device, a gigabyte held resident because the user might ask another question is a gigabyte taken from everything else they are doing — and the fastest way to have a finance app uninstalled is to make the phone feel slow.

Decision 06

Converge PDF onto the CSV pipeline instead of building a second one

PDF import handles password-protected statements and detects scanned, image-only PDFs that need different treatment from text-layer ones. Then it reconstructs the page layout into a grid — and feeds that grid into the same header-mapping and row-parsing components the CSV and Excel pipeline already used, unchanged.

Building a parallel PDF-specific parser would have been the obvious route and would have doubled the surface where the two paths could quietly disagree about the same statement. Instead a cross-format consistency test asserts that the PDF-derived and CSV-derived versions of the same transaction agree.

That test deliberately asserts on every field deduplication relies on, rather than the easier, more obvious surface fields of date and amount. The fields that matter are the ones a duplicate would hide behind.

Decision 07

Keep the date out of the duplicate check

Transactions arriving from different sources are deduplicated on what identifies the payment itself — and for transactions carrying a strong bank reference, the date is deliberately left out.

This was discovered, not designed. An SMS alert and a statement row describing the same real-world payment can disagree on transaction date versus posting date. A date-sensitive check would have silently created duplicate records for a meaningful fraction of transactions — silently being the operative word, because nothing would have errored and the totals would simply have been wrong.

It is the kind of rule that looks arbitrary in a diff and obvious in a bug report, which is exactly why it has tests around it.

Decision 08

Score the header row rather than assume it

Net-banking exports do not agree on where a table starts. So CSV and Excel import detects the header by scoring candidate rows instead of assuming a fixed position — and where the source data is ambiguous about whether a row is a credit or a debit, a direction-inferred flag surfaces in the import preview so the user can check the inference before it is committed to the database.

Showing an inference as an inference is the honest version of automation. The alternative silently books a refund as a purchase and lets the user find it in a monthly total.

Decision 09

Audit dependency health as a first-class criterion

Maintenance activity, licence and single-maintainer risk are reviewed before a package is adopted, not after it fails. Two real problems were caught and replaced mid-build because of it.

SMS access moved off a package flagged as a maintenance risk and onto a small native bridge of my own — which also made room to normalise the registered sender IDs Indian banks send from, so an SMS can be reliably mapped back to its bank.

Database encryption moved off a fork flagged as poorly maintained and single-maintainer, onto an actively maintained encrypted store. For a security-sensitive dependency in an app whose entire promise is custody, a single-maintainer fork is a structural risk, not a convenience trade.

Document handling was likewise chosen after auditing alternatives, on licensing and active maintenance. Encryption keys live in the platform's hardware-backed key storage rather than in application code or plain preferences.

Decision 10

Open every phase with a review block, not with code

Each phase begins with a design review and issue-fixing block before implementation starts, on the theory that design problems are cheapest at the moment they are noticed and most expensive once something is built on top of them.

It works. The two dependency problems above were caught this way. So were two open items in the current phase — including a diagnosability gap where the model load path has no async acknowledgment, so a silent failure from memory pressure or a corrupt file produces no clear signal. On its own that is a minor annoyance. Once user-facing features sit on top of the load path it becomes an opaque bug class, which is precisely why it was worth naming before that happened rather than after.

Decision 11

Let the phone decide the next phase

The next phase has to choose how the model gets invoked as a fallback: inline, blocking the interface while it runs; on-demand, triggered explicitly by the user; or background-batch, queued and processed opportunistically. Those are three genuinely different products.

That decision is blocked on measurement, deliberately. It will be made from prefill and decode tokens per second and peak resident memory, measured on representative hardware — not estimated. Which is why the current phase is not considered complete until those benchmarks exist.

Guessing here is cheap and wrong. If decode is fast enough, inline is the best experience and everything else is over-engineering. If it is not, inline is unusable and shipping it would be the kind of mistake that gets discovered by users.