Positioning & messaging canon

Internal contributor note. When you write or edit user-facing prose (docs, landing, README, CLI help, UI copy, the kapi Agent Skill, MCP tool descriptions), match this. neokapi is positioned as a content and language intelligence framework. This canon supersedes both the older translation-first phrasing and the earlier "dual-heart" framing. Pairs with the repo-root docs/internals/brand-communication.md guide.

What neokapi is (the one sentence)

neokapi is an open-source, format-aware content engine: parse any format into one unified content model, let a person or an AI agent edit the content inside it, check it, and write it back — byte-for-byte. The same engine makes that content work in every language, so going multilingual is part of the journey, not a separate tool.

kapi is the CLI + desktop built on the engine. neokapi is one continuum — get your content right, then get it everywhere — where "everywhere" means every format and every language. There is no second story.

Who it's for

The forward-looking builder — developers, AI builders, and content people who ship across formats and languages and want it to just work, without becoming translation engineers.

We are not optimizing for the traditional translation engineer / CAT-tool / agency buyer, and we do not court them with their own jargon. We use language technology as the machinery that makes content just work — it is the engine room, never the product identity or the headline. A builder should reach "and now it's in French, with the tags and placeholders intact" without ever learning what a TMX file is.

The journey (one continuum, optional multilingualism)

Point kapi at your content → get it right (parse · edit · check · brand) in your real files → and it works in every language, automatically → ship it back unchanged.

• Multilingualism is optional and woven in — a natural turn of the same project, not a fork, not a ceremony, not a "Languages" nav header. A monolingual builder has a complete tool after "get it right"; languages are simply the next thing the same engine does.
• The hard language tech — byte-for-byte round-trip, content memory, segmentation, bilingual interchange — is the under-the-hood reason it just works. Name it once in depth/reference and link to it; never lead with it, never make the visitor learn it.

The lead wedge (one verb, one buyer)

Lead with Edit on developer / structured formats:

The open engine that lets you — or your AI — safely edit the content inside real files (JSON, Markdown, HTML, config, i18n catalogs) and write them back, byte-for-byte.

Why this wedge: headless byte-fidelity gates CI, there is no native AI editor for these formats, and the engine already serves them. Do not lead with editing binary Office (.docx/.pptx) — Microsoft Copilot and a wave of Office MCP servers own in-app office editing. We support those formats and harden them to an SLA; they are not the headline.

The three pillars (the body)

1. Parse — read any format into one unified content model with roles, structure, and stable anchors. Clean input for AI/RAG, with provenance to write back.
2. Edit — change the content inside a format and save the original, byte-for-byte. Programmatic (ksed, transforms) and AI-driven, with a safety harness that preserves annotations and produces a reviewable diff.
3. Check — deterministic + AI checks emit one finding shape with a 0–100 score; gate on it (exit 3); loop with an assistant until it passes — tests for AI output.

These three run identically whether you rewrite the source or produce a target: the same byte-for-byte write-back holds at the monolingual and the multilingual end. (They are distinct capabilities in code — rewrite is a Transform over SourceView, translate a Produce over VariantView, AD-006 — so never write "translate is just rewrite with a target"; write "the same write-back holds whether you rewrite the source or produce a target".) Brand voice is one check in this checkset, not a separate system.

The moat (state it honestly)

The differentiator is byte-for-byte read-modify-write round-trip across the long tail. Do not claim "everyone else only extracts" — that is false (Aspose, GroupDocs, python-docx, the Office-MCP wave all write back). The honest, defensible claim is the bundle:

the only open-source, format-agnostic, agent-drivable engine that round-trips the long tail under one streaming model, with overlay-safe annotations and a built-in QA loop, headless.

State the moat once canonically (the hero subhead) and cross-link it — do not multiply it across sections. It is true identically at both ends and proven at both ends: the format-maturity dashboard is the monolingual proof; parity and test-comparison are the multilingual proof. Never assert "survives anything" or "every … preserved" as an unbacked claim — point to the dashboards ("under load, per format").

Use RAG/AI-ingestion as a named use case, never the category. Never publish a parse-accuracy benchmark or enter a parsing leaderboard (PDF is an off-core plugin).

Who lands where (all open-source — no commercial funnel)

Audience	Lead with	Lands on
Builders editing structured files	the Edit wedge	kapi inspect/kapi apply, the format-aware toolbox
AI / agent builders	kapi as an MCP tool / Agent Skill	use-with-Claude, the agent loop
AI / RAG engineers	the Parse verb (inspect, anchored JSONL)	OSS mindshare
Builders shipping in many languages	"and in every language" — it just works	the translate / content-memory / segmentation recipes, the neokapi-i18n CLI

Every destination is an open-source page on the project site. There is no sales funnel.

Bowrain on the project site: four named seams, nothing else (R9)

Bowrain is a separate, commercial platform with its own site and its own positioning. On the neokapi project site it appears only as neutral, admonition-style "Works with Bowrain" notes — at most four, at exactly these named seams:

