Skip to main content
Every document records the processing revision that successfully completed for OCR, content extraction, and optional LLM classification:
  • pipeline_version_ocr
  • pipeline_version_content
  • pipeline_version_llm
The binary carries the current revision for each pipeline. Maintainers bump a revision when code, a prompt, an output schema, or another processing contract changes enough that older results may be worth regenerating.

​
Version zero

Version 0 means the pipeline has never completed successfully for that document. A failed LLM request therefore remains at 0. A valid low-confidence response is still a completed classification: Suchi adds the needs-review tag and records the current LLM revision without applying its uncertain metadata. Dates use their own scores independently: a high-scoring, source-backed date may still be accepted in automatic mode even when document metadata needs review. A later successful classification at or above the configured threshold clears an earlier classifier-owned needs-review assignment if the new result does not request that tag. It does not remove manual, rule-assigned, imported, or legacy tags without recorded classifier ownership. A changed title alone does not establish confidence; failed requests and low-confidence results retain the tag. This distinction matters when the LLM is first enabled. Existing version-zero documents are not automatically presented as outdated LLM results because they have no prior LLM result to upgrade. Select the documents in Documents and use Rescan when you want to classify them.

​
Automatic proposals

Automatic proposal detection follows the per-pipeline recommendation thresholds committed in distro/cmd/suchi/pipeline_proposals.go. Zero, the default, creates no new reminder for that pipeline. When a processing revision is worth offering to existing archives, maintainers set that pipeline’s threshold to the current revision before creating the release tag. The tag therefore determines the behavior of source builds, release binaries and both container images; there is no workflow input or runtime setting that can produce two policies for one tag. On boot, Suchi compares stored revisions with each positive recommendation. Detection, eligibility and documentless approval runs are scoped independently to each filing system. Global pipeline/OCR/LLM configuration does not make a proposal or --system S02 rescan apply to another system. When previously processed results are older, the detector opens one admin approval per affected pipeline and system. A zero threshold does not create a new reminder. The recommendation may remain at an earlier revision when a later processing change is not itself worth prompting. In that case only documents below the committed threshold are offered; approving the proposal runs those documents through the binary’s current pipeline. A recommendation cannot exceed the current processing revision, and invalid tagged policy stops startup with an explicit error. The main.rescan.policy startup log records all three effective thresholds. For LLM classification, automatic proposals only include documents with a successful earlier revision (pipeline_version_llm >= 1). Enabling the LLM or changing its endpoint, model, key, timeout, threshold, egress setting or shared application mode does not create a proposal. New ingests and explicitly requested rescans use the current mode and thresholds. Startup and settings saves never bulk-accept pending suggestions; rescans preserve accepted/rejected date history. Password-protected PDFs waiting for decryption are also excluded. A rescan cannot advance them while the password gate is closed; supplying a password already re-enqueues the document through the current pipeline. The proposal in Approvals names the improved processing step and matching document count, without displaying internal revision numbers. Its actions are:
  • Rescan all N: enqueue every matching document.
  • Try 20 first: enqueue up to 20 random matches. This only appears when more than 20 documents match.
  • Dismiss: close this proposal without enqueuing work.
The underlying approval choices remain approve_all, approve_sample, and dismiss; the web app presents human labels. Rescans use the same durable post-ingest path as new uploads, so a process interruption does not lose the work. Dismissed proposals stay closed for that pipeline’s recommended revision across restarts. The detector honors saved dismissals and closes duplicate proposals left by older builds; explicitly approved work still runs. Raising one committed recommendation can create a fresh proposal for that pipeline without opting in the other pipelines. Setting a threshold to zero, or lowering it, does not cancel or hide a newer unresolved reminder. If another rescan brings the matching count to zero, a later boot with the same or a higher positive threshold cancels the obsolete open proposal.

​
Explicit rescans

Camera-image fixes correct EXIF orientation and the page density of image-derived PDFs, and retry difficult QR codes when local ZBar is available. They retain content revision 2; existing revision-2 documents need an explicit selected rescan. OCR revision 2 adds one sparse-text retry for empty pages and a confidence-filtered sparse supplement for raster images in the lightweight engine. The existing approval path offers older OCR results for rescan. Original images remain available even when an earlier installation stored invalid derived bytes or skipped conversion. Select affected images in Documents and choose Rescan, or accept the relevant proposal, to regenerate their archive and indexed text from the immutable original. Upgrading alone does not repair previously processed images. Use the Documents selection controls for ordinary operator-driven rescans. The CLI provides narrower filters and dry runs:
Unlike automatic LLM upgrade proposals, --stale llm includes version-zero documents. This is intentional because the command is an explicit operator decision.

​
Failures

Exhausted or terminal jobs appear in the Processing issues tab of Approvals. Correct the underlying problem, then choose Retry to run the same processing step again. Choose Dismiss when the failure was expected or no longer needs attention. Raw job names and error text are available under Technical details. Both actions are administrator-only and audited; dismissing a processing issue does not delete its document. Related pages: LLM classifier, Approvals, CLI, and Automations.