AEGI Shield Fraud Workflow: Browser-Verified Synthetic Execution and the Path to Controlled Evaluation

Engineering update · 17 October 2026. AEGI Shield has completed an internally verified, bounded synthetic Fraud review workflow across evidence generation, application-level verification, a staff browser review and audit export. This is a technical integration milestone, not evidence of a bank pilot, trained-model improvement, or production qualification.

One defined workflow: Fraud review reprioritisation

The reference workflow asks a narrow question: with the eligible population and investigator capacity held constant, can the system produce and preserve a reviewable comparison between a baseline queue and a proposed prioritisation?

1. Shield Fraud Context: processes a fixed set of 60 intentionally synthetic cases, applies a clearly illustrative priority rule and exports frozen rankings, context observations and hashes.
2. Core Fraud research verifier: checks the bounded evidence contract and independently recomputes the declared top-K metrics. A positive research-profile result is not normative Core qualification.
3. Ops staff application: receives the exact allowlisted evidence through an authenticated request, validates its binding and permits a staff reviewer to inspect scope, metrics and limits.
4. Review and audit: records Continue, Refine, Stop or Insufficient Evidence as an internal research recommendation, with actor, revision, event history and a digest-bound JSON export.

The browser exercise uses real loopback HTTP and Chromium against a separate Gunicorn process. The Core research module still executes within Ops; the test is not proof of an independently deployed multi-host Core service.

What was verified

At the integrated development commit verified on 17 October 2026, the recorded automated results were:

• 227/227 regression tests passing on SQLite and 227/227 on PostgreSQL;
• 31/31 checks for the real HTTP and Chromium synthetic-review walkthrough;
• 52/52 PostgreSQL socket-HTTP checks covering stale revisions, competing writers, duplicate refusal and rollback following an intentionally injected audit-write failure;
• successful Docker production-settings boundary smoke checks and disposable local walkthrough launcher.

These are developer-controlled engineering checks under stated test conditions. The counts are not a reliability percentage, third-party assurance, independent human acceptance, or a customer deployment result. The current reviewer export also contains a targeted fix that prevents a stale review payload from being paired with a newer audit history.

What the synthetic numbers do—and do not—mean

The illustrative fixed-capacity dataset contains 60 synthetic cases and uses K=10. Its baseline surfaces six synthetic positive cases in the top 10, while the demonstrator’s candidate surfaces ten: 6 → 10, ΔTP@10 = +4. The candidate’s prioritisation rule is deliberately constructed to illustrate the evidence pipeline; it is not a trained fraud scorer.

This result does not prove predictive uplift, Shared Credit–Fraud Context incremental value, real fraud prevented, improved financial outcomes or return on investment. It is separate from the public BAF-003 synthetic benchmark shown elsewhere on this site; the two studies are not interchangeable.

Current acceptance boundary

Available for a scoped technical discussion: a bounded internal synthetic walkthrough, with explicit limits on evidence ownership and claims. Not yet accepted: a production or customer-authorised pilot. Formal internal Gate A acceptance, independently qualified Core semantics, an actual Factory/model scorer, customer-owned evaluation inputs and the authorised Ops Run-to-final-Decision-Package lifecycle are separate work. Current synthetic-review access remains development-only; it is not a general-purpose customer data upload service.

How to request a Controlled Evaluation

A financial institution can begin by describing one workflow, one current baseline, one proposed change, and the decision it needs evidence for. AEGI can then assess the scope, whether comparable historical evidence and mature labels exist, the operating constraints, data custody, approval authority and stop criteria. No customer records are required for that first conversation, and prospective partners should not send confidential records, credentials or live data through the public contact channel.

The first useful external engagement may therefore be a feasibility and evaluation-scoping exercise, followed only by a separately approved historical or shadow evaluation if the required technical and institutional controls are met.

Explore the Controlled Evaluation process →

Request a Controlled Evaluation →

Scope note: synthetic research evidence only; not pilot acceptance, model-performance validation, Core G1 qualification, financial-institution approval or authorisation for production reliance.