Narrative Shield is Corvus Intelligence's AI-augmented StratCom decision support platform – a unified console for cognitive-domain operations covering the full strategic communications effects cycle. Unlike point tools that address only detection or only content generation, Narrative Shield is organized around three interlocking operational flows: a reactive flow for always-on threat monitoring, a proactive flow for planned influence operations, and an assessment flow for after-action analytics. This article walks through the technical architecture of each flow and the backend and frontend engineering decisions that support them.

The platform is built on .NET 8 / ASP.NET Core for the backend API, React 18 with TypeScript and Vite on the frontend, and integrates the Anthropic Claude API for all AI-augmented reasoning tasks. Deployment is Docker-based with a REST API conforming to OpenAPI 3, and the system integrates with OpenTAKServer for field delivery of approved StratCom products.

Reactive flow: always-on narrative monitoring pipeline

The reactive flow is the continuous monitoring backbone of Narrative Shield. It runs as a persistent background service in the .NET backend, polling configured signal sources on a configurable interval (default: 5 minutes) and passing each ingested signal through a multi-stage processing pipeline before surfacing qualified detections to the operator queue.

The pipeline stages are: ingestion and normalization, keyword taxonomy matching, 5-factor severity scoring, propagation chain graph construction, Course of Action generation, and operator queue insertion. Each stage is implemented as an independent service with a defined interface, allowing individual stages to be replaced or extended without affecting the rest of the pipeline.

The 5-factor severity scoring algorithm

Severity scoring is the core quantitative step in the reactive flow. Each detected narrative is evaluated against five independent dimensions:

Reach – the estimated audience exposed to the narrative at the time of detection, derived from account follower counts, cross-platform duplication, and estimated organic amplification rate. Reach is log-normalized to prevent large-follower accounts from dominating scores across all dimensions.

Velocity – the rate of propagation measured as the gradient of reach over the preceding 6-hour observation window. A narrative that has doubled its audience in two hours scores higher on velocity than one that has reached the same absolute audience over 48 hours. Velocity is the most reliable early-warning signal for coordinated inauthentic behavior.

Sentiment polarity – the degree of hostility or harm directed at the monitored entity, scored by the Claude API on a -1.0 to +1.0 scale with the polarity magnitude mapped to 0–100 for the severity contribution. The API prompt includes entity context so that ambiguous political language is evaluated against the specific monitored subject rather than generically.

Target audience alignment – how closely the narrative's observed distribution matches the demographic and psychographic profiles of the monitored entity's defined priority audiences. This factor uses the audience segment maps configured in the Audience Mapping panel and cross-references geographic distribution data from the ingestion layer.

Source credibility – a composite authority score for the originating and top amplifying accounts, drawn from the Source Registry maintained by operators and updated continuously from behavioral signals. Accounts with established histories of coordinated inauthentic behavior receive negative credibility adjustments.

The five dimension scores are combined into a single 0–100 severity index using per-topic configurable weights. By default, weights are equal (0.2 per factor). Topic administrators can adjust weights through the Scoring Configuration panel; a force-protection topic, for example, might upweight target audience alignment and source credibility, while a strategic-level narrative topic might upweight reach and velocity.

Key insight: The 5-factor model is intentionally decomposed rather than monolithic. Operators who question a severity score can inspect each factor independently and understand exactly which dimensions drove the assessment – this transparency is a prerequisite for human oversight at decision points, and it satisfies the NATO AI principle of explainability at the evidence level, not just the conclusion level.

Propagation chain graph construction with cytoscape.js

Once a narrative clears the severity threshold, the reactive flow constructs a propagation chain graph to visualize how the content has spread from originating sources through amplifier networks to reach audiences. The graph is rendered in the frontend using Cytoscape.js, chosen for its performance with large sparse graphs and its support for custom layout algorithms suited to directed information-flow visualizations.

Graph construction begins with the seed nodes from the Source Registry: known adversary accounts and coordination clusters associated with the watch topic. The ingestion layer's relationship data – reply chains, repost trees, cross-platform co-posting patterns – is used to expand the graph outward from seed nodes, connecting intermediate amplifiers and terminal audience nodes. Edge weights encode the volume of content flowing between nodes and the temporal sequence of propagation steps.

