Working with Story.

What Story is

Story is the first always-on intelligence analyst for social, media and audience data. It operates against Pulsar's TRAC GraphQL API to interpret social, audience and narrative data.

You ask it questions in plain language; it queries your live Pulsar data, runs the analysis, and replies with a verdict, the evidence behind it, and the so-what for your work. What you get is a senior analyst's answer — verdict-first, comparative, calibrated, position-taking — delivered in seconds.

What Story is not

Who Story is for

• Marketing analysts and CMOs at consumer brands.
• Comms and reputation leads at corporate and agency teams.
• Insight teams running research for brand and agency clients.
• Strategists and planners shaping briefs and campaigns.
• Crisis and risk teams monitoring brand, executive, or category exposure.

Where Story sits in Pulsar

Story reads from the same data lake as your analysts. It operates against the TRAC GraphQL API and queries any search saved in the Pulsar platform. When you refer to "the brand," "the topic," or "the campaign," Story treats that as your analytical subject and looks up the matching search.

On 21 October 2026, Saga became Story and moved from private beta into public beta. Five months of private-beta use pushed it from one-off questions into daily stakeholder briefings, overnight monitoring and reports that go straight to senior teams. That work set the two tests this release had to pass: you should be able to leave it running overnight, and you should be able to check any quote it gives you.

2.1 · Why the name changed

Behind every spike, shift and share-of-voice swing there is a story: who started it, why it spread, and what it means for you. Finding that story and telling it clearly, with the evidence attached, is what this agent does. The name now says so.

The product is Pulsar Story. The agent is Story. Both replace every prior use of Saga.

2.2 · The model reasons. Code keeps the books.

Most agent failures are not reasoning failures. They are bookkeeping: date maths, recipient lists, filters, attribution and permissions. In this release none of that is left to the model, so its judgement goes where it counts — what matters, and why.

2.3 · Built to run without you

2.4 · More control, better outputs

2.5 · A fresh start: one thing to do by 28 October

These improvements apply to chats created from 28 September 2026. Chats set up before then were built on the earlier version, cannot fully benefit from the fixes, and account for most of the schedule failures seen during private beta.

Moving a brief across

Most briefs take a few minutes to bring across. If you run briefings for a wider team or for senior stakeholders, contact your account manager or support@pulsarplatform.com and the team will help move them.

2.6 · What's next

Public beta is where Story keeps improving in the open.

Three habits that separate good answers from average ones

Ten questions Story answers well

Each is a separate use case with its own lens. Replace bracketed terms with your brand, topic or campaign — then filter to find the one closest to your job.

How Story structures an answer

Every analytical response follows the same five-part shape. If a section adds nothing, Story drops it, but the order never changes.

1. Verdict — the headline finding in one sentence.
2. Evidence — the data behind the verdict; comparisons and a concrete example.
3. Hypotheses tested — for "why" questions, which candidate causes held up and which were rejected.
4. Worth a closer look — what you should have asked about but didn't.
5. So what — the strategic implication and what to do next.
6. Caveats — what the data can't tell you; where the sample is thin.

UI prompt filters — set scope without typing it

The Story chat UI lets you set search, timeframe and reply language as prompt filters in the composer, alongside your typed message. When set, they're passed to Story automatically. You don't need to repeat them in the prompt.

In practice, three ways to work:

• Filters only, short question. Set the search + date range + language in the composer; ask "Why did sentiment shift?" — Story has everything it needs.
• Chat only. Type all the scope in your prompt (the original behaviour). Story resolves each part from your message.
• Combine both. Filters carry the defaults; anything explicit in the message overrides. UI search + "last 7 days" in chat → the 7-day window wins over the UI date range.

A schedule is how a confirmed brief becomes something that keeps running. You approve the plan once; Story runs it on Pulsar's servers, on your clock, and delivers to the recipients you set. This is the difference between an assistant you have to open and an analyst that files to you.

4.1 · How a scheduled run works

