Kernels

1. 1Fork. Kernels → Catalog → Your kernels → Fork a kernel. Pick the closest of the eight, or one of your own, and name the copy. Only your organization sees it. Or start from scratch: a name and a voice is a whole kernel. configure_kernel, create_kernel
2. 2Tune the voice. Register: casual or authoritative. Humor: off, or on with 1 to 5 devices per piece. Framing: inquisitive or declarative. Notes (up to 2,000 characters): your terminology, facts to get right, what to avoid; written into the voice itself. A note that is really a setting ("make it funnier") is offered back as that setting. update_kernel, suggest_kernel_voice_settings
3. 3Add your own evals. An eval is a detector (sentence-regex, char-set, heading-regex, word-list, structure, distribution, llm-judge or hybrid) plus an optional fix. With a fix it repairs what it finds; without one it only measures. Every new eval is filed for review and runs once a person activates it. add_kernel_custom_eval, remove_kernel_custom_eval
4. 4Edit the file. Everything else (the writer, which rules repair, measure or stay off, the effort) is the kernel file, under Kernel file on the kernel's page. Save a change as a candidate: nothing changes until it is live. Once you write the voice as text, the voice settings stop applying. get_kernel_file, save_kernel_file, get_kernel_file_schema
5. 5Test it. Test this kernel, on its page, writes from a real brief with the live version or a candidate, and shows every pass. The Studio runs the same brief through different kernels side by side. Each test spends one kernel run. start_kernel_studio_run, get_kernel_studio_run
6. 6Use it. Make a tested candidate live; making an earlier version live rolls back. Make the kernel your organization's default, or bind it to an endpoint. When the kernel you forked improves, your copy doesn't change: the update arrives as an offer you accept or ignore. promote_kernel_version, set_org_writing_kernel, accept_kernel_offer

Underneath the settings, a kernel version is one JSON file (Kernel file on the kernel's page; schema at /api/schema/kernel). Only name and voice are required; voice is one text, or named paragraphs kept in the order you write them.

{
  "name": "Letterstory",
  "writer": "claude-sonnet-5",
  "voice": {
    "tone": "Plain, specific, a little dry.",
    "audience": "Content and growth teams. No hype."
  },
  "register": "authoritative",
  "humor": false,
  "inquisitive": false,
  "person": "first_plural",
  "rules": {
    "system-rarity": "repair",
    "plainly-tic": "off",
    "letterstory-buzzwords": {
      "mode": "repair",
      "name": "Buzzwords",
      "detector": { "kind": "word-list", "words": ["synergy", "leverage"] },
      "fix": "Say what it does instead."
    }
  },
  "effort": { "rounds": 3, "samples": 3, "floor": 6 }
}

The system rules are ids in rules like any other, each with a limit on how far it turns down.

Only name and voice are required; the rest uses platform settings. Every save is a new, unchangeable version. rules sets each check to repair, measure or off; effort sets passes, drafts and the bar. Use ours, fork ours, or bring your own.

A per-call field wins over the endpoint's defaults, field by field. entities take a treatment (never, mention_once, mention_often, lead_company) plus linkable, so how a client or competitor is named is data, not prose you write. directives guide how to write, never what is true. config_patch changes a kernel setting for one run without saving a version.

1. 1Decompose. The brief becomes claims, each with the evidence it needs. Every input is written fresh, never edited in place; your images, tables and embeds are held and put back under the heading they came from. A brief too thin to write from is refused before any model call.
2. 2Draft. Written in the kernel's voice, inside its constraints. The first pass writes several drafts (effort.samples) and keeps the best.
3. 3Repair. Each rule the kernel lists finds and fixes its own pattern, on every pass. No call turns a rule off.
4. 4Judge. A team of adversarial judges (three editors) scores every pass on commitment, economy and movement, out of 9. Below the bar (effort.floor), it goes again, up to effort.rounds passes, and the best pass ships. The judges are the platform's, the same for every kernel and every writer, so a score means the same thing whoever wrote.
5. 5Verify. Names and figures must come from your input, and the brief is never echoed back. The record then checks the draft that ships against your input: every claim, every held block, every heading.

A constraint you didn't set is recorded as skipped, never as a pass.

CLI: letterstory kernel write

Metered in runs. Direct API runs draw kernel run credits; runs Letterstory makes for you come out of your plan.