LedgerGuard

Architecture

A rules engine evaluates amount, velocity, region mismatch, and duplicate submissions over a seeded ledger. Scores are sums of triggered rule weights. Thresholds map scores onto allow, review, or hold. Manual actions append history. This is not a bank, not a detector, and not a compliance product.

Seeded transaction → rule evaluation → score → threshold class → optional reviewer action → audit trail.

Decisions

• — Compute the illustrative score only from triggered rules.
• — Keep threshold sliders as the policy that reclassifies eligible cases.
• — Require every status change to write a decision history row.

Trade-offs

• — Strict amount rules catch outliers and they inflate false positives on legitimate large purchases.
• — Manual review reduces automated harm and it adds operational latency.
• — Duplicate detection needs idempotency keys; missing keys look like new spend.

Failure modes

• — Lowering the hold threshold reclassifies more sample cases without changing rule evidence.
• — Approving a case does not clear the rules that originally fired.
• — Filters can hide held items from the queue without deleting them.

Evaluation

Queue counts and rule-trigger tallies are aggregations of the current sample set after the selected thresholds and actions.

Production extensions

Proposed — not implemented in this portfolio.

• — Replace static weights with a calibrated model behind the same explanation UI.
• — Stream authorizations from an event log with exactly-once decision keys.
• — Add maker-checker review and immutable audit export.