Skip to main content

Context scan

A context scan reads material your team has already written and proposes the axes the content varies along, a voice profile draft and candidate terms. You review and correct a first draft instead of writing one. A proposal takes effect only when you approve it in the Context hub, with the same correction loop that keeps the context current later.

A scan runs before any bring-your-own provider key exists, so it always uses platform AI credits. The credits it spends are reported on the job as it runs.

The flow​

A scan reads the sources you give it, assembles them into one corpus, and proposes what it found: the axes, a voice profile drafted from the corpus, and extracted term candidates. Each proposal is approved on its own.

Sourcespaste, URL, upload, git reporead sourcesCorpusassembled + source-taggedproposeAxesthe dimensions content varies alonginferVoice profile drafttone, style, vocabulary, examplesextract termsTerm candidatesterm + definition + domainreturn proposalsReviewapprove each, then it governs

A scan reads sources into one corpus and proposes axes, a voice profile and term candidates. Nothing governs until a person approves it.

The scan runs as a background job. Creating one returns a job id. Poll the scan until it reports completed, then read its proposals. The lifecycle is queued → processing → completed (or failed), and while processing the job reports a progress percentage and a phase label: reading sources, assembling the corpus, drafting the voice, extracting terms.

Sources​

A scan accepts any combination of four source kinds, assembled into a single source-tagged corpus:

  • Paste: copy or a style guide pasted directly as text.
  • URL: public web pages the scan fetches and reads as text. The scan fetches only https URLs and refuses private, loopback and link-local addresses, checking again on every redirect. A scan therefore cannot reach internal infrastructure.
  • Upload: documents uploaded ahead of the scan. Bowrain checks each upload against a list of text-bearing formats before storing it, and reports any unsupported file back to you. Per-file and per-batch size limits apply. Stored uploads are kept for a retention window, so a "regenerate" during review can reuse the same files.
  • Git repository: a public https git repository. The scan reads its Markdown files.

The corpus has a total size budget. A scan reports which sources it read and which it skipped, so you can see when it trimmed the corpus to fit.

What a scan proposes​

Axes​

A scan proposes the dimensions the corpus's content varies along: a brand, a mode (tutorial, how-to, reference, explanation), a market, or another axis the project has not yet named. An axis changes the shape of the context, so you approve it separately from anything that sits on it.

Bowrain records an approved axis as a pending recipe change. On a project connected from a checkout, the next kapi pull writes defaults.coordinates.<axis> into kapi.yaml for review in git. The axis exists once that change is committed and a push carries content at it. You approve a structural axis, a product or a channel, against a particular collection, because a scan reads a corpus and has no way to tell which collection it belongs to. It lands as that collection's channel:. Only the recipe creates a coordinate.

Voice profile​

The scan drafts a voice profile with the same shape a hand-authored one has: tone (personality, formality, emotion, humour), style rules (active voice, sentence length, point of view, contractions, prohibited patterns), vocabulary (preferred, forbidden, and competitor terms), and before/after examples. The draft's name marks it as needing review.

Each inferred section carries evidence: a confidence score and a short note citing what in the corpus supports it. A reviewer can weigh each section on its own. The evidence is kept separate from the profile, so the profile stays in the ordinary profile format.

Term candidates​

Alongside the voice profile, the scan extracts term candidates: terms found in the corpus, each with an optional definition and domain, deduplicated and merged with the profile's preferred terms. They are candidates for the terms explorer. You adopt them as concepts in a separate step.

Review, then approve​

A scan produces proposals, and a person approves each one in a separate action. The separation between curation and governance applies from the first profile.

Youmanage_voiceContext scanasync jobContextaxes + profiles + termscreate scan from sourcesread → propose → infer → extractspends platform creditsreturn proposals + evidenceapprove an axisa recipe change, delivered by pulltest edited draft against sample textno AI costadopt: save profile at its point, promote terms

A scan returns proposals you review. An approved axis reaches the recipe through pull; an adopted profile is bound at its point; promoted terms become concepts.

While reviewing, you can test a draft against a sample of your own text. The scan scores the sample against the draft profile, including your edits, with a rule-based vocabulary match. The test makes no AI call and costs no credits, so you can adjust the draft and see the effect before you adopt it.

When the draft is ready, save the edited profile as a voice profile bound at the point it governs, and promote the term candidates in the terms explorer.

Credits and quota​

A workspace runs its first scan before anyone configures a bring-your-own provider key, so a scan always runs on platform AI credits. These follow the same credits model as the platform's other AI operations. Bowrain refuses a scan up front if the workspace has no spendable credits. The credits a scan spends (one credit per token) are metered per phase and reported on the job as tokens_used. A self-hosted deployment with billing disabled deducts no credits. Approving an axis is free.