Authoritative documentation · English

Processing

Processing turns committed Notes and imported Documents into validated knowledge through one unified queue. Sources, OCR, committed Notes, and rebuilds all flow through the same priority-ordered, resumable pipeline with a visible stage, progress, and device boundary.

The unified processing queue

Every unit of work — a source import, an OCR run, a Note extraction, a rebuild — is admitted to one queue with an explicit priority, stage, and status. The queue exposes:

• Priority and stage — what runs next and what phase it is in.
• Progress and ready candidates — how far a run has advanced and which candidates are already available.
• Pause reason — why work paused, including budget ceilings and operator action.
• Device boundary — confirmation that OCR, retrieval, and discovery run locally.
• Retry, pause/resume, cancellation, and checkpoints — resumable, cancellable work that survives interruption.

Progressive Preview

A working Preview answers from the first durable candidate while remaining work continues. You do not wait for the entire corpus to finish before the Book becomes queryable. Preview reflects current admissible working knowledge and is never production; Published chat pins a separately activated immutable release.

Changed blocks and exact duplicates

Changed Notes and changed sources process only their changed blocks; unchanged blocks are not reprocessed. Exact duplicate imports create no repeated billable generation. Processing cost stays proportional to what actually changed.

Providers and budgets during a run

Select a reviewed provider profile explicitly before generation; Harnesser never silently falls back to another provider or model. Set token and cost budgets before a run. A failed or uncertain request retains its conservative reservation until reconciled, and work pauses before its conservative ceiling. Every external operation sends a bounded, explicitly selected slice of plaintext — never the whole Book.

Boundaries to keep visible

Processing never validates, publishes, activates, withdraws, or deletes on its own. Candidates become answers only through human validation, and a release becomes production only through explicit publication and activation.