Saga newsroom system

Saga is the one newsroom computer system (NRCS) you can connect today. One connection carries four things, each switched on separately: stories pushed from Nuvelics, pitches delivered to Saga's feed intake, stories arriving from Saga, and the Nuvelics panel inside Saga. This page explains what each does and what to expect. The steps to create the connection and turn each part on are in the NRCS settings tab.

You can have several Saga connections, for example one per Saga installation, and each part is set up per connection.

What to ask your Saga administrator forCopy Anchor Link

• An API key for the integration. Nuvelics uses it for everything it sends to Saga.
• Saga's API address and your instance address. Both must be https. The instance address is also how the panel works out which connection it is embedded in.
• For stories arriving from Saga: a place in Saga's own webhook settings to paste an address and a key that Nuvelics gives you. Select only the Story and Pitch events; Nuvelics accepts and ignores every other event Saga offers.
• For pitches in Saga's feed: the feed id of each Saga feed that should receive a newsdesk's pitches. Each id must be registered as a feed source in Saga, and you must type it exactly as Saga has it.
• For the panel: where Saga's own settings take an HTML plugin address.

Push a story to SagaCopy Anchor Link

An editor with the Member role or above pushes an enriched story with Push to NRCS; see Push a story to your newsroom.

What arrives in Saga. A new story, titled as the Nuvelics story, whose description is the story summary and whose body holds the Summary and Why It Matters. Attached to it are six notes: 5W1H, Original Sources, Additional Sources, Key Claims & Fact-check, Story Timeline and Key Entities. Sources that carry no web address, such as a journalist's own text, PDF or image, are never named in what leaves Nuvelics, and an additional source research found but never read is left out.

What you should know.

• A story is pushed to a given connection once, and only after enrichment has finished. Nuvelics sends the story as it is at that moment: outputs are not carried across, and later changes in Nuvelics do not update the copy in Saga.
• A story that came from Saga cannot be pushed back to it.
• Nuvelics cannot undo a push. If the push fails part way, the story may already exist in Saga, and the connection stays selectable so you can try again; a retry creates a second story, so check Saga first.
• Each push is recorded in the story's history and the audit log, and can be announced in a chat channel; see Slack and Google Chat.

Deliver pitches to Saga's feedCopy Anchor Link

Pitches normally wait in Nuvelics for an editor to review them. With the pitch feed on, each pitch is also delivered to Saga as an item in a feed, so producers who live in Saga see it there.

How it is set up. The feed is on or off per connection, and you map each newsdesk to the Saga feed id its pitches go to. A newsdesk with no mapping delivers nothing. Mapping a desk does not send its earlier pitches: only pitches created after the mapping are delivered.

What arrives in Saga. One feed item per pitch: the pitch headline, its summary, why it matters, and, where the pitch was built from articles, the list of articles that corroborate it with their publisher. The item names the pitch's newsdesk as its source and carries the pitch's language. A pitch someone wrote by hand has no corroborating articles, so its item lists only any web links it was started from.

What to expect.

• Delivery is automatic and runs in the background. A draft pitch that its creator has not yet sent to the desk is not delivered until it is.
• A delivery that fails for a reason that may pass, such as Saga being unreachable, is retried with a growing delay, up to five attempts over several minutes, and then given up. A pitch Saga refuses outright is not retried.
• If Saga rejects your API key, the connection's Health turns Unhealthy until a delivery succeeds again. Replace the key on the connection.
• Delivering the same pitch twice does not create a second item, because Saga keeps one item per pitch.
• An id Saga has not registered as a feed source is accepted, and the items are shown to nobody. Nuvelics records them as delivered and cannot detect the mistake, because Saga offers no way to read the feed back. Check a first pitch in Saga after you map a desk.
• Removing a newsdesk's mapping stops its deliveries; pitches already delivered stay in Saga.
• The feed delivery history of one pitch, including pitches that are waiting, not mapped, or older than the mapping, is available through the pitches API.

Receive stories from SagaCopy Anchor Link

With Accept inbound deliveries from Saga on, Saga tells Nuvelics whenever a story or pitch is created, changed or deleted there, so the stories your journalists write in Saga appear in Nuvelics.

What happens.

1. Saga sends an event to the address Nuvelics gave you, with the key in an x-api-key header. Nuvelics answers right away and always with success for an event it understands, including ones it ignores, so Saga does not resend work that was never lost.
2. Nuvelics stores the record and fetches Saga's fuller view of it in the background: its editorial state, assigned people and body text.
3. What the record becomes depends on what it is:
   • A story your journalists wrote in Saga becomes a story in Nuvelics with the origin Saga. Nuvelics waits a few minutes after first seeing it before creating the story, so that a story you pushed yourself is recognised rather than duplicated.
   • The copy of a story you pushed is linked to the story you pushed. The newsroom's later edits to the copy show on that story, and no second story appears.
   • A Saga pitch is stored as a record only. It does not become a story.
4. When Saga reports a story that came from Saga deleted, or its editorial state archived, the story is marked as dropped in the NRCS. Archiving or deleting the copy of a story you pushed leaves the Nuvelics story alone. Dropped stories are hidden from the list unless you filter for them, and Nuvelics refuses to create outputs for them. If Saga restores the story, it is back.

Enriching and checking what arrives. Arriving stories are not enriched or checked unless you turn on Evaluate stories Saga delivers against the org's story checks. It is off by default because it spends your organization's model budget on every story. Only stories delivered after you turn it on are processed. When a journalist keeps editing, Nuvelics waits for a pause in the changes before enriching again. Story checks run on the text that Saga holds. The checks themselves are configured separately.

Limits.

• Saga is the only newsroom system Nuvelics receives stories from.
• The address and key are shown once when you turn the webhook on. Regenerating replaces both, so update Saga as well.
• Nuvelics never reports the health of the webhook key, only of the API key it sends to Saga.

Use Nuvelics inside SagaCopy Anchor Link

The Nuvelics panel is a narrow view of pitches, stories and enrichment that Saga loads in a side panel. Journalists read and review without leaving Saga, and can file a story in Saga from it. What each view shows is in Saga plugin panel.

What you do in Saga. Paste the HTML Plugin address shown on the NRCS tab into the place in Saga where an HTML plugin address goes. Nothing else is configured on the Saga side.

What a journalist does. On first use the panel shows Sign in and a short code. The journalist confirms the code on any device, in a browser they are already signed in to or on their phone, and the panel opens itself. The code is good for five minutes. The panel then stays signed in for up to 90 days of continued use.

Good to know.

• The panel's access is narrower than the person's own: it works with pitches, stories, adding a story to your NRCS and the newsdesk list, and nothing else, and it is limited to one organization.
• Everyone in the organization can open the panel, but what a person can do in it matches their role. Adding a story needs the permission to push to the NRCS.
• Add story files the story in Saga the same way Push to NRCS does, once per connection. The panel works out which connection is embedding it by comparing Saga's address with each connection's instance address; when it cannot tell, the journalist chooses the connection.
• Signing the person out of the Nuvelics web app, or disconnecting the panel from their connected applications, ends the panel's access at once. Reducing someone's role takes effect on the panel's next request.
• Sign-in opens no popup, so it works in a Saga panel that blocks popups, and in desktop clients that embed a browser.

Manage it another wayCopy Anchor Link

• CLI: nuvelics nrcs-config creates and updates connections, and nuvelics story push pushes a story (nuvelics story).
• API: NRCS configs, including the webhook endpoints.
• AI assistants: the NRCS tools.