Skip to main content

Publish on brand

This guide is for people who write and publish content, site pages, posts, marketing copy, and want it to leave the building on profile for the audience it was written for, and optionally in more than one language. It assumes no codebase and no command line: everything below happens in the Bowrain web app, against the systems your content already lives in.

By the end you will have a workspace that knows its voice and vocabulary, a project connected to your content platform or design tool, server runs drafting and checking that content, a review session for what a machine cannot decide, and an explicit publish step that writes the result back where it came from.

Establish the contextaxes + voice profile + termsfetchConnectWordPress · HubSpot · FigmarunDraft and checkthe loop runs on the serverparked unitsReviewparked work, approvalsapprovedPublish backexplicit, per connector

Context first, then connect, run the loop, review, and publish back.

You need access to a Bowrain workspace; see First login for signing in and creating one. Adding connectors requires the manage connectors permission; approving a scan's proposals and saving a voice profile requires manage_voice, and promoting terms requires manage_terms.

1. Establish the context​

The loop can only enforce what the workspace has written down. Three things carry that knowledge, and all are shared across every project in the workspace:

  • The axes your content varies along: the brand, the kind of document, the market. Content sits at a point on them, and what governs it is bound there.
  • A voice profile: a machine-readable description of how content at a point should read: tone, style rules, preferred and forbidden vocabulary, before/after examples. Most workspaces call their default profile brand. Once saved, it runs as checks over everything the loop produces, and it keeps improving: corrections your reviewers make aggregate into candidate rules that a reviewer promotes into the profile.
  • Terms: the concepts and terms your team has decided on, per language, with lifecycle statuses (preferred, deprecated, forbidden). Term suggestions appear in the editor, and term use is checked on everything a run produces.

Starting from nothing, use a context scan: point it at material you already have, pasted copy, public web pages, uploaded documents, and it proposes the axes, a voice profile and term candidates for you to edit and approve. Nothing a scan proposes is enforced until you approve it. Alternatively, curate directly: add concepts in the terms explorer or import an existing terms list from CSV or JSON.

You do not need a finished profile to continue. A thin profile plus the correction loop is a workable starting point; the rules you actually need surface as reviewers fix real output.

2. Connect where your content lives​

Create a project with your source language and any target languages you want (see First login), then open the project's Connectors view from the project sidebar. Connectors are shared across the workspace; fetching and publishing act on the project you are in.

Click Add connector, pick the system, and fill in its credentials. They are write-only: the server uses them to sync, and the interface never displays them again. Each connector syncs a specific slice of its system, and the limits matter when you plan what to route through Bowrain:

SystemWhat syncsPublish backNotable limits
WordPressPosts: title, body, excerptYes, updates fetched posts in placeFirst 100 posts; posts only (no pages, custom types, or media); never creates posts or changes their status
HubSpotCMS site pages: HTML title and meta descriptionYes, patches the page objectBody content and modules are out of scope; a separate publish inside HubSpot may be needed to go live
FigmaEvery text layer of one design fileNo, pull-onlyTranslations are exported and applied outside Figma

Once a connector is added, Browse content shows what it can see, and Fetch now pulls that content into the project as source text. Sync is explicit: connectors do not poll on a schedule, and fetching stores source content without starting a run. The same operations are available through the workspace connectors API if you prefer to script them.

For a one-off document with no connector, a press release, a slide deck, a contract, upload the file directly into the project and export the finished file from the editor in its original format.

3. Draft and check​

Content fetched from a connector is ordinary project content, and a server run is how it catches up: each run checks the source against the context, reuses what the workspace already remembers, drafts the rest with AI steered by the voice profile and vocabulary in force at each point, checks everything it produced, and parks what a machine cannot decide for a person. Parked work is pending review, not an error.

From the web app, start a run from the project's Runs view with Run now; the run's progress, pass count, and per-locale summary appear in the same view. A connector fetch raises no server event, so content fetched from a CMS is caught up by starting a run; automation rules react to content being pushed (from a repository or the CLI), not to a fetch.

For finer control, say draft then run a specific check, author a server-side flow on the project's Automations > Flows tab and run it over the project. Flows are connector-agnostic: the same flow applies to content from any connector.

4. Review​

What the loop parks lands in the project's review session, which walks every pending block across items and locales with the source, the draft, the checks and the voice findings side by side. Approve, reject or edit each block, or approve everything that passes the checks and the voice bar in one action. Approving the last pending block starts the run that delivers.

Every fix a reviewer makes is also a signal: recurring corrections surface as candidate voice rules with a measured blast radius, and promoting one makes it an enforced check on every future generation (see Voice and corrections). The per-locale ship state on the dashboard tells you what can go out today.

5. Publish back​

Publishing is a deliberate, explicit step; nothing leaves Bowrain on its own. In the project's Connectors view, click Publish on the connector and confirm; the connector writes the project's stored text back to the matching items in the remote system, overwriting what is there.

What arrives depends on the system: WordPress posts are updated in place (title, body, excerpt, publication status untouched), HubSpot pages receive their new title and meta description but may still need a publish step inside HubSpot to go live, and Figma has no publish path, so you export the translations and apply them through your design workflow. Each connector page states exactly what its publish writes.

What's next​