1. Plugins — the desktop tour's plugin section (kapi/desktop/tour.mdx), where the kapi-bowrain plugin is documented like any other plugin.
2. Review — the review & approve recipe (kapi/recipes/review-and-approve.mdx), where local review's single-reviewer limits are described.
3. Cross-project context — the content-memory and terms storage recipe (kapi/recipes/memory-and-terms-storage.mdx), where the storage models are enumerated.
4. CI / the loop — the kapi-loop-in-CI page (kapi/convergence-in-ci.mdx).

Callout rules: factual register, a plain link to https://bowrain.cloud/docs/ and nothing else, no pricing or selling copy, no nav entries. Everywhere else the project site stays Bowrain-free — homepage, README, CLI help, every other docs page. (The kapi/Bowrain architectural boundary still holds in the code; these four seams are the only messaging exceptions.)

The decided venue lines (R12 — canon, verbatim)

Where a headline or pitch is needed on a Bowrain-facing surface, use these verbatim:

kapi holds the context graph for one project. Bowrain holds the same graph across projects.

The frame behind it: communication is contextual — a legal notice is not a help article — so every project carries a content context, the coordinates that fix voice and tone for a specific time, place and audience. kapi resolves those coordinates locally and serves the context that holds there; Bowrain holds the same graph at organization scope. The difference is reach, not capability: one project's context, or every project's.

Brand is one coordinate beside audience, surface, register, market and validity — not the frame. Content memory keeps its name and meaning: it is the store of approved wording, a different object from the graph.

Never use: "brand memory" (retired by R12); "Kapi drafts, Bowrain governs"; "converges it for your whole team, all the time" and any "whole team" venue phrasing; any hero that leads with translation.

Naming: all prose — framework docs included — says content memory (with recycling as the verb), never "translation memory". The identifiers keep their own spelling in code and on the wire: the recipe keys tm: / memory_source: / termbase:, the --memory and --terms flags, and the on-disk memory.db / terms.db. Prose that has to name one describes the concept in the settled vocabulary and quotes the identifier in backticks — "the project's content memory (.kapi/memory.db)", "the terms store (terms.db)".

Headline register: brand, voice, on-brand, agents, governed review, delivery, the kapi loop. Search-keyword vocabulary — "Lokalise alternative", "localization platform", "translate XLIFF" — belongs only on bowrain.cloud SEO surfaces; never in headlines, nav, or docs titles. Never disparage competitors.

Vocabulary (write the left as the right)

Don't write	Write
"primary translatable content unit"	"primary modifiable content unit"
"the translatable text of any format"	"the text/content inside any format"
"translation memory" / "TM" (the product noun)	"content memory" — the store; recycling is the verb
"termbase" / "glossary" (the store)	"the terms store" — keep a head noun; a bare "terms" needs an article
"localization" / "l10n" (as the framing)	recast the sentence: "multilingual content", "language", or plain "translation" where that is what is meant
"a localization and translation toolkit"	"a format-aware content engine — parse, edit, check any format, in any language"
"Source / Target" (to non-specialist readers)	"canonical content + variants" (axes: locale, tone, channel)
"everyone else only extracts"	"the only OSS, format-agnostic engine that round-trips the long tail …"
"faithful" (as a brand adjective)	drop it — use the concrete "byte-for-byte" / "write it back unchanged"
"faithful content model"	"unified content model"
"at heart, a localization engine and the tool that keeps your source content on brand" (dual-heart)	one continuum: "get your content right, then get it everywhere" — multilingualism woven in, not a second heart
"Add a language" / "Localize" / "Languages" as a nav header or ceremonious stage	weave it as a natural outcome: "and in every language" — part of the journey, not a separate destination
specialist jargon in the lead (XLIFF, TMX, "Okapi alternative", "translation memory")	builder outcomes ("it works in every language"); keep the jargon in depth/reference only
a lone narrow format in a generic example (XLIFF, .docx)	a broad/recognizable set ("JSON, HTML, Markdown, config, office formats"); keep XLIFF/PO only in explicit multilingual copy

Code-level: the generic tool capability carries neutral vocabulary — CapProduce, the Produce(VariantView) handler, VariantView — while the ITS Translate field keeps its spec name. Keep the user-facing translate tool and kapi translate command: that is the translation application. Do not rename Source/Targets/VariantKey/Block.Translatable (good generic names, wire-bound, or — for Translatable — a parse-time extraction classifier, not an editability flag).

Don'ts

• Don't make the homepage legible to five audiences at once — lead with the one wedge, then offer use-case pages.
• Don't sell or mention Bowrain on the project site outside the four R9 seams (see above).
• Don't make "Languages"/"Localize" a nav header or a ceremonious "add a language" step; weave multilingualism into the journey as a natural outcome.
• Don't court the traditional translation engineer with their own jargon — serve the builder who wants it to "just work," and keep the language machinery under the hood.
• Don't put "the content layer your AI assistant orchestrates" (or similar AI-orchestration slogans) in the hero. The tagline's "for people and AI agents" carries it; the slogan decays fast.
• Don't hardcode counts (formats/tools/providers) — name categories, link to generated references (per brand-communication).
• Don't bury or delete the multilingual story — it is the proof that byte-for-byte write-back holds under the hardest workload (parity dashboard, XLIFF/TMX, okapi-bridge). Present it as the engine quietly doing the hard thing, not as a separate product.