The resulting graph serves two operational purposes. For the reactive flow, it helps operators identify the network topology of the detected campaign – whether content originated from a small coordinated cluster or emerged organically, and which amplifier nodes are structurally critical to the propagation chain. For the assessment flow, the same graph structure becomes the basis for measuring whether counter-narrative actions actually disrupted propagation, by comparing pre- and post-action graph topology metrics.

Course of action generation via claude API

For detections that exceed the alerting threshold, the reactive flow automatically generates three structured Courses of Action (CoAs) using the Claude API. Each CoA is a structured object containing: a recommended action type (counter-narrative publication, source attribution challenge, platform abuse reporting, key leader engagement, silence/wait), a brief rationale with explicit reasoning chain, predicted counter-reaction from adversary actors, escalation risk score, and attribution risk score where applicable.

Generating three CoAs rather than one recommendation is a deliberate design decision: it preserves operator agency by presenting the decision space rather than collapsing it to a single AI recommendation. The reasoning traces are surfaced in the operator UI alongside each CoA, not hidden behind the output. Operators can expand the trace to see the Claude API's chain-of-thought reasoning before accepting or rejecting a course of action.

Key insight: No CoA-derived action is ever disseminated without explicit operator approval. The platform enforces this at the API layer – the dissemination endpoint requires a signed approval token that can only be generated through the operator approval workflow. The architectural constraint is not advisory; it is enforced in code.

Proactive flow: audience segment mapping and campaign generation

Where the reactive flow responds to detected threats, the proactive flow is operator-initiated: given a defined communications objective, it generates a structured campaign plan with multiple variants and predicted cognitive effects. The proactive flow is appropriate for planned information activities – supporting a public affairs release, pre-positioning counter-narratives ahead of an anticipated adversary operation, or coordinating allied messaging across multiple government channels.

The proactive flow begins with audience segment mapping. Operators define target segments using the Leaflet / OpenStreetMap geospatial interface – drawing geographic boundaries on a map, selecting applicable demographic and psychographic profiles from the segment library, and tagging language and cultural context attributes. The segment definition drives both the campaign generation and the content adaptation steps that follow.

