PHISHFINDER TO SUPRA
Synthetic instructional walkthrough — October 9, 2026

This instructional walkthrough shows PhishFinder and Supra using fictional training material.

You will see actual saved reporting outputs, a fresh local Rose analysis, and a fresh automatic redaction example.

The investigator forms come from separate synthetic rehearsals.

This is an edited walkthrough, not a recording of one integrated live case.

Start with the citizen’s own account.

Preserve the original wording and uploaded evidence.

Extracted information, a model interpretation, and a later correction should remain distinct.

This screen is from the saved local citizen demonstration.

The example describes a bank impersonator demanding gift cards and a reported loss of one hundred dollars.

Rose examines supplied text for patterns such as payment demands, account verification, code requests, suspicious link instructions, and urgency.

It considers context, including warnings and quoted demands.

In the inspected implementation, this is local pattern based analysis.

Rose is separate from the citizen page; that page does not currently invoke Rose.

I ran Rose on a fictional demand to buy gift cards immediately and read back the codes.

It returned suspicious, with medium confidence, and cited the gift card demand and urgency.

Rose does not establish identity, scan attachments for malware, recover funds, or guarantee an investigation.

No clear scam pattern would not mean a message is legitimate.

The citizen guidance should be short and practical.

Stop responding to the suspicious demand.

Contact the real institution using a trusted contact route, especially if money or credentials were shared.

Preserve the message and transaction records.

The guidance should explain remaining reporting steps without promising recovery.

Immediate danger requires emergency assistance, not waiting for an app response.

This is the actual downloaded IC3 preparation copy.

It contains synthetic complainant information, the reported loss, and the incident narrative.

The application labels it draft only, not submitted.

Required identifying details are not automatically removed from an official filing draft.

A separate share safe copy can mask them.

An actual agency confirmation is needed before showing submitted.

Here is the transaction and narrative at a larger scale.

The payment row and declared loss agree at one hundred dollars.

Agreement is an arithmetic check, not independent proof that a loss occurred.

Missing subject information remains missing.

IC3 does not accept supporting evidence attachments through its complaint process; preserve those originals separately.

The same reviewed account also supports a separate FTC preparation draft.

It records the impersonation category, phone contact, payment and description.

The saved output explicitly says that live conditional fields still need verification.

This is a preparation document, not an official FTC receipt, and it does not demonstrate automated filing.

I ran the shared local redactor on a synthetic statement.

It masked the name, date of birth, email, telephone and street address.

It retained the incident date and reported amount.

This result is a derivative, not a replacement for the original.

Pattern matching can miss sensitive material.

Documents, images, metadata and the final export still need review.

The before and after view shows exactly what this run changed.

The bracketed labels replace detected text; they do not encrypt the document.

Redaction and encryption solve different problems.

Official request forms can require victim information, so the redaction policy must be specific to the destination.

The unredacted original and any private mapping must stay access controlled.

Case evidence supplies people, identifiers, amounts and dates.

Retrieval augmented generation, or RAG, supplies relevant reference passages for guidance.

The checked worktree’s RAG database is empty, and I did not find the Fraud Examiners Manual in the scoped project folders.

We cannot label this a successful manual grounded generation.

The companion document identifies this gap explicitly.

For the separate fictional kiosk case, the source reports a twenty five hundred dollar payment and says the receipt and provider return are missing.

The guidance therefore prioritizes obtaining and comparing those records through an approved route.

It keeps account control and intent unresolved.

The companion includes source links at the bottom, suggested owners, completion checks and alternative branches.

This is the actual General Ocean County Prosecutor’s Office request draft from the kiosk rehearsal.

Its case number, victim fields, reported amount and records window come from reviewed synthetic material.

They do not come from the Fraud Examiners Manual.

The service destination is unverified, and the draft says do not serve.

No signature, issuance or transmission is implied.

At this larger scale, review the victim and subject roles, the event date, and the requested records window.

A records request should be narrow enough to address the actual evidence gap.

A kiosk network address might identify provider infrastructure rather than the offender.

The continuation page is included in the document package.

This is the second request type, the High Tech Crime Unit form.

It belongs to a different fictional case and is not a second outcome of the citizen example.

The rehearsal uses a labeled synthetic provider exhibit.

That does not verify a real provider relationship, subscriber, or service address.

Unknown and unverified information must not be filled by guessing.

The enlarged section shows the populated case details and requested records.

Each material value needs a trace back to the case source and review record.

Procedural references need their own passage and page links.

A general manual citation cannot establish a subscriber or authorize a request.

These are preparation aids for human assessment, not issued subpoenas.

The intended final package contains preserved originals, reviewable derivatives, guidance, request drafts and an integrity manifest.

Encryption requires approved key handling and recipient side verification.

Delivery to departmental email or Axon Evidence needs a verified authorized route.

This walkthrough does not send evidence, file agency reports, or demonstrate live Axon delivery.

You have now seen actual reporting and request documents, a fresh Rose result, and automatic redaction on synthetic text.

The companion includes full page copies, source records and evidence linked guidance.

The next acceptance step is one integrated browser rehearsal with a populated qualified RAG and independently reviewed outputs.

Nothing shown here establishes production readiness or a completed legal filing.