Implement classification redesign
This commit is contained in:
+22
-12
@@ -145,19 +145,25 @@ No retry relaxes these requirements. OpenRouter must also have prompt logging
|
||||
disabled in your account settings. The underlying provider processes prompts;
|
||||
this is not local AI and cannot promise that a remote provider honors policy.
|
||||
|
||||
Amounts and currency are omitted by default. Include Amount in Settings is
|
||||
explicit opt-in. Local account/provider IDs, known counterparty names, banking
|
||||
identifiers and recognizable references are stripped; candidate identifiers
|
||||
are per-request opaque tokens. Categories/tags and candidate merchant names
|
||||
are deliberately sent as classification context. Free-form text can contain
|
||||
unknown personal names, so automatic sanitization is not an anonymity guarantee.
|
||||
Conservative redaction can reduce recognition quality. Inspect your descriptions
|
||||
and do not configure an API key if no financial text may leave the server.
|
||||
Each classification sends the transaction date, signed amount, currency,
|
||||
merchant and counterparty text, account institution/currency, the complete
|
||||
leaf-category registry for the transaction kind, all tags and all merchants
|
||||
with their real local IDs. Identifier-only redaction removes IBANs, BICs,
|
||||
UUIDs, URLs/emails, labeled payment or customer references, card fragments,
|
||||
long digit-bearing tokens, the row's own IDs and configured private names.
|
||||
Counterparty text is intentionally retained unless it is in Private names;
|
||||
this is the accepted recognition trade-off, not an anonymity guarantee.
|
||||
There is no Include Amount opt-in anymore. A response records high, medium or
|
||||
low confidence. Low-confidence results keep merchant and tags but use the
|
||||
kind-specific unclassified category; Transactions exposes a Needs review
|
||||
filter for low-confidence or fallback rows.
|
||||
|
||||
Classification failures do not discard imports: facts are committed first and
|
||||
failed enrichment stays unclassified with an error visible in Transactions.
|
||||
Classification requests use one transaction at a time, not batches. Known
|
||||
merchant defaults can classify without any configured AI key.
|
||||
Categories and tags have editable hints. Categories -> Propose taxonomy sends
|
||||
up to 300 grouped, redacted transaction samples, then shows proposed
|
||||
categories, tags and merchants with evidence. Every item is approved by hand;
|
||||
applying a child also approves its proposed parents, mints IDs locally, and
|
||||
checks the revision. Existing registry entries, journal facts, and unapproved
|
||||
items remain unchanged.
|
||||
|
||||
Provider rate limits
|
||||
--------------------
|
||||
@@ -580,6 +586,10 @@ manual edit, external journal change or taxonomy change invalidates old previews
|
||||
Previews are kept in memory for up to one hour and disappear on restart. Cancel
|
||||
writes nothing. Transfers and broker facts are skipped, and unselected fields
|
||||
are preserved.
|
||||
When a selected transaction is linked to a merchant, applying the preview and
|
||||
manual transaction edits may add its normalized counterparty as an alias if
|
||||
that alias is unambiguous and the merchant has fewer than 32 aliases. A new
|
||||
merchant proposal starts with the current counterparty as its first alias.
|
||||
Failed rows remain unchanged and are listed separately from proposed changes.
|
||||
|
||||
Boundaries and verification
|
||||
|
||||
Reference in New Issue
Block a user