AEGI October 2026 Engineering Evidence: Synthetic Fraud Review and Recovery

Engineering evidence update · 28 October 2026. AEGI has advanced one bounded, internally controlled synthetic Fraud review workflow across Shield, a research-scope Core verifier and the Ops reviewer application. This note records what was integrated, what was tested, and the separate gates that remain open. It does not announce a bank pilot, production deployment or independently qualified assurance.

What has been integrated

The first implementation target is a fixed-population Fraud review reprioritisation workflow. A one-command internal demonstrator processes 60 intentionally synthetic cases through the existing Shield Fraud context contract and an illustrative—not trained—ranking rule. It freezes the baseline and candidate ordering, source and configuration identities, labels and declared metrics.

A separate Core Fraud I0 research entry point checks the bounded evidence contract and recomputes the claimed top-K counts and difference rather than accepting a supplied metric at face value. The Ops application then carries the evidence through an authenticated, staff-facing review path with an auditable decision record and handover. These Shield and Core changes were integrated into their respective main branches on 19 October 2026; the scoped Ops workflow was integrated on its release branch.

This path exercises evidence continuity and reviewer controls. It is not a trained fraud model, an empirical credit–fraud uplift result or a customer-authorised run.

Verified engineering checkpoints

• Shield: the integrated Fraud I0 demonstrator and R1 evidence handoff had passing post-merge CI on 19 October 2026. The bounded test suite included 260 tests and reproducible replay checks at the reviewed source.
• Core: the real, opt-in Fraud metric verification research profile merged to Core main with post-merge CI success. Its positive result is expressly limited to the declared research profile; normative Core G1 qualification remains open.
• Ops: the merged solo synthetic Fraud baseline and full-state recovery work passed 276 of 276 tests on SQLite and 276 of 276 on PostgreSQL, with 12 of 12 populated recovery checks at the merged source. The rehearsal covered the database, evidence files, private configuration and pinned Docker images. It did not establish production recovery objectives, bank acceptance or hosted customer operation.
• Offline review work in progress: a separate 27 October draft adds a restricted evidence review pack and standalone checker. At its exact draft head, the Fresh Fraud CI reported 280 tests passing on each database, and the related full-verification workflows succeeded. This is tested draft functionality, not a merged customer release or independent external audit.

What reviewers can examine conceptually

1. Scope identity: which fixed population, workflow, review capacity, policy, configuration and versions were evaluated.
2. Evidence binding: whether received artifacts match the recorded bytes and declared source package.
3. Metric recheck: whether a verifier independently recomputes the declared count from the allowed bounded inputs.
4. Human review trail: whether a staff review, revision and downstream handover remain linked to the same evidence snapshot.
5. Failure and recovery: whether stale, malformed or mismatched artifacts are rejected, and whether the local research workflow can recover its recorded state under the tested conditions.

The offline review pack is a further aid to constrained technical inspection; it does not authenticate the real-world truth of input labels or turn developer-controlled fixtures into independent evidence.

Evidence classes must remain separate

Engineering control evidence demonstrates the stated software behaviour under bounded synthetic tests. The separate BAF-003 public-synthetic benchmark measures a queue-composition difference under fixed review capacity. Neither answers the commercial question of what a proposed change would do in a bank’s own historical population.

That third question requires a separately approved institution-controlled evaluation with a documented baseline, permitted inputs, outcome basis, comparable capacity, controls and decision authority. A model or workflow should progress only when its evidence justifies the next approved stage.

Open qualification and customer gates

Formal Gate A acceptance, Core G1 normative qualification, an independently governed evidence examiner, a real Factory fraud scorer, customer-controlled data and evaluation authority, external production security/operational assurance and production authorisation are not established by these engineering runs. A separate experimental shadow-work-order branch remains unmerged and its CI startup checks were blocked; it is not part of this published capability statement.

Passing automated CI is evidence of reproducible engineering checks, not a bank’s model-validation decision, an external audit, a fraud-loss reduction result or regulatory endorsement.

For a prospective financial-institution partner

The useful next step is to choose one workflow, one current baseline, one proposed change and one decision question. AEGI can first discuss scope, feasibility, operational constraints and evidence expectations without requesting customer records. Any historical replay or later shadow stage requires separate institutional approval and lawful data arrangements.

Request a Controlled Evaluation · Review the evidence hierarchy · Read the earlier browser-verification note

Claim boundary: AEGI-conducted synthetic/internal engineering evidence. Not customer or production validation, independent Core qualification, independently authenticated source truth, predictive superiority, fraud-loss reduction or bank/authority endorsement. Implementation-stage states are tied to the cited dates and branches, not blanket readiness claims.