• It runs server-side. Scheduled runs are independent of your browser and your login. Close the laptop and the 7am brief still lands at 7am.
• It runs against the stored plan, not the live chat. Thread, resource and context bindings are written onto the schedule when you create it. Later edits to the chat do not retro-fit the schedule — and a scheduled run cannot be derailed by whatever you typed last.
• A failed step retries; the run does not restart. Transient backend failures are retried in place, reusing valid state (resolved search IDs, built variables) rather than starting the analysis from scratch.
• Every run is logged. scheduled_run_started opens the timeline entry; step completions, search resolution and execution outcomes are recorded automatically server-side.

4.2 · Setting one up

4.3 · How the date window is computed

A schedule does not store dates. It stores the rule that produces them, and evaluates that rule at run time — which is what makes a 7am brief survive a clock change.

4.4 · Cadence limits in public beta

4.5 · Recipients & delivery

• Recipients are applied exactly as set, on every run. The agent never decides who gets the brief.
• Delivery goes through the Pulsar Notifications service, the same path as an interactive email dispatch.
• Changing the recipient list means telling the people joining or leaving it — Story does not notify them.

4.6 · What carries into every run

Everything you set is bound to the schedule and reapplied on each run, with no re-interpretation:

4.7 · Permissions on a scheduled run

A scheduled run carries your Pulsar permissions — your private searches, the folders shared with you, nothing beyond. A recipient who could not see a search in Pulsar can still receive a brief built from it, so treat the recipient list as a disclosure decision.

4.8 · Managing a schedule

Access is granted by account identity or by the chat's resource ID, so logging out and back in — or opening a different chat — does not lock you out of your own schedules.

4.9 · When a brief stops arriving

1. Check the chat's age. Chats created before 28 September 2026 were deleted on 28 October 2026, and their schedules with them. Recreate the brief in a new chat.
2. Read the schedule status. Paused and revoked schedules do not run. Check the last successful run time to see when it stopped.
3. Check the search still resolves. A deleted search, or one you lost membership of, will fail the run rather than quietly return nothing.
4. Re-authenticate, then recreate. If the stored token has expired, revoking and recreating the schedule after a fresh login is the supported fix.
5. Reproduce it in a new chat before reporting it. If the same brief works in a new chat, the schedule was the problem, not the agent.

These principles govern every analytical response Story produces. They are not stylistic preferences. They are the bar.

At least one of these is applied explicitly on every non-trivial analytical request. Most strong analyses combine two or three.

6.1 · The five lenses of a mention

Every mention carries five distinct dimensions. "Mentions are up" is one lens. "Mentions are up but engagement is flat" is two lenses and an insight.

6.2 · Macro / Meso / Micro

Strong analysis moves through at least two altitudes.

6.3 · Hypothesis-driven analysis

For any "why," "what caused," "what drove," "what's behind," or diagnostic question, Story switches from question-driven to hypothesis-driven analysis. Before running queries, it enumerates 3–5 plausible causes, tests each one, and reports which holds up.

The five candidate families

A great answer often rejects more hypotheses than it accepts. That discipline is the point — it shows what the answer is not, not just what it is.

6.4 · Audience intelligence

Story reasons about audiences as first-class analytical objects, not by-products of mention analysis. This is what makes Pulsar's audience-intelligence positioning defensible analytically.

Three ways to define an audience

Audience operations — as set objects

Cohort ≠ Segment ≠ Audience

6.5 · The Pulsar Virality Model

Pulsar's proprietary methodology for scoring, classifying, and predicting the trajectory of narratives. Applied whenever a question touches virality, trend prediction, breakout risk, or narrative emergence.

Lens A — seven metrics per narrative

Lens B — Visibility × Impressions archetype (±15 gap rule)

Both axes normalised 0–100. Compare narrative-median Visibility (internal conversation intensity) against narrative-median Impressions (cross-network reach). Classify by signed gap:

Pipeline behind the scores

The Pulsar Narrative Intelligence pipeline runs in six stages: INGEST → EMBED → CLUSTER → SCORE → LABEL → RENDER.

• Embed — TF-IDF + Truncated SVD, 150 dimensions.
• Cluster — UMAP → HDBSCAN (min cluster 100, min samples 20). Noise bucket preserved as its own narrative.
• Score — Virality (seven metrics) + V × I archetype computed per narrative.
• Label — LLM-judged narrative naming with vocabulary anchored to the cluster's actual posts.
• Render — .xlsx + HTML deliverables.

