Analyst workflow

This guide walks an analyst through a typical day on the platform: review the queue, work cases, prepare enforcement, and watch for resurrection. It assumes you have an analyst role in your organization.

Your home: the dashboard

Your starting point is /dashboard. The headline tiles show:

• Action required — cases assigned to you or to your team awaiting review.
• Pending client approval — cases sent to clients, waiting for their decision.
• Verification due — cases where the next 4-hour check is scheduled or overdue.
• Watchlist alerts — new updates on monitored domains.
• Recent enforcement — submissions in flight and provider responses.

All tiles label their data source. If something says imported, that is migrated v1 data. If something says unavailable, the underlying provider or database is unreachable — flag it; do not work around it.

Triage: the threat feed

Open /dashboard/threat-feed. Filter by client, brand, source, issue type, platform, status, activity, priority, assignee, date, SLA, queue, or tags. The threat feed is the consolidated intake queue: new manual submissions, scan results, watchlist changes, and API ingestions land here.

For each row:

1. Open the case. The detail page shows the URL, screenshots (desktop + mobile), DNS / WHOIS / RDAP / SSL / redirect / HTML evidence, and any notes or tags already attached.
2. Confirm classification. The Classification Run shows the confidence score, label, and sub-scores (visual, NLP, domain, evidence). If you disagree, override with a reason — that override becomes training feedback.
3. Set priority. Priority is an analyst judgment combining client policy, threat severity, and SLA risk.
4. Add notes if needed. Notes are typed (analyst, client, system) and audited.
5. Decide the next step:
   • Dismiss if the case is not actionable. Choose a reason: whitelist, irrelevant, duplicate, false positive.
   • Watch if the domain is dormant or in setup. Adds it to watchlist; future updates re-trigger triage.
   • Send to client approval if client policy requires authorization before enforcement.
   • Progress to enforcement if you have authority and confidence is sufficient.

Sending a case for client approval

When a client policy requires human authorization:

1. From the case detail, click Send for client approval.
2. Select the brand and reviewer scope (some clients have brand-specific approvers).
3. Add an optional note for the reviewer with your recommendation.
4. Submit. The case status moves to pending with activity client_review.
5. The client reviewer receives a notification (in-app, email, or Slack depending on their preferences) and works it in their portal.
6. When they decide, you get a notification and the workflow resumes:
   • Approved → case ready for enforcement prep.
   • Rejected → case dismissed with the reason captured.
   • Request more information → case on hold; back-and-forth via comments.

Preparing and submitting enforcement

From a case ready for enforcement:

1. Click Create enforcement on the case detail, or bulk-select compatible cases from the threat feed and choose Create from selected. Cases bundled together must share provider/platform.
2. Step 1: confirm context. Client, report type, issue type, brand.
3. Step 2: select cases to include in this enforcement (one or many).
4. Step 3: complete the channel form.
   • CleanDNS: reporter identity, rights owner, related trademarks, content URLs, description, screenshots.
   • Social (Meta / X): platform, form type, content URLs, evidence files.
   • Registrar / host: abuse contact, registrar policy, attached evidence.
   • XARF email: reporter, sender, schema fields, evidence references.
5. LLM-assisted draft (where available): the platform pre-fills the description from case evidence and client policy. Edit as needed; you own the final wording.
6. Submit. Status moves to submitted. A workflow run is created in Temporal; provider submission, response polling, and verification scheduling are now durable — if a provider rate-limits or times out, the workflow retries.
7. Watch the activity stream. Provider receipts (received_request), action confirmations (actioned_request / partial_action / rejected_request), and verification check results all appear in the case timeline.

Verification and closure

Active enforcement cases automatically schedule verification checks every four hours by default. Each check tries DNS, HTTP, visual, provider status, and blocklist queries.

You will work verification when:

• A check returns inconclusive or failed and needs a human read.
• A provider response says partial_action and you must decide whether to re-submit, escalate, or accept.
• The threat is down for several consecutive checks and you can close the case.

To close: open the case, choose Close → pick a reason (content_removed, case_successfully_suspended, platform_denied_request, platform_unresponsive, insufficient_information, etc.), confirm. The case moves to closed. A 30-day resurrection monitor starts automatically.

If the threat reappears within the resurrection window, the case reopens or a linked follow-up is created depending on your client's policy. You will see it in the threat feed with activity reopened or enriching.

Watchlist and whitelist

For domains that are dormant, in setup, or known-safe:

• Watch a domain to monitor it without creating a case. Watchlist tracks DNS, subdomains, status code, WHOIS, availability, screenshots. Updates flow into the watchlist feed and you can promote them to cases when content appears.
• Whitelist suppresses an exact URL, domain, email, or entity from creating cases. Used for partner-owned assets, known testing infrastructure, and confirmed false positives.

Reports and intelligence

/dashboard/reports lists scheduled and on-demand reports. Most are configured at the client level; you can run a one-off report against a date range, client, brand, or issue type.

/dashboard/intelligence clusters cases by shared infrastructure (IP, ASN, registrar, host, SSL issuer, redirect chains, scripts). Use it to spot campaigns and recommend pre-emptive watchlisting.

Tips for working efficiently

• Filter then bulk-act. The threat feed supports bulk dismiss, bulk watchlist, and bulk-create-enforcement when cases share provider.
• Use tags for queues. Tagging lets you build saved filters that match how your team actually divides work.
• Trust the source labels. A live tile is current. An imported tile is migrated v1 data. An unavailable tile means a real problem — escalate, don't ignore.
• Override with reasons. Every analyst override on classification, dismissal, or escalation feeds the model evaluation pipeline. Be specific.