Version 0.5.1. Host-executed procedure for `kb-ingest`; not a background scheduler. Follow the contribution protocol for budgets, checkpoints and retry identity.
| Context | User-selected material, explicit project and `get_project_context` lens | Objective, authorized project lens including four default research lenses and saved guidance, scope, run identity and pinned pack versions | Required tools/schema are available; otherwise report blocked. |
| Capture | Explicitly selected local files, user-pasted text or an allowlisted public URL | Verified artifact digest, stable source ID, content-bound revision ID, metadata candidate and extraction availability | Use the connector for local files, `source_capture_text` for explicitly supplied UTF-8 text/Markdown (maximum 1 MB), or `source_capture_url` for a configured public host. Pasted text requires a stable capture ID and source key, and returns an archived artifact, extraction and candidate marked `pasted-text`; retry with the same ID and identical inputs after uncertainty, since changed inputs conflict. The service retains at most 1,024 private capture receipts. The capture does not register the source. The connector returns a typed `source_candidate`; `.vtt` and `.srt` files are parsed into cue-timed blocks and tagged `transcript`. Cite the precise cue times together with the quote span. The connector can record a declared NotebookLM export provenance for supported text, Markdown or PDF files, but does not verify that provenance; omit `source_revision_id` to derive a revision from file identity, content digest and its durable retry checkpoint, or supply a stable revision ID when resuming an existing workflow. Submit candidates through `proposal_submit`; staging alone does not register a source. Failed fetches return a `capture-failed` candidate without artifact bytes; register it only when a bookmark is useful. PDF extraction currently requires the supported Linux sandbox. HTML citations refer to visible extracted text, not markup-byte offsets. |
| Budget checkpoint | Current source stage and run budget | Per-source coverage checkpoint, remaining file/section plan and resume point | Process one source at a time. Use metadata to target relevant bounded slices; retain concise notes and exact evidence excerpts, not full source text. Checkpoint after each source. If quota or tool budget is near exhaustion, save the exact resume point and report remaining coverage without dropping a research lens. |
| Triage | Source plus project lens and four default lenses (technical, conceptual, cultural-historical, financial-market) | Included sections, explicit clear-exclusion reasons and review flags | Treat lenses as coverage prompts, not quotas. Historical, philosophical, cultural or commercial evidence is not automatically out of scope. Exclude only clearly unrelated or unavailable material, or user-excluded topics. Continue normal evidence-backed proposal processing for plausible material; add `ingest_review_create` as a follow-up notification/filter flag when human relevance review would help. |
| Duplicate check | Candidate findings and explicit readable project/shared scope | Existing-node candidates, reuse/update decision, or explicit unresolved-review flag | Before creating a node, run multiple lexical searches over its title, distinctive terms and likely synonyms, then inspect plausible matches with `get_node`. Reuse the stable node ID and preserve supported content for a true update; do not create a second node when it represents the same concept. Keep materially distinct conditions as distinct records. The backend flags exact entity name/alias matches only and does not deduplicate other node types. |
| Extract | Included sections and immutable maps | Atomic proposal draft with field-level evidence | Read captured source text with bounded `source_extraction_block` calls, using exact extraction and block IDs; inspect relevant pages/sections even when the host cannot directly open a PDF. Use the normalized text and offsets returned by the service for exact quotes/locators. Record partial/unavailable coverage; upload or extraction alone is not analysis. |
| Online verify (when task/project enabled) | Selected claims and bounded search/page-read budget | Short `OnlineEvidence` excerpts with relation/context and verification URLs, stored in the normal `update_node` proposal | Follow the [online verification protocol](../protocols/ONLINE_VERIFICATION.md). Search for support and counterevidence; open pages before recording text; preserve archived support assessment; never upload/register a web page. |
| Proposal grouping | Assessed findings across captured sources | Small, coherent learning bundles with source dependencies | Treat documents as capture/provenance units and proposals as semantic learning units. Group by one project question or a tightly related set of findings, combining evidence across files when it supports the same learning. Do not create one proposal per file or one oversized proposal for the whole packet. Keep unrelated learnings separate so each can be evaluated, retried, reviewed and accepted independently. Include each new source candidate as `register_source` in the first proposal that cites it; after acceptance makes that revision readable, later proposals cite the accepted revision without registering it again. |
| Evaluate | Complete bounded bundle and base revision | `proposal_evaluate` findings and eligible status | Evaluation is read-only; it does not reserve an ID or store the proposal. |
| Submit | Evaluated bounded bundle and stable proposal identity | `proposal_submit` outcome and eventual receipt | Every affected domain's policy applies; protected decisions remain external. |
| Human review | Stored review flag and authorized editor/admin decision | Include, exclude or defer feedback; optionally saved project/lens guidance | The flag never blocks proposal evaluation/submission or marks knowledge accepted. Decisions are feedback only. Save reusable guidance only on explicit reviewer opt-in. |
| Report | `proposal_status`, receipts, review flags and coverage records | Accepted/held work, review notifications, index state, limitations and resume point | Never equate upload, evaluation, review-flag creation or partial acceptance with complete processing. |
Resume calls `source_upload_status` or `proposal_status` using the exact checkpointed ID and revision before returning to a stage. Changed assertion/evidence invalidates assessment and later stages. Correct only actionable findings; repeated identical failure stops for diagnosis. Pipeline instructions may be replaced independently of the skill's extraction criteria if these input/output and recovery obligations remain valid.