Campaign variant generation is handled by the Claude API against a structured prompt template that includes the communications objective, the defined audience segment, the current narrative environment (drawn from the reactive flow's active detections for the relevant watch topics), and any operator-specified constraints (content restrictions, approved messaging themes, prohibited claims). The API generates three campaign variants, each with a distinct primary framing, a set of supporting talking points, and predicted cognitive effects broken down by audience sub-segment.

The predicted cognitive effects model draws on the audience segment profiles to estimate how different framings are likely to be received by different sub-populations – not as a precise predictive model, but as a structured reasoning output that operators can evaluate and interrogate. The predictions are clearly labeled as AI-generated assessments, not empirical forecasts.

Content adaptation produces audience-targeted draft content in three register variants for each campaign: general public (accessible language, emotional framing appropriate to the audience profile), media (factual, quotable, structured for journalistic use), and allied governments (formal, precise, aligned with diplomatic conventions). All draft content is held in the operator review queue and requires explicit approval before any downstream delivery.

Assessment flow: engagement correlation and after-action analytics

The assessment flow closes the effects cycle by measuring whether StratCom actions actually achieved their intended cognitive effects. It is the component most commonly absent from information operations tooling – platforms that generate content rarely provide rigorous mechanisms for measuring what that content accomplished.

Engagement correlation is the primary measurement mechanism. For each approved and disseminated StratCom product, the assessment flow tracks engagement signals (reach, sentiment response, counter-amplification, secondary sharing) and correlates them against the propagation graph metrics of the target narrative. The correlation engine compares narrative-share – the proportion of total audience discussion captured by the monitored narrative versus counter-narratives – before and after the intervention, controlling for baseline trend.

Narrative-share tracking is implemented as a time-series metric stored per watch topic, updated on each polling cycle by the reactive flow pipeline. The assessment dashboard visualizes narrative-share as a trend line, with intervention timestamps overlaid so operators can identify which actions correlated with share shifts. The correlation is observational, not causal – the platform does not claim that a counter-narrative caused a narrative-share reduction, only that the correlation existed within the measurement window.

Key insight: Outcome data from the assessment flow feeds back to the reactive flow's scoring models through Narrative Shield's closed-loop learning mechanism. When an intervention successfully reduced narrative-share for a specific adversary source cluster, that outcome adjusts the source credibility scores for those nodes in subsequent detections – the system learns from operational experience in a traceable, auditable way, not through opaque model fine-tuning.

.NET 8 backend API design

The backend is organized as an ASP.NET Core Web API with a modular service architecture. The three operational flows are implemented as independent background services registered with the .NET generic host, sharing a common data access layer but operating on separate queues and state stores. This separation means a delay or failure in the proactive flow's campaign generation does not block the reactive flow's detection pipeline.

The REST API conforms to OpenAPI 3 and is documented via Swashbuckle. Every endpoint is typed end-to-end – request and response models are shared between the backend and the React frontend via a generated TypeScript client, eliminating the class of integration bugs caused by schema drift between API server and consumer. The API is authenticated via JWT bearer tokens with role-based access control enforced at the controller level.

The decision log – the immutable record of every AI-generated output, operator action, approval, and dissemination – is implemented as an append-only table. Write operations to the decision log use optimistic concurrency to prevent duplicate entries under concurrent writes, and reads are paginated and indexed by watch topic, operator, and timestamp for efficient after-action retrieval.

React 18 frontend with TypeScript

The frontend is a React 18 single-page application built with Vite and TypeScript, styled with Tailwind CSS. State management uses React Query for server state (detection queues, assessment data, campaign variants) and React context for UI state (selected watch topic, active panel). The architecture avoids a global client-side store for server data – React Query's cache invalidation and background refetch behavior is better suited to the polling-heavy nature of the reactive flow than a manual Zustand or Redux store would be.

Cytoscape.js graph rendering is isolated in a dedicated component with a custom React wrapper that manages graph initialization, data updates, and layout recalculation outside React's render cycle – Cytoscape.js mutates a canvas element directly, and reconciling that with React's virtual DOM requires careful boundary management. Layout recalculation is debounced and performed off the main thread where browser support permits.

The Leaflet geospatial component follows the same pattern: initialized once, updated imperatively via refs, and wrapped in a React component that exposes a declarative interface for setting the displayed segment boundaries and overlaying narrative-distribution heat maps.

OpenTAKServer integration for field delivery

Approved StratCom products are delivered to field units via an OpenTAKServer integration. When an operator approves a dissemination action, the backend posts a CoT (Cursor on Target) mission package to the configured OpenTAKServer instance via its REST API. Field units running TAK-compatible applications receive the package on their devices without requiring a separate communication channel or manual relay from the StratCom team.

The integration is configured in the Narrative Shield administration panel: operators specify the OpenTAKServer endpoint, authentication credentials, and the TAK groups that should receive packages for each watch topic. Package content is formatted as structured text suited to field display – not raw intelligence reporting, but operator-approved talking points and situational summary in a format appropriate for the tactical audience.

For a broader discussion of how defense software handles mission-critical architecture constraints, including fault tolerance and degraded-mode operation, see our architecture overview. The CI/CD pipeline considerations for defense software article covers the build and deployment discipline that underpins Narrative Shield's release process.

How to configure a new narrative watch topic in narrative shield

The following steps walk through the complete configuration of a new watch topic, from initial taxonomy definition through first operational period after-action review.

Step 1: Define the watch topic and keyword taxonomy. Navigate to Administration > Watch Topics and create a new topic. Enter a descriptive label and build the keyword taxonomy covering primary terms, related phrases, and known adversary hashtags. The taxonomy supports Boolean operators and wildcard matching. Start broad and tighten based on the first 48 hours of scored results.

Step 2: Configure severity scoring weights for this topic. Open the topic's Scoring Configuration panel. Adjust the five factor weight sliders to reflect operational priorities. Weight changes take effect on subsequent scoring runs and do not retroactively rescore historical detections.

Step 3: Set the severity threshold for operator alerting. In the Alerting panel, set the severity index threshold above which a detection triggers immediate operator notification. The default threshold of 65/100 suits most topics. Configure the notification channel and duty officer assignment for this watch topic.

Step 4: Seed the propagation graph with known source accounts. Add known adversary accounts, amplifier networks, and coordination clusters to the topic's Source Registry. These seed nodes initialize the Cytoscape.js propagation graph when a new detection occurs. The registry accepts direct account identifiers and can be bulk-imported via CSV.

Step 5: Map the target audience segment for this topic. Open the Audience Mapping panel, draw a geographic boundary on the Leaflet map, select applicable demographic and psychographic profiles, and tag the segment to the watch topic. This segment definition is used by both the reactive flow (target audience alignment scoring) and the proactive flow (campaign variant generation).

Step 6: Activate the topic and validate with a test detection. Set the topic status to Active. Use the Test Injection tool to submit a synthetic signal matching your keyword taxonomy, confirm the propagation graph initializes correctly, and verify that an alert fires if the synthetic severity score exceeds your configured threshold.

Step 7: Review after-action analytics after the first operational period. After 24–72 hours of live operation, open the Assessment dashboard for this topic. Review engagement correlation charts, examine false-positive rates, and adjust taxonomy or thresholds accordingly. Export the after-action report and feed findings back to the watch topic configuration to improve future scoring accuracy.

Frequently asked questions

+What is the difference between Narrative Shield's reactive and proactive flows?

The reactive flow is always-on monitoring: it ingests signals, scores detected narratives against a 5-factor severity model, constructs propagation chain graphs, and generates structured Courses of Action for a human operator to review. The proactive flow is operator-initiated: given a communications objective, it maps target audience segments geospatially, generates multiple campaign variants with predicted cognitive effects, and produces audience-adapted draft content – all before any threat has materialized.

+How does the 5-factor severity scoring algorithm work?

Each detected narrative is scored on five independent dimensions: reach (estimated audience exposed), velocity (rate of propagation across platforms and time), sentiment polarity (degree of hostility or harm to the monitored entity), target audience alignment (how well the narrative matches known adversary target populations), and source credibility (authority score of originating and amplifying accounts). The five dimension scores are weighted and combined into a single 0–100 severity index. Weights are configurable per watch topic to reflect operational priorities.

+Does Narrative Shield replace human StratCom officers?

No. Narrative Shield is designed explicitly around human oversight at every decision point. The platform generates Courses of Action and draft content, but no output is disseminated without operator approval. Every AI-generated output is accompanied by a visible reasoning trace so operators can evaluate the underlying logic, not just the conclusion. Decision timestamps and approval records are written to an immutable audit log.

+How does the OpenTAKServer integration work?

Narrative Shield exposes a webhook endpoint that sends approved StratCom products – situation summaries, counter-narrative talking points, and guidance updates – to an OpenTAKServer instance as CoT (Cursor on Target) mission packages. Field units receive these products on their TAK devices without requiring a separate communications channel or manual relay. The integration uses the standard OpenTAKServer REST API and is configured via the Narrative Shield administration panel.

+What compliance framework does Narrative Shield follow for AI use?

Narrative Shield is designed to comply with NATO's AI principles: human control at every decision point, transparency of reasoning (all Claude API outputs include visible chain-of-thought traces), reliability through deterministic scoring pipelines that do not vary output for the same input, security through audit logging of all actions and approvals, and accountability through complete decision provenance from signal ingestion to approved dissemination.

Related reading: For the foundational architecture concepts underlying Narrative Shield's backend, see Mission-Critical Software Architecture for Defense. The deployment and pipeline engineering behind this class of platform is covered in Building a Hardened CI/CD Pipeline for Defense Software. For context on the broader vendor selection considerations when procuring StratCom or cognitive-defense platforms, see How to Choose a Defense Software Development Vendor.