AI integrations

An organisation can let AI translate, summarise, categorise or review its documents at chosen points in the editorial process. Each AI step is an operation: a recipe saying what to send to a model, what answer to expect and where the answer goes. The model behind it is reached through a connector.

For example, an operation named translate-article sends an article's body to the organisation's own model provider, asks for the text in the language the editor picks, and writes the translation back into the article. Bound to a Translate transition in the article workflow, it runs whenever an editor takes that transition.

Operations

An operation is a document of type core/ai-operation, edited by members with the owner or admin role under System settings > AI integrations. It declares:

• the document type it applies to;
• the connector and model it uses;
• a reference name, such as translate-article, that workflows use to find it. Reference names are unique within an organisation: an operation that takes a name already in use is not saved, and the editor says which operation holds the name;
• instructions, written as prose;
• optional reference material, such as a glossary or a list of categories;
• optional inputs the member picks when the operation runs, such as a target language;
• the shape the answer must have, as a JSON Schema;
• output targets: where each part of the answer is written, for example a metadata field, the body text, or a new document.

Presets cover common jobs such as translation, categorisation and article review. An operation runs only once promoted to usable, and stays editable afterwards: a change applies from the next run. The full field list is in the document reference.

Connectors and the included models

A connector holds the address and API key of a model provider. One connector usually serves many operations, so rotating a key is one edit. The supported providers are OpenAI-compatible APIs, Anthropic, Mistral, and a generic JSON endpoint for any other service. The model is chosen per operation, not per connector. A connector can be disabled, which pauses every operation that uses it. The API key is stored for the organisation and never shown again after it is entered; replacing it is the only way to change it.

The platform also includes its own models, which run inside the deployment at no per-call cost, so the text they process does not leave it. They do three fixed jobs on wires, and one on videos:

• categorise every incoming wire by IPTC topic;
• translate wires when an editor creates an article from them;
• summarise those wires into the article's description;
• write the posts that share an exported video, per platform.

They also draft the script of a video when a member asks for an AI draft under Make video, and check every video script against its article. The script is a draft like any other: the article's quotes are offered to the model word for word, with their speakers, and it may only pick among them; each scene names the article sentences it rests on; and a source check compares every scene with those sentences before anyone can approve the video. See Images and audio.

Categorisation picks one topic from the fixed list of 17. Translation and summaries come from a general-purpose language model with fixed instructions: translate only, keeping names, numbers, dates, quotes and paragraphs, and summarise only from facts stated in the wire. Its answers are drafts for the editor; see Wires for the languages and how the summary language is chosen.

Video post texts are written from the video's own text only, in the article's language and the tone the editor picks (Inform, Urgent or Explain), and they stay editable before they are copied. The model writes the words; the platform adds the format of each platform, the link and hashtags from the story's tags. A post that names a number, name or quote the video does not have is replaced by the plain post the platform makes without AI, as is every post when no model may be used. The AI use of the source of every wire behind the video's articles applies (see Wires). A run whose posts are used is recorded in the video project's AI record.

They also process every recording: transcription, speaker separation and speaker naming all run inside Tidenda. Recordings and transcript text are never sent to an external AI provider by this processing, and no connector or operation can change that. See Images and audio.

Members with the owner or admin role can turn AI off for videos under System settings > Account, with Use AI to draft videos and write their post texts. It is on by default. Off, a video made from an article gets a plain draft made without AI, the post texts are the plain ones, and the video editor says that AI for videos is turned off. The setting is ai.video.enabled in the organisation's settings.

An organisation that wants video scripts drafted by its own provider creates an operation with the reference name video-script on one of its connectors (OpenAI-compatible, Anthropic or Mistral). While it is usable, its connector and model write the scripts; the instructions and the shape of the answer stay the platform's, since the check depends on them. A wire whose source allows only the included models still has its videos drafted by them.

The wire jobs and the video post texts appear as System defaults on the AI integrations page. Each can be replaced with Use your own integration, which creates an operation with the matching reference name on one of the organisation's connectors. While that operation is usable, the platform uses it instead of the included model. The included models cannot be chosen as the connector for any other operation. See Wires.

When operations run

Bound to a workflow step. A workflow transition can name an operation. When a member takes the transition, the operation runs, and the document moves to the transition's target status once the answer has been written. If the operation declares inputs, the member fills them in first. See Workflows and Adding AI to a workflow.

On demand in the editor. An operation with Offer in the editor switched on can be run by anyone who may edit a document of its type. Its answer is shown to the member and never written to the document, so only operations without output targets qualify, and every required input must have a default. Members see the operation's title, not its instructions or connector. The article review in the editor works this way.

On test. Test invoke in the operation editor runs the operation against a chosen document and shows the answer without changing the document.

