Alethea logo

How to evaluate a narrative intelligence platform

What this guide is for

If you're evaluating a narrative intelligence platform — for the first time, or as a refresh against a current vendor — this guide is the framework most procurement teams use. It covers the seven evaluation axes that differentiate vendors in this category, the RFP-style questions that surface meaningful capability differences, and the trial / POC structure that produces a defensible buying decision in 30 to 90 days.

This is a vendor-neutral structure. The named vendors in the category — Alethea, Blackbird. AI, Cyabra, Graphika, PeakMetrics, and adjacent vendors (Dataminr, Flashpoint, Recorded Future, NewsGuard) — each have different strengths against these axes. Structured evaluation surfaces which strengths matter for your specific buying context.

Step 1 — Establish the buying context

Narrative intelligence spans multiple personas with distinct buying contexts. The right evaluation criteria depend on which buying context drives the procurement.

Common buying contexts that trigger narrative-intelligence procurement:

Persona Buying context that triggered the search
CCO Reputational flare-up trending; viral disinformation about company or executive; coordinated boycott; AI-generated content impersonating the brand; regulatory motions intersecting with disinformation
CISO Coordinated disinformation campaign escalating; false breach rumors spreading; AI-generated deepfakes appearing; executive or brand impersonation in security contexts
CSO Named executive targeting; coded language evolving into mobilization; direct attack on peer-industry executive; specific incidents (doxxing, protest, geopolitical hostility)
Communications risk owner Has just been through a reputational flare-up; building a proactive monitoring layer before the next one; pilot / POC / business-case design after an incident
Security and threat lead Existing cyber tooling covers technical threats; build-vs-buy on a narrative-intel capability

Knowing which context drives the evaluation determines which capability axes weight heaviest. A CSO buying for online-to-offline escalation cares more about physical-security integration and source coverage on fringe channels. A CCO buying after a viral flare-up cares more about mitigation workflow integration and detection latency.

Step 2 — Score each vendor on seven evaluation axes

Axis 1 — Analytical anchor

Where does the platform's primary depth live?

  • Narrative-arc tracking (actors, content, propagation, targets)

  • Account-level inauthentic-behavior detection (bots, coordination scoring)

  • Image and media analysis (deepfakes, synthetic media classification)

  • Dark-web intelligence (cybercriminal forums, fringe channels)

Each vendor has a primary anchor and lighter coverage on the other axes.

RFP question: "Describe the primary analytical depth of your platform. Where is your strongest published case research? What's the framing of your most-cited product page?"

Axis 2 — Source coverage

Which platforms, forums, and channels does the vendor monitor? How publicly documented is the source list?

  • Mainstream social platforms (Twitter / X, Facebook, Instagram, LinkedIn, TikTok, YouTube, Reddit)

  • Fringe platforms (Telegram, Discord, Truth Social, Gab, Parler, 4chan, Substack, Bluesky)

  • Dark web and cybercriminal forums

  • Encrypted-channel observables

  • News and broadcast media

  • Multi-language coverage

Some vendors publish named platform lists; others operate under platform NDAs and publish coverage in qualitative terms.

RFP question: "Provide your source coverage statement. Which platforms are named in your public material? Which platforms are covered under data-sharing agreements? Provide coverage for the specific platforms most relevant to our buying context."

Axis 3 — Attribution depth

How does the platform attribute coordinated activity to actors? What's published?

  • Published case studies on named operations (Doppelgänger, Storm-1516, PromptPasta, IRA-linked operations, etc.)

  • Coordination signatures used (account-age clustering, posting timing, narrative-template repetition, network-graph analysis, off-platform coordination evidence)

  • Attribution-confidence framing (moderate / high confidence; named threat-actor groups; aligned-with-but-not-confirmed framings)

  • Multi-language attribution capability

RFP question: "Provide three to five published case studies demonstrating attribution depth. For each, describe the coordination signatures that anchored the attribution, the confidence level, and the operational use of the attribution."

Axis 4 — Mitigation workflow

How does the platform handle the response after detection?

  • In-platform mitigation engine (agentic takedown drafting, holding-statement generation, response plan building)

  • Analyst-services tier separate from the platform

  • Detection-and-reporting only (mitigation handled by customer or external partners)

  • Integration with the customer's existing incident-management workflow

Vendors that publish integrated mitigation tend to fit buyers with thin in-house response capability. Vendors that publish detection-only fit buyers with mature internal response functions.

RFP question: "Describe the operational mitigation workflow your platform supports. Is it inside the platform, in a separate analyst-services tier, or out of scope? Provide a worked example of a coordinated attack response from first signal through resolution."

Axis 5 — Deepfake and synthetic media detection

