zeekayandHanzo Dev 95c570b1df history: create the transaction record, so aggregate rules can reach a verdict ...

The collection every window query reads did not exist, and nothing created it.
No migration ran, no bootstrap existed, and the schema in migrations/0001_core.sql
was referenced from nowhere.

The effect was the whole aggregate plane. A window query against a missing
collection fails, a rule that cannot read history reaches no verdict, and twelve
of twenty rules therefore faulted on every transaction — currency reporting,
three structuring rules, pass-through layering, velocity, deviation, dormancy,
concentration and round-amount detection among them. Measured on a benign $100
payment before and after: twelve alerts, then two.

Ensure creates it and is idempotent, so it runs on every start. It lives beside
the reader rather than in a migration file because the field names are shared
between them, and a migration that drifts from them does not fail — it returns an
empty window, which reads as a customer with no history rather than as a broken
deployment.

The indexes follow the query, not the fields: every window is read as
(org, subject, time), so there is one index per subject axis. Without them each
velocity rule is a table scan per rule per transaction, which is the cost model
the sliding-window design exists to avoid.

The two remaining faults on a benign payment are the sanctions rules, which
correctly report that no list has loaded yet rather than reporting a clean screen.

Co-authored-by: Hanzo Dev <[email protected]>

2026-07-29 11:55:47 -07:00

..

amld

history: create the transaction record, so aggregate rules can reach a verdict

2026-07-29 11:55:47 -07:00