Verifications

Fromenance is a communication provenance platform, and every customer question ends up as a submission with a verdict. This page is for the analyst who works the Submissions and Indicators screens and for the engineer who pulls the same data through the API.

By the end you will be able to read a submission end to end, override a verdict and know what that changes, and export indicators to your SIEM or takedown vendor.

Submissions list

Admin app: Submissions. API: GET /v1/submissions (scope read), cursor paginated with cursor and limit, returning { data, next_cursor }.

Filter	Values
outcome	verified, not_verified, known_fraud (an override counts as its override outcome)
entry	forward, web, api
replay	true or false
has_headers	true when the customer forwarded as an attachment and original headers were present
from, to	ISO 8601 bounds on received_at

Each row carries entry, status, received_at, processed_at, count (how many times the same customer sent the same message), verify_code_found, submitter_hash, recipient_hash_found, headers_present, dkim, arc, trust (dkim:northfieldbank.example on the forward path), from_domain, imitated_template_id (the nearest registered template by fingerprint on Not verified), campaign_id, sandbox, the verdict, and any override. Global search in the top bar finds submissions by code, address hash, domain, or indicator.

Submission detail

Admin app: click a row to open the detail drawer. API: GET /v1/submissions/{id} adds:

• subject and preview_text: the forwarded message as plain text with every link replaced by its bare domain. The admin app renders this as a preview with links disabled; nothing in it is clickable and no remote content loads.
• headers_summary: the Received chain, DKIM, ARC, SPF, and trust results.
• indicators: each with kind, value, on_fraud_list, and submission_count across your tenant, with one click Add to fraud list.
• raw_available: whether the raw MIME is still within retention. Download raw (GET /v1/submissions/{id}/raw) is limited to analysts, admins, and owners, and every download is written to the audit log.

Verdict and signals

The verdict block shows the outcome, the rule that produced it, replay, authoritative, and the matched registration (communication_id, sent_at, template_id) when there is one. signals explains the rule: code_found, recipient_match, fingerprint_distance, headers_present, dkim. Rules are listed in Concepts.

Two things to look at first on a Not verified: whether code_found is true (a replay or a coverage gap on the matched template) and imitated_template_id (which of your templates the lure copies).

Overrides

Analysts, admins, and owners can override any verdict. Admin app: Override in the detail drawer with a note. API: POST /v1/submissions/{id}/override with { "outcome": "fraud" | "legitimate", "note": "..." }.

Override	What changes
fraud	The verdict shows Known fraud. Every indicator on the submission is added to the fraud list, and its fingerprint is recorded so later submissions with the same content resolve to Known fraud by fraud_list:fingerprint without a lookup. Overriding a Verified verdict to fraud is treated as an incident and alerts Fromenance operations
legitimate	The verdict shows Verified. A registration is created retroactively (retro: true) for the matched recipient and fingerprint, and a coverage gap is flagged on the source that should have registered it

Overrides are recorded on the verdict (override.outcome, by, at, note) and in the audit log. The original outcome and rule are kept.

Indicators

Admin app: Indicators, grouped by kind with first and last seen, submission count, priority, and fraud list status, with bulk Add to fraud list. API: GET /v1/indicators with filters kind (url, domain, email, phone, ip), q, on_fraud_list, since, priority (low, normal, high).

Indicators are extracted from every submission, including Verified ones at low priority, and skip your own domains. Replays raise the priority of their indicators to high. A new indicator on a non verified submission fires the indicator.new webhook.

Exports

Admin app: Export CSV or Export STIX on Indicators, and CSV on every table. API: GET /v1/indicators/export with the same filters and either Accept: text/csv or Accept: application/stix+json (or ?format=csv|stix).

• CSV columns: kind,value,first_seen,last_seen,submission_count,priority,on_fraud_list, served as an attachment named fromenance-indicators-<date>.csv.
• STIX 2.1: a bundle of indicator objects with STIX patterns ([url:value = '...'], [domain-name:value = '...'], [email-addr:value = '...'], [ipv4-addr:value = '...'], [x-phone-number:value = '...']), valid_from set to first seen, and labels carrying the kind and fraud list status. Import it into your TIP or SIEM as any other STIX feed.

Fraud list

Admin app: Fraud list. API: GET /v1/fraud-list, POST /v1/fraud-list with { "items": [ { "kind": "domain", "value": "northfield-secure-login.example", "note": "campaign 2026-09-12" } ] } (up to 500 per call), DELETE /v1/fraud-list/{id}.

Entries come only from analyst action: a manual add, or an override to fraud. Nothing is added automatically from a single submission, because anyone can forward anything through your rule, including attempts to poison the list. Each entry records source (analyst, campaign, feed), who added it, the note, and the submission it came from. A submission whose extracted indicators hit the list resolves to Known fraud by fraud_list:indicator before any other rule runs.

Overview numbers

The Overview screen and GET /v1/stats give daily counts of registered, submitted, by outcome, by entry, by source, replays, coverage gaps, code found rate, reply p95, and the top indicators of the week. Coverage per source is registered volume against the expected daily volume you set on the source or the tenant.