Feed content to your AI

Goal: turn any document (Word, PDF, JSON, Markdown, HTML) into a stream of clean, anchored content blocks an AI assistant or RAG pipeline can read without knowing anything about the source format. No translation is involved. Every block carries a reference (ref: its document and its key) and the revision of its text (rev), so an edit produced later can be written back to the same block with the surrounding markup intact, and refused if the block changed in between. Concepts: Content model, Checks.

Desktop

In Kapi Desktop you check what your AI will read before you index it:

1. See what your AI will see. Open a file in your project: the Blocks view lists the blocks kapi inspect reads, each with its text and structural role and the surrounding markup stripped away.
2. Judge the parse before you index. Preview (plus Structure and Layout where the format carries them) shows whether headings, tables, and reading order came through. A parse problem is cheaper to fix here than after it shows up in retrieval.
3. Then stream. The feed itself is kapi inspect --jsonl (CLI tab), or a connected assistant reading blocks directly (Agent tab).

Agent (Claude)

A connected assistant needs no export step: the MCP tools are the feed:

• read_blocks reads the anchored blocks of any file it is pointed at, a page at a time;
• check_file returns the structured kapi.check/v2 Report, one finding per block;
• apply_edits writes revisions back through the round-trip, each guarded by the revision read_blocks reported.

You describe the outcome ("read the contract and flag every clause that mentions liability") and the assistant reads the blocks, with no markup to strip.

CLI

Survey first. kapi stats sizes the job (blocks, words, characters, a breakdown by structural role) to estimate token budget and decide how to chunk:

kapi stats --json report.docx docs/*.md | jq '.total.words'

Extract blocks with anchors. kapi inspect emits one record per block: the block's ref and rev, the text with inline codes as <x id="…"/> placeholders, the structural role and the nesting level. A Word document, a JSON catalog and a Markdown page all yield the same record shape. --jsonl streams one object per line for pipelines; -f declares the format when detection is ambiguous:

kapi inspect --jsonl report.docx docs/*.md | \
  jq -c '{doc: .ref.doc, block: .ref.block, role: .role, text: .text}'
cat page.html | kapi inspect -f html --jsonl

Write back; check any time. kapi apply lands an assistant's edits on the original blocks by reference; kapi check returns findings a program can act on (exit 0 pass, 3 gate tripped, --no-fail for fix-loops):

kapi apply edits.json --dry-run           # review before writing
kapi check report.docx --max-chars 300 --forbid "TODO"

An edit to a block that changed since you read it, or that would corrupt an inline code, is refused; Edit content documents the change set's shape and what refuses an edit.

In a project

In a kapi project, kapi stats, kapi inspect, and kapi check with no file argument survey every source the recipe declares. A block's reference is its project-relative path and its key, which stays the same across runs while the block is there, so an assistant indexing your project can retrieve and rewrite the same blocks over time.

Further reading

• Edit content: the inspect → edit → apply loop and the preservation contract.
• MCP server: every structured tool behind the same loop.
• What gets translated: when your goal is translation.