Story does not run this pipeline. It queries or computes against its outputs. Knowing the pipeline matters when a user asks why clusters look the way they do, why noise is preserved, or why two similar posts ended up in different narratives.

6.6 · Forecast & scenario discipline

The Virality Model classifies what has happened with implications for what is likely next. This section governs how Story expresses what is likely next.

6.7 · Data quality check

Pre-analysis smell test. Runs on every analytical request before interpretation. Six checks, three severity levels.

The six checks

1. Time-window continuity — any missing days in the window?
2. Sentiment sanity — is the distribution plausible for the topic and platform mix?
3. Language mix — does the language distribution match the market?
4. Author concentration — is more than 30% of volume coming from < 5 authors?
5. Volume vs history — is the window volume within reasonable multiples of the trailing 30-day median?
6. Platform mix — has the platform distribution shifted materially since the last comparable window?

Severity tiers

6.8 · The so-what test

If Story does not have a clean answer, the analysis is incomplete. Either deepen it or state explicitly that the question as posed has no strategic implication in the data.

Voice

• Comparative: lead with the comparison, not the absolute — "3× baseline" before "12,400 mentions."
• Change verbs: doubled, tripled, halved, collapsed, stalled, flipped, drifted, accelerated, decayed, plateaued, broke out, reversed. Never "increased," "decreased," "changed," "varied."
• Anchored: every abstraction has a concrete example — a post, an author, a paraphrased quote.
• Concise: no filler, no preamble, no flattery.
• Numbers: rounded to meaningful precision — "12,400" not "12,387"; "23%" not "22.7%"; "tripled" not "3.04×."

Integrity guardrails

Social and audience intelligence has specific risks. These apply regardless of how the question is phrased.

Aggregate, never individual

Aggregate patterns about authors are fair: "The conversation skews male, US-based, 25–34." Claims about specific individuals from their public posts are not: "This person is unhappy at work," "This person has mental health issues." Reporting what an author posted is fine; inferring who they are beyond what they have publicly stated is not.

Attribute, don't amplify

When summarising what posts say, attribute to the post, not to the world: "One post claims X", not "X is true." Misinformation in the dataset is reported as content, not amplified as fact.

The dataset is not the universe

Platform mix, language coverage, and geographic coverage shape every finding. Story names these limits when material. Platform-bounded discourse is never presented as "the public conversation" unless the platform mix justifies that claim.

Sensitive categories

Extra caution required when analysis touches children or minors (no profiling), health conditions, political affiliation, religious belief, sexual orientation, immigration status (all aggregate-only), and criminal allegations (attributed to claims, never asserted).

How Story's structure plays out on a single question.

Story detects intent as ANALYSIS. The diagnostic phrasing in "why." It resolves the search, builds variables for the current 7-day window and the prior 7-day baseline, runs a data-quality smell test, generates 3–5 candidate causes, executes the queries, and replies in this shape:

Six prompts written to use Story as an autonomous agent on the data lake — clustering raw conversation, tracing propagation, reasoning across steps. Each is reusable across brands. Replace placeholders in {CURLY_BRACES} before running. Default lookbacks are stated and can be overridden.

Click a prompt to expand and copy.

For engineers, customer success, and power users who need to know what is under the hood — to debug access issues, explain why an answer looks the way it does, and integrate Story into broader workflows.

10.1 · System overview

Story is a tool-using agent. Its loop is: classify the user's intent → route to the appropriate workflow → execute the minimum set of tool calls required → run the analytical frameworks against the returned data → respond in the verdict-first output structure.

Services it calls

• Data — the TRAC GraphQL API, where every mention, metric and audience attribute is read from.
• Search lookup — resolves a search title to its ID, and the reverse.
• Notifications — delivers email dispatches and scheduled briefings.

Authentication is handled inside the tools using a reader-scoped token; the LLM layer never sees credentials.

10.2 · Intent detection

Before any tool runs, Story classifies the request into one of seven intents. The intent determines which steps execute.

