Skip to main content

Context

Use the Context hub to manage writing guidance and terms for a workspace. It shows where terms apply, their history and relations, and the effects of proposed changes. Profiles can be scoped to a brand, product, channel or other coordinate.

For detailed workflows, see Voice and corrections and Terms. To derive first proposals from existing content, run a context scan.

Outdated wording

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

Profiles​

The hub opens on Profiles: one card per point the workspace's content sits at. A point is a coordinate such as a product, channel, brand or market. A profile is the guidance that applies at a point. The workspace's own point, which holds content that declares no coordinates, is labelled Brand.

Each card shows the applicable voice profile, vocabulary, stored check results, pending reviews and custodians. Check results include scores and findings for the blocks checked. A point with no results is marked as unchecked. Opening a card shows these details and the collections and projects at that point.

A check score belongs to a voice profile. A stored check records the voice profile it resolved through, at the narrowest coordinate the check carries. Two points that share one voice profile show the same score, and the card says so.

Bowrain derives profiles from the content it holds. Each push from a checkout (kapi push) declares every collection's coordinates and the voice profile they resolved to, and Bowrain groups the collections by point to recover the profiles. A recipe's own profiles: regions stay in the project, which resolves them and sends only the result. One broad profile that governs two points therefore appears here as two points.

Who holds a point​

Custodians are members with a manage_voice or manage_terms grant at the point or an ancestor. The card lists their grants and scopes. Points without a custodian are marked as unassigned; this does not prevent content processing. Custodian assignments also determine custodian seat usage. See Members and roles.

Axes​

Projects declare axes in their recipes. Approving an axis proposed by a context scan records a pending recipe change. The next kapi pull writes a declared axis to defaults.coordinates.<axis> in kapi.yaml for review and commit. A structural product or channel axis is approved for a specific collection and written to its channel: field.

The server accepts content at the new coordinate after the updated recipe is pushed. It rejects coordinates whose axes are absent from the recipe.

Channel names​

Projects can use different names for the same channel. Bowrain identifies possible matches across a workspace and proposes them for review.

Accepting a proposal records that the names refer to the same channel. Dismissing it records that they are distinct. Either decision prevents the pair from being proposed again. These decisions leave recipe slugs and local coordinate resolution unchanged.

Concepts​

The hub works with concepts. A concept is the language-neutral notion behind terms. It carries terms across locales, each with a lifecycle status, plus a domain and a definition. A forbidden term is a concept whose term has the forbidden status. Voice vocabulary rules reference the same concepts, so terms and voice profiles stay consistent.

The Concepts section is a list of concepts beside a detail pane. Each row shows the term a concept is headed by, that term's status, and how many languages the concept has terms in. Search the list, or narrow it by term status or market, and select a concept to see beside the list:

  • its terms in each language, each with its lifecycle status, and the deprecated and forbidden forms with the term to write instead;
  • where it came from: its domain, voice profile and coordinates, whether it belongs to one project or the whole workspace, and who added it and changed it last;
  • its relations: the concepts one hop away;
  • and its history, the discussion on it and the evidence recorded for it, one tab each.

Select a related concept to open it in the pane. A link to one concept, from Activity, the dashboard or a review, opens the list with that concept selected.

Relations​

Concepts connect to one another through typed relations, drawn from the framework's SKOS-aligned vocabulary. They fall into a few families: hierarchy (a concept is broader than, narrower than, or part of another), succession (one concept is replaced by another), guidance (use this one instead of that one), cross-scheme equivalence, and stance (this concept is a competitor's). The exact label set is defined by the framework's terms model; see the framework terms reference for the canonical list.

e-shopforbidden termreplaced_byStorepreferred termbroaderCommercebroader concept

Typed relations connect concepts: a retired term is replaced_by the preferred one, which in turn sits under a broader domain concept. Guidance (use_instead) and stance (competitor) relations connect concepts the same way.

A concept's detail pane lists its direct relations, one line each: the kind of relation, the concept at its other end, and an arrow for its direction. Selecting the other concept opens it. Relate, in the pane's toolbar, adds a relation to another concept, and the cross on a line removes one. An ordinary relation applies directly; a succession (replaced_by) relation is a governed edit that travels through a change-set before it lands.

Every relation can carry a validity: a time window, plus tags such as a market. A relation can hold in one market and not in another, or only after a launch date. A concept shows the relations that apply as of the chosen date and within the chosen market.

Markets​

A market is a workspace-defined scope, a name plus the locales it covers (for example a dach market covering de-DE, de-AT, and de-CH). Markets give the free validity tags a stable vocabulary: a term or relation scoped with market: dach is interpreted, filtered, and rendered consistently everywhere. A term's status can differ per market: a term can be forbidden in Germany and permitted elsewhere. In a concept's detail pane, each language is labelled with the markets that cover it, a relation scoped to a window shows the dates it holds between, and the Concepts list narrows to one market. Plans also limit the number of markets; see Billing and credits.

The concept story​

Every concept has a story, shown on the History tab of its detail pane. It lists, newest first and with who acted and when:

  • the concept's revisions. Each edit produces an immutable snapshot with a summary, which records term-status transitions and relation changes.
  • the observations recorded against it.
  • its comment threads.
  • the change-sets that touched it.

The Discussion and Evidence tabs beside it hold the comments and the observations in full. Compliance scores are reported per project and locale on the hub's Dashboard.

