Company Brain
Editorial guide

How to Tell Whether an Artifact Corpus Is Ready for Company Brain

You know the process knowledge is scattered. The harder question is what to bring first.

One folder has old SOPs. The helpdesk has years of tickets. Agents use private snippets. Important exceptions live in internal threads. A process owner remembers the real rule but has never written it down.

The wrong response is to upload everything.

A corpus is simply the bounded set of tickets, documents, macros, notes, transcripts, and related material chosen for one review. The files are often called artifacts because they are records left by the work the team already did.

A useful first source set belongs to one team or function, covers a related slice of work, and can be reviewed by one accountable person. It should be broad enough to reveal patterns and contradictions, but small enough to produce decisions instead of a company-wide cleanup project.

Use this readiness check before you start.

1. Can you name the team or function?

Good boundaries sound like:

  • support operations handling billing adjustments, access recovery, and bug triage
  • the team responsible for one sales-to-onboarding handoff
  • customer success operations for one lifecycle stage
  • RevOps handling one routing and exception process

Weak boundaries sound like “all company knowledge,” “our whole helpdesk,” or “everything in the drive.”

You do not need to name one recurring issue in advance. A refund process, handoff rule, or stale-macro problem can emerge as a narrow finding inside the broader team source set.

2. Is there a clear use for the result?

Do not gather material merely because documentation feels messy.

Name what a useful reviewed result would change this week:

  • replace an unreliable macro
  • clarify an escalation path
  • update an onboarding SOP
  • resolve inconsistent billing decisions
  • prepare approved guidance before an agent project
  • create a support training pack

A specific use helps the reviewer decide what matters and prevents the source set from expanding without a finish line.

3. Is there one accountable reviewer?

Choose the person who can decide whether the proposed guidance is current, safe, and reusable.

The reviewer may be a Support Operations Manager, Head of Support, onboarding owner, Customer Success Operations lead, RevOps owner, COO, or founder. The title matters less than the authority to:

  • approve a procedure or rule
  • edit weak guidance
  • reject unsupported behavior
  • keep an unresolved item open
  • decide which source wins when materials disagree

If nobody can make those decisions, the source set is not ready to become approved operating knowledge. It may still be useful for discovery, but not for final approval.

4. Do you have real cases as well as written guidance?

An SOP-only source set shows the intended process. A ticket-only source set shows behavior without enough policy context. The strongest first set usually mixes both.

Useful material includes:

  • recent routine cases
  • meaningful exception cases
  • current SOPs and suspected old drafts
  • support macros or saved replies
  • public help articles
  • escalation and ownership notes
  • selected CRM context that legitimately changes a decision
  • text call transcripts or handoff notes
  • exported Slack or Teams discussions

You do not need every source type. You need enough variety for the owner to see the standard path, the important exceptions, and the places where guidance conflicts.

5. Is the size reviewable?

There is no magic file or ticket count.

The set is too small when it contains only one polished document and no real examples. It is too large when the reviewer cannot explain what work it covers or recognize whether something important is missing.

Prefer a representative slice over a full workspace dump. Include common cases, edge cases, current guidance, and sources agents still encounter even if they may be stale.

6. Are the inputs readable?

For the current trial, you can paste text or upload supported files.

Browser-readable extraction covers text-like formats such as TXT, Markdown, CSV, JSON, HTML, VTT, and SRT; text-layer PDFs with selectable text; readable DOCX files; and supported text-like entries inside ZIP files.

Scanned or image-only PDFs are not OCRed. Empty, corrupt, password-protected, or image-only documents may not produce text. Unsupported, unsafe, encrypted, nested, corrupt, or overly large ZIP content should be skipped or rejected visibly, not treated as though it was read.

Check a few important files before relying on them. If a key policy exists only as a scan, provide a readable version or leave the missing source visible for review.

7. Is the material allowed?

Ordinary confidential operational material is allowed for one bounded team or function source set. You should not have to manually sanitize normal business documents merely to make the trial useful.

Keep restricted material out:

  • secrets and credentials
  • payment data
  • regulated health, legal, or financial data
  • private employee records such as performance, disciplinary, payroll, medical, or immigration information
  • highly confidential strategy
  • special-compliance material
  • anything the organization cannot share under its own obligations

If the process depends on restricted material, do not force it into the trial. Choose a different operating slice or use guided scoping.

8. Can you preserve the boundary when sources are connected?

A connected source should reduce collection work, not erase scope.

The owner should still be able to select a queue, view, tags, date range, folder, or similarly narrow boundary. The source inventory should preserve record identity and make partial, stale, failed, or revoked imports visible.

Do not treat connection access as permission to ingest everything the account can see.

Ready, needs scoping, or not suitable

Your source set is ready when it has one clear team or function, a related operating slice, representative evidence, one accountable reviewer, and a concrete use.

It needs scoping when the pain is real but the boundary, source selection, reviewer, or intended use remains vague.

It is not suitable for the current trial when it requires restricted material, whole-company ingestion, unsupported inputs that contain the critical evidence, or a review decision nobody can own.

How Company Brain fits

Company Brain turns one ready source set into a draft operational knowledge pack containing proposed SOPs, decision and escalation rules, macro drafts, internal FAQ entries, gaps, conflicts, outdated-content flags, and open questions.

One named owner reviews the result and can approve, edit, reject, or mark items as needing work before export. The product does not require a pre-named recurring issue or a fixed number of files.

For more help drawing the boundary, read start with one bounded team corpus. To see the end product, read what a reviewed operational knowledge pack looks like.

The next step

If you can name the team, intended use, reviewer, and representative source material, start the free trial.

If one of those pieces is still unclear, apply for guided scoping before uploading a large or unfocused source set.