Keeping content caught up

When source content changes, translations and previous check results may need updating. A Bowrain run reuses eligible content memory, drafts the remaining text and checks the results. Work that needs a reviewer waits for review in the team's review queue.

Runs execute on the server using the configured AI credentials and the workspace's shared terms, content memory and voice profiles. Content imported through a connector uses the same processing flow.

The steps below happen on the server. The model behind them, with its lifecycle ladders, coverage gates and ship states, is documented on the kapi site as the kapi loop.

Produce, promote, release

Each of the three steps happens in its own place:

A server run produces; review in the app promotes what a machine can't decide; the ship gate releases.

• Produce: a run. A server-side flow over connector content, a push under the bowrain.converge policy, or a developer's kapi up takes each block as far up its lifecycle as a flow can without a person.
• Promote: review. Items a run holds back appear in the project's review session. There a person, or several people sharing the decisions, approves each translation a machine could not decide.
• Release: the ship gate. kapi check --ship reports whether a scope is shippable. You add it to a pipeline as the enforcement point for a release. An ordinary build passes when target languages are behind.

The formal name

The model behind this (derived state, lifecycle ladders, coverage gates) is formally called convergence; the server-side runs are convergence as a service. The REST API, the run event stream, and --json output use that vocabulary. On the kapi site the same model is named the kapi loop.

Source first

A run settles the source first. It checks source content and translates it only once it reaches the configured translate_after level. A source problem fixed before translation is fixed once, instead of once in each target language. You can set the gate to require a person's approval.

A server run settles the source, holds each block until its source reaches translate_after, then translates the source that has. Work that needs review is added to the review queue.

• Settle the source. A server run's first pass covers the source locale only. It runs the source checks and the rule-based checks, and marks do-not-translate terms as protected so translation leaves them unchanged. It then moves each block's source status up the authoring ladder (written → approved).
• Hold the source. The project's defaults.translate_after (default written) is the source-side counterpart of the ship gate. Source that has not cleared its bar holds: the run stops with the reason source_not_ready, opens a source-review task in the team's queue (see Review), and reports how many blocks are blocked on source. Set translate_after: none to translate without holding the source.
• Translate source that meets the gate. The run processes settled source per locale, memory first. It reuses what the shared memory already has, translates the remainder with AI, and checks the result. Protected terms stay unchanged.
• Hold at the target ship-gate. A locale that clears its ship_gate is shippable. Anything a machine cannot decide waits for review.

Editing a source block re-opens the hold for the changed segments, and the next run checks and regenerates them. The kapi site documents the ladders and gate thresholds under Source first.

Who starts a run

A connector, push policy or explicit command can start a server run:

The same server-side run, started by a connector, a push policy, or a developer's command.

• From a connector, with no checkout. For content connected server-side, such as a content platform or a design tool, a server-side flow or automation rule runs over the content where it lives and publishes the results back to it. A repository connector turns a push webhook into a run and delivers the results as a pull request. The repository needs no pipeline.
• From a push policy. With bowrain.converge: on-push in the recipe's bowrain: block, every push starts a server-side run, and the project stays current without anyone running a command. You set the policy per project, in the same way a repository sets CI to run on git push. See Automation.
• From a developer's terminal or CI. kapi up on a connected project prints its resolved venue first (server), pushes the drift, streams the run's progress live into the same terminal view, and pulls the results down. kapi up --local overrides the venue for one run: the work runs on that machine with its keys, and kapi pushes the results so the server stays current. kapi up --server requires the server venue and fails if it is unavailable, for CI that must never spend local keys. See the kapi connector and the loop in CI.

Seeing it

Every surface reads the same derived state:

• In the web and desktop app, a project's Runs view lists the server-side runs (Running, Up to date, Waiting for review) with the trigger (Manual, kapi up, On push), the pass count, and a per-language summary such as "3 shippable · 1 waiting for review". A Run now button starts a run from the app, and an in-flight run can be canceled.
• In the terminal, kapi status shows the per-language coverage grid, the server standing, and the effective venue and bowrain.converge policy.
• In the review session, translations waiting for review are the worklist. A run reports them as awaiting a person and exits zero.

A run started from the app and a run started from a terminal emit the same event stream. The Runs view, CLI and --json output report progress from those events.

See it run

The video shows the developer route: connect a repository, push, and bring it up to date on the server.

Outdated wording

The narration uses terminology that has since been retired. The interface and the behaviour shown are unchanged.

What's next

• Connectors: every route into a workspace
• Quick start: get content in, from your systems or from a codebase
• Review: where work waiting for review gets promoted
• The loop in CI: pipelines and the ship gate
• The full model on the kapi site: ladders, gates, ship states