Disambiguation favours ANALYSIS by default when interpretation cues are present ("why," "how is," "what's happening," "should we"). A follow-up may change the intent; Story detects the change and adapts the target output while reusing compatible state (search IDs, resolved date ranges, valid variables).

10.3 · Tool surface

10.4 · Multi-model support

The architecture is model-agnostic — the same system prompt, tool surface and analytical contract run across any supported model, and users can switch mid-conversation with state preserved. Public beta ships a deliberately narrow line-up: the three Claude models that gave the most consistent results across private-beta workloads.

10.5 · Security & access model

Story enforces the same data-visibility rules as TRAC. A user only sees the searches their account can see; Story only retrieves what the user could have retrieved manually.

How access is enforced

• Feature flag — Domain + user-level flag controls whether Story appears at all. Without it, the launchpad tile and left-nav icon are hidden.
• Membership — If the Story product is enabled at the membership level, the lock on the launchpad item is removed. Without membership, the tile shows but is locked.
• Reader token — All API calls are made under a reader-scoped token tied to the user's team membership on the current domain. Elevated credentials are never passed to the LLM layer.
• Search visibility — Story inherits from TRAC. Private searches must have the user added explicitly; public searches are accessible to anyone on the domain.

Known constraints

• Cross-domain analysis is not supported in the current beta unless the user is a Superuser.
• All authentication errors surface as the explicit error returned by the API (HTTP 401, HTTP 403), with the failing search ID where applicable. Story does not silently fail.

10.6 · Output structure (technical)

Every response in DATA_RETRIEVAL or ANALYSIS intent has three structural elements in fixed order:

1. Narrative text — the prose response in the verdict-first structure.
2. Metadata block — exactly one fenced JSON code block (tagged metadata) containing the resolved search context (search ID, name, resolved date range, models used).
3. Chart block — at most one fenced JSON code block (tagged chart) containing the chartPayload from build-chart-series. Always last.

Charts use the Pulsar palette and follow Tufte rules: y-axis baseline at 0 on bar/column, no 3D, no gradients, the user's brand is always Pulsar Blue (#0068FD), the title is the insight (not the topic), and at least one annotation marks the point that justifies the title.

10.7 · Failure handling

Story classifies failures into five categories and recovers per category, never restarting from scratch when a valid state exists.

10.8 · Analysis workflow phases

When the intent is ANALYSIS, Story runs through four product phases in order. Each has its own allowed and forbidden tool calls. The UI enforces the transitions.

10.9 · The render-analysis-report tool

The final ANALYSIS deliverable is a structured payload — not markdown. Story passes six section types in a fixed order; the UI renders them.

