Retrieval-grade chunks

Every AI integration does the same four things: fetch markdown, split it, embed it, store it. The splitting step decides retrieval quality, and it is the step done worst — a splitter reading markdown can only guess at ## and hope.

We know which parts are atomic. Ask us to split it.

GET /api/orgs/{orgId}/spaces/{spaceId}/items/{itemId}/chunks

{
  "chunks": [
    {
      "chunkId": "8f2c…:steps:0",
      "slot": "steps",
      "role": "resolution",
      "headingPath": ["Disk full on deploy", "steps"],
      "text": "1. SSH to the node…",
      "tokens": 412,
      "contentHash": "1a2b3c4d…",
      "atomic": true
    }
  ],
  "policy": { "version": "2026-09-01", "maxTokens": 512 }
}

The policy is a contract

Once you store a chunkId, how we split is a public interface: changing it would invalidate every vector store built on it, at once and silently. So it is versioned from the first release and travels in every response. A change to policy.version is a breaking change, announced like any other.

What we deliberately do not do

We do not host embeddings or run a vector store. You would be trading a clean content API for an infrastructure dependency, and there are better vector databases than any we would write. Chunks are the useful half.

We also do not offer a chunking configuration UI. The value here is that we hold the opinion about what is atomic; a settings page hands that decision to somebody who does not want it.