How is deepfake detection handled?

  • In-platform classifiers (vendor builds detection capability internally)

  • Partnership integration with a specialist (e.g., Reality Defender)

  • Out of scope (vendor doesn't claim deepfake detection capability)

Buyers expecting AI-generated content to be a recurring threat shape weight this axis heavily.

RFP question: "Describe deepfake and synthetic-media detection capability. In-platform, partnership-integrated, or out of scope? What's the coverage across modalities (audio, video, image, text)?"

Axis 6 — Physical-security integration

Is the platform built to feed protective-intelligence workflows?

  • Dedicated CSO / executive-protection solution content

  • Online-to-offline escalation workflows (narrative signals to physical-threat indicators)

  • Integration with protective-intelligence tools (Ontic, Everbridge, Dataminr handoff patterns)

  • Coverage of specific physical-security use cases (executive doxxing, protest coordination, facility threats)

This axis matters most for CSO-led procurement.

RFP question: "Describe physical-security and executive-protection integration. Do you publish dedicated CSO solution content? Do you support online-to-offline escalation workflows? Do you integrate with named protective-intelligence platforms?"

Axis 7 — Integration ecosystem

What's published for procurement-grade integration?

  • Public API documentation

  • Named SIEM / SOAR / TIP connectors (Splunk, Sentinel, ServiceNow SIR, QRadar)

  • Comms-stack integrations (Slack, Microsoft Teams, Cision, Muck Rack)

  • Legal-workflow integrations (DocuSign, Ironclad, legal-defensibility evidence packages)

  • Identity and access management (SSO, SAML, role-based access)

  • Data residency and retention controls

RFP question: "Provide the published list of named integrations. For each, link to the public documentation."

Step 3 — Run the RFP

A typical RFP for narrative intelligence has three sections:

Section A — Capability mapping

The vendor provides specific responses against each of the seven evaluation axes, with named published material as evidence. Buyers should require responses to include public URLs and verifiable claims from public sources.

Section B — Buying-context fit

The vendor describes how their platform fits the specific buying context that drives the procurement, with reference to published case studies in the same industry, persona, or scenario shape.

Section C — Commercial structure

Pricing model (subscription tiers, analyst-services pricing, integration fees, support tiers), contract structure (MSA, DPA, SLA, term length, renewal terms), data retention and deletion posture, security and compliance posture (SOC 2, GDPR, regional data residency), and reference customers willing to take a call.

Step 4 — Run a structured POC (30 to 90 days)

The most defensible procurement decisions come from a POC that exercises the platform against real or representative buying-context scenarios.

Suggested 30/60/90-day POC structure

Days 1–30 — Detection and attribution baseline

  • Run the platform against historical scenarios the customer has already lived through. Compare the detection-and-attribution output to what the customer's team produced in real time.

  • Run the platform against active monitoring in the customer's specific buying context. Score the platform on signal-to-noise, false-positive handling, and evidence-package quality.

Days 31–60 — Mitigation workflow integration

  • For at least one detected scenario, exercise the mitigation workflow end-to-end. Score the platform on takedown evidence-package quality, holding-statement options, response-plan operational usability, analyst engagement quality through execution.

  • Test the integration ecosystem against the customer's existing comms / security / legal tools.

Days 61–90 — Production-readiness assessment

  • Run the platform alongside the customer's existing tools in production.

  • Build the business case: what did the platform surface that would have been missed; what response did the platform enable that would have been slower or weaker; what's the total cost of ownership relative to the value delivered.

What to look for during the POC

  • Vendor responsiveness to specific scenarios beyond demo material

  • Quality of analyst engagement when the platform surfaces something the customer's team hadn't seen

  • Evidence-package quality for legal and regulatory review

  • Integration onboarding time relative to the published estimates

  • Roadmap commitments for capability gaps surfaced during the POC

Step 5 — Make the buying decision

A clean buying decision pairs the POC results with the evaluation-axis scoring against the original buying context. The decision artifact should include:

  • The original buying context that triggered the procurement

  • The weighted evaluation-axis scoring per vendor

  • The POC results scoring per vendor

  • The total-cost-of-ownership comparison

  • The reference-call summary per vendor

  • The recommended vendor with the explicit rationale tied to the buying context

Common procurement pitfalls

  • Anchoring the evaluation on demo theater. Demo material is built to showcase strengths; structured POCs against the customer's real scenarios produce a more defensible decision.

  • Weighting all seven axes equally. The buying context determines which axes weight heaviest.

  • Ignoring the response-workflow architecture. Two platforms can score similarly on detection capability and diverge sharply on what the customer's team has to do after the alert.

  • Underestimating procurement-grade documentation. API documentation, named integrations, and security posture material matter for the deployment-readiness assessment.

  • Skipping reference calls. A 30-minute call with a customer in a similar buying context surfaces operational realities no RFP response captures.