The tool payload also carries a metadata object (intent, searchIds, searchNames, dateRange, modelUsed, chartCount) and up to four chartPayload objects in charts. Fenced ```metadata, ```chart or ```charts blocks in the assistant message are forbidden in EXECUTE — the UI reads charts from the tool result.

10.10 · Search resolution rules

Distinct from intent detection: how Story turns an entity or a title into a search ID.

Match outcomes

• 0 matches after entity + one broader retry — Story says no matching search was found and asks the user to pick one from their team. It does not claim "no data" or loop on more variants.
• 1 match — Story uses it in build-graphql-variables.
• > 1 matches — Story asks a single short clarifying question listing at most five options as "name (ID: N)".

10.11 · Content authorship & nested posts

When Story cites specific posts or attributes actions to accounts — especially on X / Twitter — attribution rules are non-negotiable.

• The author of a TracContent record is always userScreenName / userName on that record — never inferred from a brand name, keyword, or search title appearing in the text.
• A brand mention in a competitor or brand search does not mean that brand authored the post.
• For quote tweets, replies, retweets and reposts, Story checks subtype (ORIGINAL_POST / QUOTE / REPLY / RETWEET / REPOST) and quotedPostId / pulsarParentId. It models two layers: the account that published this record, and any quoted or replied-to content.
• If userScreenName or subtype is missing, Story does not assign specific text to any brand or user. It says authorship cannot be verified from retrieved fields, and retries the query once with the required selection set.

Citation format

10.12 · Server-automatic timeline events

Core workflow milestones are logged server-side; Story does not need to call log-context-event for them. The following events are automatic:

Supplemental events (call log-context-event)

• topic_updated — user changes scope or topic materially.
• analysis_plan_updated — draft plan revised before confirmation (when not via render-plan).
• analysis_scope_changed — confirmed analysis scope no longer compatible.
• heartbeat — reserved for future periodic checkpoints.

Current status

Story has been in public beta since 21 October 2026. It is an add-on to the Pulsar Platform, available to customers on request. Enablement is still two-layered: at the domain level (via product membership) and at the user level (via feature flag). A user who lacks either does not see Story in the launchpad or left navigation.

Getting it switched on

Speak to your account manager, or contact support@pulsarplatform.com. Domains are enabled through the product team and require both feature-flag activation and membership enablement — commercial terms are handled by the account team, not documented here.

Getting access

1. Confirm Story is enabled on your domain (your account manager can check).
2. Confirm your user account has the Story feature flag set.
3. Confirm your account has membership of any private searches you want Story to analyse.
4. Log in to the Pulsar domain; Story appears as a tile in the launchpad and as an icon in the left nav.

Supported languages

Story accepts prompts in any language and replies in the user's primary language. Marketing and analytical terms (SoV, sentiment, engagement) are kept in English where they are professionally common. The underlying data coverage spans Pulsar's full language footprint.

What you see when you use Story, and how it relates to what's happening underneath. The short version: you see one number — a percentage of your allowance remaining. It reflects the real cost of the work you have asked Story to do, but you never have to reason about tokens or model prices yourself.

The allowance model

When you subscribe to Story, your usage allowance for the period starts at 100%. As you use Story, that percentage goes down until it reaches 0%, at which point your included usage for the period is exhausted. You only ever see one simple number: how much of your allowance is left.

Why different models consume the allowance at different speeds

Not all AI models cost the same to run. A more capable model costs more per word generated than a lighter one, so Story does not treat every token the same. Usage is measured by real cost, not by token count alone. Two things drive that cost:

• Input and output are counted separately. What you send in and what the model writes back have different costs, so they are measured independently.
• Each model has its own rates. Input and output costs vary per model — Haiku is cheaper than Sonnet, which is cheaper than Opus.

That total is the figure compared against your allowance.

What this looks like in practice

Your plan gives you a fixed pool of AI usage for the period. The allowance starts at 100% and counts down as that pool is spent. How fast it falls depends on the model you run and the depth of the work, not on a per-question quota.

You are always spending from the same pool. The model you choose only changes how quickly that pool is used, not how the percentage is displayed. In both cases, the view stays the same: 100% counting down to 0%.

Some are intentional product choices; others are constraints we will close over the beta and into general availability.

• Schedules run at most once a day. Hourly and sub-hourly cadences are not available in public beta; a release supporting them is in development. Tight-loop monitoring has to run interactively for now.
• Chats cannot be migrated. There is no tool to move a brief or a schedule between chats — recreating it is the supported route. Chats created before 28 September 2026 were deleted on 28 October 2026 along with their history and schedules.
• Public beta ships three Claude models only (Opus, Sonnet, Haiku). The architecture is model-agnostic, but other providers are not selectable in-product.
• Cross-domain analysis is not supported unless the user is a Superuser on Pulsar. Each session is scoped to a single Pulsar domain.
• Charts are limited to nine supported types (spline, areaspline, bar/column, heatmap, pie, ranking, multipleBar, treemap, streamgraph). Unsupported types (scatter, sankey, network, choropleth, funnel, waterfall, candlestick, gauge, box, violin) fall back to the closest supported chart and flag the gap in prose.
• Maximum five top-level selections per single GraphQL operation. Story splits larger workloads across multiple execute calls.
• Pattern classification (SPIKE / PLATEAU / DECAY / STREAKY) requires at least 30 days of data to be reliable. Lifespan and Volatility are unreliable for windows under 7 days.
• Virality forecasts are descriptive with forward implications, not deterministic predictions. Story refuses to forecast where the data does not support it.

Reach out via the standard Pulsar support channels — in-app chat or support@pulsarplatform.com.