What the model sees

The operation decides how much of the document to send: all of it, or only named fields. A document's private fields, its history and internal notes, are never sent. The model also receives the operation's instructions, its reference material and the values of any inputs.

For an on-demand run on a document that links wires as sources, the model also receives the plain text of up to 10 of those wires, so that instructions can ask it to check facts and quotes against them.

Everything sent through a connector reaches that provider. The answer is checked against the operation's schema before anything is written, whatever the provider promises about structured output.

Failures

While an operation runs, the document stays at its starting status, read-only, with a banner saying that AI is working. The banner offers a cancel link, which stops the run without writing anything.

• Temporary problems, such as network errors, provider errors, timeouts and rate limiting, are retried automatically with increasing delays, up to the operation's Auto retries count (3 by default).
• Problems with the answer: it does not match the schema, cannot be read, or the projection selected nothing. If the transition has an On failure status, the document moves there. Otherwise it stays at its starting status.
• Configuration problems, such as a rejected API key, a disabled connector, a missing operation or a reached usage limit, never move the document.

A run that ends without moving the document, whether it failed or was refused before the provider was called, releases the lock at once. The document stays at its starting status, editable, and its editors see a note in place of the banner: which step failed, the reason, and that the step can be retried or skipped. Members who can manage AI integrations get Retry and Skip on the note itself; other members can run the step again from the status menu. Dismiss removes the note for everyone. The note also goes when the document changes status or another AI step starts.

The lock and the note are kept in the document's private section (see Private fields), so neither appears in a snapshot, a webhook payload or an API response, and a pushed document cannot set them.

While automatic retries are pending, the run counts as working and the document stays locked. A run still marked as working after 10 minutes, for example because a provider never answered, is cleared with a timeout note.

Every run is recorded in the Invocations log at the bottom of the operation's editor: who or what triggered it, the request and response, the duration, and the error. A failed run there offers Retry, which runs the operation again on the document as it is now, and Skip, which moves the document on to the transition's target status without the AI's answer.

The AI label and the AI record

Every time AI changes a document's text, the platform adds an entry to the document's AI record: what AI did, when, the operation that ran, and who set it to work, a member or a workflow step. Entries are written when a workflow step writes its answer into the text, when an article is created from wires with AI, and when a member applies an AI review suggestion in the editor. An answer that only sets metadata, such as a category, adds no entry.

The first entry turns on the document's reader AI label (meta.aiGenerated). The public site shows it as a disclosure line, and webhook payloads carry it. Editors can hide or show the label from the AI chip in the article footer, which also lists the AI record in plain language. Each change of the label is logged in the record with the member and the time. Later AI changes leave the label as the editors set it.

The AI record and the label log are kept in the document's private section (see Private fields): they appear in no snapshot, webhook payload or API response, and a pushed document cannot set them.

Publishing without review

A workflow step can bind an operation whose success moves the document to usable or withheld. The model's answer is then published, and signed, with no person reading it first. An organisation allows this only by turning on AI publishing without review under System settings > Account. It is off by default.

While it is off:

• a workflow with such a step is not saved, and the workflow editor names the step and explains why;
• such a step, if a workflow still holds one, is refused when it runs, before the provider is called. The document stays at its starting status with a failure note.

While it is on, a document an AI step publishes carries meta.publishedWithoutReview, with the time and the operation's reference name, in its signed published version. Its AI label is on and cannot be hidden, and the public site says the article was published automatically without review.

The mark stays until a member moves the document into usable or withheld, which includes Skip on a failed step: the member has then taken responsibility for what is published, and the new published version carries no mark. Moves by the platform, such as an embargo release, and moves to other statuses leave it in place.

Publishing that involves no AI answer is not affected: newswires published on arrival, an On failure status that is usable, or a member's own transition.

Snapshots and rollback

Before an operation's answer is written into a document, the platform stores a copy of the document as it was. If some output targets fail to apply, the invocation log names that copy. Restoring it is a manual task for the platform operator; there is no rollback button.

This copy is separate from the signed snapshots that webhooks deliver. A webhook receiver sees an AI step as the document's transition to its target status, recorded in the history as made by the system rather than by a member, and, when the step published the document, as meta.publishedWithoutReview in the payload.

Limits

• Per operation: a maximum number of runs per hour and a cooldown per document, both optional.
• Per organisation: an hourly limit on AI runs, set by the platform operator, shared by workflow and on-demand runs. A run over a limit is refused before the provider is called.
• Included models: limited to their three wire jobs.
• One note per document: the note shows the latest failed step only. The full history of runs is in the invocation log.
• Publishing without review: off unless the organisation turns it on; see above.

Related pages

• Adding AI to a workflow
• Workflows
• Document reference