Observations: what others say​

An observation attaches external evidence to a concept: a competitor's phrasing, customer language from a support ticket, a style-guide citation, a regulatory requirement. Observations carry a kind, a quote, a source, and an optional locale and market. Observations are evidence. They inform proposals and appear in the story, and no check enforces them.

Comments​

Concepts carry threaded comments with @mentions, which notify the person mentioned. Discussion happens where the decision is made: on the concept, or on the change-set under review. Resolved threads stay in the story.

Voice and corrections​

The Voice section holds voice profiles and correction records. Repeated corrections can produce candidate rules for a reviewer to promote into a profile. Every promoted rule references the concept it governs. See Voice and corrections for candidate review, blast-radius previews and progressive autonomy.

Experiments: change-sets and pilots​

The hub's Experiments section holds consequential changes as reviewable drafts.

A change-set is a named draft of edits to the graph and to the vocabulary: create or update concepts, add or remove terms, change a term's status, add or remove relations, add or remove concept-backed voice rules. Operations collect in the draft, and the live graph changes only when the change-set merges. You can evaluate a draft in two ways before approval:

  • Blast-radius preview. At any point, Bowrain evaluates the draft against stored content across the workspace and reports which blocks, in which projects, collections, streams, and locales, would be newly flagged or resolved, with a source word count as a proxy for re-translation effort and a sample of affected blocks to inspect. The preview leaves stored content unchanged.
  • Pilots on selected streams. Bind a change-set to one or more content streams to evaluate it before merging. Voice checks use the pilot's candidate profile on those streams. The trial report compares proposed term changes without applying them to ordinary term checks, which continue to use workspace terms. Merging applies the operations and removes the pilot overrides. Abandoning removes the overrides without applying the draft.

Tiered governance​

Edits are classified as ordinary or governed. Only governed edits require approval by another person.

Ordinary edits, such as definitions, notes, observations, comments, proposed terms and non-status term metadata, apply directly, produce a revision, and land in the audit trail.

Governed edits, such as setting a term's status to forbidden or preferred, removing such a status, succession (replaced_by) relations, concept-backed voice rule changes, and merging any change-set, travel through a change-set and require at least one approval from someone other than the author (separation of duties). Term-status transitions are additionally checked against the framework's status-transition policy, so a forbidden term returns to preferred only through a governed transition.

Authormanage_termsReviewermanage_voiceWorkspace graphsystem of recordopen change-set, add governed oppreview blast radiusnothing persistedsubmit for reviewapprovereviewer ≠ authormergeops applied, pilots retired

A governed change travels through review by someone other than its author before it touches the graph.

A change-set with only ordinary operations merges directly from draft by its author. A change-set containing any governed operation must be submitted, approved by a second person, and only then merged. The lifecycle is the same in either case:

ordinary mergeDraftaccumulate opspreview blast radiuspilot on a streamsubmitIn reviewsubmittedapproveApproved≥1 approval, approver ≠ authormergeMergedops applied, pilots retired

A governed change-set moves draft → in review → approved → merged; an ordinary one merges straight from draft. Merge re-validates each op against the current revision, so conflicting edits are rejected.

The dashboard and the decision inbox​

The Dashboard opens on the workspace's counts: projects, concepts, suggested rules, what needs you, active experiments and voice profiles. What's new sits below them and lists what waits for a decision first. A change-set in review or approved shows who proposed it, how long it has waited and the blast radius stored when it was submitted. Its button opens the change-set, where a reviewer approves or rejects it. A voice profile whose team's corrections suggest rules has a row that counts them by kind, and its button opens the profile's review. The change-sets that moved most recently follow.

Each project then has one row: its voice profile, its latest compliance score against that profile's bar, the trend, whether it is drifting, and when it was last checked. One project's compliance over time, terms by status, each language's coverage, the markets and the most recently changed concepts sit below the projects.

The Activity section is the workspace's record of work on its context, as a list of sessions beside a detail pane. A session is one person's run of work: their operations, close together in time. Each row names who worked, the time and the number of operations, under the day it happened. The detail pane lists the session's operations, each with an icon for its kind, and its facts: when it ran, what it recorded, and the reviews it decided, so who approved, rejected or merged a change stays on the record. Selecting an operation about a concept or a change-set opens it, and the toggles in the header narrow the record to changes, concepts, evidence or comments.

The record covers concepts created and updated, statuses changed, relations gained and lost, observations and comments added, change-sets submitted, approved, merged, and abandoned, and pilots started and stopped. It is the workspace-wide counterpart to a single concept's story.

The hub in the desktop app, CI and assistants​

The Context hub is the same in the web app and the desktop app. The desktop app is a working copy of the server and reads the same API. You edit concepts and relations in the hub against the server, so editing them needs a connection.

Terms also reach a project's local files and CI through ordinary sync. A kapi pull snapshots the workspace's governed concepts and their relations into the project's local terms store, and kapi check --ship then gates offline against exactly the terms the hub shows, the pattern documented in Gate governed terms in CI. A kapi push sends local term edits back: ordinary edits apply directly, and governed edits become a submitted change-set proposal. Edits from the hub and edits from a project follow the same separation of duties.

AI assistants retrieve the same approved context through the bowrain plugin's MCP tools: concept search, a concept's story and change-set status. An assistant works from the hub's terms.