Keep your source content on brand

Goal: flag forbidden, competitor, and off-preferred terms in your source content and rewrite what fails — so what goes to translation (or production) is already on-brand. This is source governance, before any translation. The profile format lives in Brand voice; setting one up takes ten minutes.

▶

Walkthrough videoPending recording

Authoring a brand-voice profile, running the check on a source page, reading the score and located findings, and rewriting the off-brand blocks until the gate passes.

View scene script ↗

Desktop

With a brand profile bound in the project (Project Settings), the Checks view enforces it over everything the project tracks:

1. Run the checks. Brand vocabulary findings appear alongside hygiene and length — each named by rule, located to a block, with the suggested wording.
2. Fix at the block. Open the flagged file, correct the wording, re-run; the score climbs as findings clear.
3. Fix the rule, not just the draft. A recurring off-brand term belongs in the profile — add it as a vocabulary rule so every later check enforces it.

Agent (Claude)

Ask for the sweep:

Check blog/ against our brand voice and fix anything off-brand.

The assistant loads the voice first (kapi brand guide, injected into its context so it rewrites on-voice, not just rule-compliant), runs check_file, rewrites each flagged block, and lands the edits with apply_edits — structure intact, no second model. When a term recurs, it proposes a brand change-set entry that adds the vocabulary rule to your committed profile; git diff is the review surface. It re-checks until the gate is green.

CLI

Check against a profile — yours, or a built-in starter pack — plus any inline constraints:

kapi check blog-post.md --profile-file brand/voice.yaml
kapi check blog-post.md --pack marketing-blog
kapi check product-brief.md --forbid "synergy" --forbid "disrupt" --max-words 500

Exit 0 is a pass, 3 a gate failure; --json emits the kapi.check/v1 Report with one finding per block (Checks documents the schema). Then fix and re-check:

kapi inspect blog-post.md --jsonl > blocks.jsonl
# rewrite each flagged block's "text" (keep the <x id="…"/> tags) into edits.jsonl
kapi apply edits.jsonl --diff        # preview
kapi apply edits.jsonl               # write through the faithful round-trip
kapi check blog-post.md --profile-file brand/voice.yaml

An edit whose content hash drifted, or that would corrupt an inline code, is left unchanged and reported — see Edit content. For deterministic term substitution with no assistant (vocabulary only, not tone), kapi brand rewrite --profile-file brand/voice.yaml reads stdin or --input-text and reports each change. To also add the missing rule while fixing the draft, ship both in one change-set:

{"kind":"content","file":"blog-post.md","id":"paragraph-0","content_hash":"b74d19…","text":"Today we use our infrastructure..."}
{"kind":"brand","op":"add-rule","list":"forbidden","term":"leverage","replacement":"use","severity":"minor"}

The brand entry lands in the committed profile YAML the recipe binds and compiles into the local store, so the next check enforces it (requires a .kapi project).

In a project

Bind the profile once (defaults.brand_voice.profile_file) and every surface picks it up — the Checks view, the assistant's loop, bare kapi check, and the ship gate's brand gate. When translating, a bound voice is also injected into the translation prompt, so target-language output starts on-brand.

Next

• Set up your brand guide in 10 minutes — from starter pack to bound profile.
• Content governance for AI — brand + terms + checks as one guardrail set.
• Check content like tests — the gate mechanics and exit codes.