Demo modeBrowser-only synthetic Paperless, Ollama and OCR data.Try:
Overview
System overview and current configuration
Loading…Loading…
About the Control Center
Configure connections, OCR, classification and tagging here. Prompt previews and model tests are read-only for the selected Paperless document. Deployment secrets and container-level settings remain outside this UI.
Paperless-ngx
Checking…
Loading…
Ollama
Checking…
Loading…
OCR
Loading…
Loading…
Tagging
Loading…
Loading…
Pipeline
Paperless remains the document system of record. paperless-local-ai improves scanned-page OCR, then applies local metadata automation.
1
Paperless import
Paperless consumes the original and decides through OCRmyPDF which pages actually need OCR.
2
PaddleOCR for scanned pages
Only pages that need OCR are sent to the local OCR service. Native-text pages are not sent to PaddleOCR.
3
Metadata queue
A Paperless Document Added workflow assigns the configured classification queue tag. The metadata worker picks up the document after import and OCR have finished.
4
Tag routing
Hybrid tagging first checks reviewed Paperless documents for a high-confidence complete tag-set match. Otherwise the LLM decides tags; LLM direct always lets the model decide.
5
One structured LLM request
The model returns title, document type, date and the actual sender/issuer. It also returns tags when the selected tagging route needs an LLM decision.
6
Local sender resolution
The extracted sender is matched conservatively to existing Paperless correspondents. If the optional Suggestions integration is configured, a plausible new sender can be exposed in Paperless Document Suggestions; no second LLM call is needed.
7
Human review in Paperless
Check the generated metadata, then remove the configured review tag. Only documents that have left the review, queue and error tags become trusted Hybrid history.
Current configuration
Metadata writesLoading…
Classification modelLoading…
Context windowLoading…
Tagging strategyLoading…
PaddleOCR modelLoading…
Maximum OCR image sideLoading…
Document classification
Configure the LLM request for title, document type, date and sender. Tag selection follows the strategy under Tagging; sender names are resolved against Paperless after the model call.
Loading…
Saved configuration loaded.
What do Check and Save do?
Check configuration validates the visible draft without saving. Save changes creates a new version used by the next automatic classification job. No restart is required.
i
Safe test with a real document. Preview shows the exact routing decision and prompts without calling Ollama. Run model test additionally performs the real structured request. Neither action changes the selected Paperless document or creates a correspondent suggestion.
Numeric ID from the Paperless document URL, e.g. /documents/123/details.
CPU-only model tests can take tens of seconds to several minutes depending on prompt size. OCR and LLM inference share one resource lock, so a test may also wait for another heavy AI task.
Ready for prompt preview or model test.
Classification result
Shows the final result after history routing and local correspondent resolution. Raw details remain below.
Run a model test to see the classification result.
Tagging route
Explains whether the tag set came from reviewed history or from the LLM.
Run Preview prompts or Run model test to populate this section.
Request details
Run Preview prompts or Run model test to populate this section.
System message sent to the model
Run Preview prompts or Run model test to populate this section.
User message sent to the model
Run Preview prompts or Run model test to populate this section.
Technical model result
How tagging works
Hybrid tagging combines reviewed-document similarity with an LLM fallback. Tag guidance is separate: it describes your filing rules only when the LLM chooses tags. Read the tagging design on GitHub.
Tagging strategy
Choose how content tags are decided. Title, document type, date and sender still use the configured LLM.
Why is Hybrid tagging recommended for small models? Compact models can understand a document while still applying a personal taxonomy inconsistently. Hybrid tagging reuses reviewed decisions only behind a strict evidence gate and sends uncertain cases to the LLM. Technical rationale.
History health
Built from documents whose configured review tag has been removed after human review. Documents still carrying the classification queue or error tag are excluded. The index checks for changes at most every five minutes when used.
Loading history status…
Reviewed documents—
Tags represented—
Retrospective history reuse—
Potential inconsistencies—
Retrospective history reuse is a leave-one-out check of reviewed documents, not a prediction of future accuracy.
Last updated: —
Advanced History matching
Controls when Hybrid tagging may reuse a complete reviewed leaf-tag set. Lower values increase automatic reuse but also increase the risk of a wrong tag set. Detailed behavior ↗
The closest reviewed document must reach this similarity before its complete tag set can be reused.
How many of the five nearest reviewed documents must use the winning complete tag set.
Required similarity-weighted vote share for the winning complete tag set.
Saved values loaded.
History depth by tag
History depth measures available reviewed examples, not accuracy. More examples make recurring patterns more likely to be represented, but do not guarantee a confident match.
No history: 0 · Very limited: 1 · Limited: 2–4 · Good: 5–9 · Strong: 10+
Loading…
Potential tag inconsistencies
This is a review hint, not an error detector. It shows groups of at least three reviewed documents whose full text is strongly similar but whose current leaf-tag assignments differ. Similar documents can legitimately require different tags, and these findings never change existing tags automatically.
How is this detected?
The diagnostic uses the same full-text word + character TF-IDF representation as Hybrid retrieval. It uses complete-linkage clustering with a minimum within-group similarity of 0.50 and shows a group only when multiple leaf-tag assignments are present.
Loading…
Tag guidance
Optional descriptions for how the LLM should interpret each current Paperless tag. Guidance is supplied on Hybrid fallback and LLM direct routes. A confident Hybrid match does not send Tag Guidance to the model.
Fields are generated from current Paperless tags and stored by tag ID, so a renamed tag keeps its guidance. Empty fields add nothing to the Tagging prompt.
Loading Paperless tags…
What is edited here?
All model instructions are editable. System and Base classification are always sent. The Tagging prompt is appended only when the LLM is responsible for tags. On a confident Hybrid match the Tagging prompt and the tags schema field are omitted entirely. Preview shows the exact final request.
Replaces all three visible prompt fields in the draft. Save to activate.
Used only when the LLM chooses tags. Hybrid fallback can inject Tag Guidance and relevant reviewed examples through placeholders. How prompt composition works.
Available placeholders
{{DOCUMENT_TEXT}} is required in the Base classification prompt. Tag-specific placeholders belong in the Tagging prompt so a confident Hybrid route can omit tagging completely.
What is shown here?
The structured schema is generated for each request. Document type and LLM-selected tags are constrained to current Paperless values. Correspondent is free text because the application resolves the extracted sender afterwards. A confident Hybrid route omits the Tagging prompt and the tags schema property entirely because the reviewed tag is already known.
Output schema
Run Preview prompts or Run model test to populate this section.
Current Paperless taxonomy
Run Preview prompts or Run model test to populate this section.
About these settings
These settings control the one classification LLM request. The tagging strategy and per-tag guidance are configured separately under Tagging.
Model and document input
Exact name of a model already installed in Ollama, e.g. qwen3.5:4b.
Maximum context available to Ollama. Larger values use more RAM and allow larger prompts; actual runtime mainly follows the prompt tokens used.
Maximum Paperless document text sent to the LLM. Longer text is truncated using the beginning/end ratio below.
Used only when the LLM is responsible for the tag decision.
Advanced model settings
Maximum size of the generated structured response. This does not limit input or document text.
Controls output randomness. The CPU reference configuration uses 0.
Enables model thinking when supported and can substantially increase latency.
Ollama request keep-alive hint. The metadata worker explicitly unloads the model after a completed classification job.
Used only when document text exceeds the limit. 0.80 keeps 80% from the beginning and 20% from the end.
Maximum time to wait for the Ollama classification request.
What is versioned?
Prompts, model settings, tagging strategy and per-tag guidance are saved together. Restoring an older version creates a new current version; existing history remains intact.
Saved versions
App Settings
Configure Paperless and Ollama connections, workflow tags, correspondent matching, OCR and runtime behavior. These settings are versioned and hot-reloaded; ports, volumes, resource limits and secrets remain deployment settings.
Loading…
Saved configuration loaded.
About connections
URLs must be reachable from the app containers. The Paperless token is a deployment secret and is never shown or stored in versioned UI configuration.
Paperless-ngx
Loading…
Ollama
Not tested yet.
Paperless shortcut
Adds a paperless-local-ai button to the Paperless Settings header. Requires two environment variables in Paperless. Setup guide ↗
Checking Paperless setup…
Pipeline & tags
These names must match existing Paperless tags exactly. The classification queue starts metadata processing; the error tag marks failures; the review tag marks documents awaiting human review and is the Hybrid trust boundary. The review tag can have any name. The recommended Paperless setup marks the chosen review tag as an Inbox tag so Paperless adds it on import. Paperless setup.
Must match an existing Paperless tag exactly.
Must match an existing Paperless tag exactly.
Keep this tag on the document until human review is complete. Removing it makes the document eligible for trusted Hybrid history once queue/error tags are also gone.
Comma-separated. These tags are not offered as content-tag candidates and are preserved during metadata write-back, e.g. TODO.
i
Exact matches stay exact. The sender extracted by the LLM is normalized first. A unique normalized exact match is applied without fuzzy thresholds. The settings below are used only when no exact match exists.
Correspondent matching
A fuzzy match is applied automatically only when both conditions pass. The default uses 91% minimum similarity with the existing 4 pp ambiguity margin.
How similar the extracted sender must be to the best existing Paperless correspondent. Lower = more permissive and accepts more name variation. Higher = more conservative and reduces the risk of matching different senders.
How much better the best candidate must score than the second-best candidate. This blocks ambiguous cases even when the best score itself is high. Lower = accepts more ambiguity. Higher = requires a clearer winner.
These values are saved with App Settings and used by the next classification job.
Test correspondent matching
Try an extracted sender name against the current Paperless correspondents using the unsaved values above. The test is read-only: it does not call Ollama, create a correspondent, or modify a Paperless document.
Enter a sender name to see the three closest current correspondents and the exact decision.
OCR behavior
These settings affect scanned-page OCR only. The original and archive PDFs are never resized by this setting. Maximum OCR image side is the main OCR memory control; automatic retries recover from temporary OCR process/service failures.
Longest side of the temporary OCR raster. Default 3000 px. Lower this first if OCR is memory-limited; the original/archive document is unchanged.
CPU is the tested reference configuration; other devices are currently unverified.
Delay before each retry in seconds. Empty disables automatic retries.
OCR recovery
Temporary failures are retried automatically according to the configured schedule.
Loading…
Loading…
Technical detailsRecent OCR failures (0)
No OCR failures recorded.
Runtime behavior
Dry run is an optional test mode. Classification still runs, but document metadata and persistent new-correspondent review records are not written. Technical workflow/error tags may still change. OCR remains part of Paperless import and is unaffected.
Metadata writes
Default is Off. Enable Dry Run temporarily when you want to inspect classification behavior without writing document metadata.
Advanced worker settings
Seconds between checks for documents carrying the classification queue tag.
Seconds between cleanup checks for stored new-correspondent review records after documents leave the configured review tag.
Versioned app settings
Every save keeps the previous state in history. Restoring creates a new current version.
Saved versions
Document Chat
Configure how Document Chat generates answers, retrieves relevant passages and maintains its local search index.
Loading…
Loading configuration…
Chat defaults
Defaults for new chats. Per-chat controls in Paperless can override the supported generation settings without changing these saved defaults.
Ollama model used to generate the final answer.
Used for date and time variables in the system prompt.
Sent on every chat turn. Variables are resolved at request time.
Variables
Advanced prompt assembly
Controls how much previous conversation the answer model receives and the final user-message wrapper built around retrieved excerpts. These settings do not change embeddings or require an index rebuild.
Maximum number of previous user and assistant messages sent to the answer model. 0 makes each answer independent of earlier conversation text. Retrieval history is configured separately below.
Controls the metadata and text sent for each retrieved source. The default includes title, created date, correspondent, document type and document ID. Metadata is read live from Paperless for each chat, so changing this template does not require an index rebuild. Variables such as full content or raw JSON can be very large and are intended for expert use.
Variables
Controls exactly where retrieved document excerpts and the current question appear in the final user message sent to the chat model.
Variables
Advanced chat & generation settings
Optional generation controls. Model support and useful values can vary; blank expert fields use the model/Ollama default.
Controls whether the chat model uses its reasoning mode.
Maximum context window available to the chat request. Larger values can use more memory.
Lower values are more deterministic; higher values allow more variation.
Maximum generated tokens. Thinking and the final answer share this budget.
Limits how many likely next tokens remain available to the sampler.
Keeps the smallest token set whose cumulative probability reaches this value.
Filters unlikely tokens relative to the most likely next token.
Penalizes recently used tokens to reduce repetitive output.
How much recent context the repetition penalty considers.
A fixed seed can make repeated runs more reproducible.
Generation stops when any listed sequence is emitted.
Retrieval
Controls which indexed document chunks are selected before the chat model sees them.
Maximum number of the most similar chunks passed to the chat model. Higher values can improve recall but use more context.
Advanced retrieval settings
Tune how multi-turn questions become retrieval queries and how matching chunks are filtered.
Choose which roles from the selected previous turns are included in the embedding query. User only is safer against feeding a mistaken model answer back into retrieval.
Number of earlier user turns that define the retrieval history window. Default: 3. In User + assistant mode, assistant replies inside those turns are included too. 0 uses only the current question.
Discards retrieved chunks below this cosine score. Leave blank to accept the best matches regardless of score.
Limits how many primary similarity hits may come from one document. Leave blank for no limit; lower values encourage source diversity.
Adds neighboring chunks around each primary similarity hit before prompt assembly. This can restore context across chunk boundaries without another model call. It does not change Top-K ranking.
Optional cap on how much of the approximate input context document excerpts may use. Leave blank for automatic use of the remaining prompt budget.
When enabled, answers can show the effective embedding query, similarity scores, selected chunk ordinals and prompt-budget details. No extra model request is made. This can be overridden per chat.
Embedding & index
Controls how Paperless text is split and embedded. Changes that alter stored document vectors require a rebuild; runtime-only tuning does not.
Ollama model used for both document and query embeddings. Changing it requires a full index rebuild.
Approximate target size of each searchable text chunk. Smaller chunks are more focused but create more index entries. Requires rebuild.
Text repeated between neighboring chunks so context is not lost at boundaries. Requires rebuild.
Advanced embedding settings
Model-specific. The built-in templates are configured for Qwen3-Embedding. Other embedding models may expect different prefixes, templates, dimensions or context behavior.
Exact text embedded for each search. The built-in default follows the recommended Qwen3-Embedding query instruction format. Changes affect new searches immediately and do not require a rebuild.
Variables
Exact text embedded for every indexed chunk. The Qwen3-Embedding default is plain {{CHUNK}}. Changes require a rebuild.
Variables
Leave blank for the model's native vector size. A custom value changes stored vectors and requires a rebuild.
On truncates an oversized query to the embedding context; Off makes Ollama return an error instead. No rebuild required.
Controls the same behavior for indexed document inputs. Changing it affects corpus embeddings and requires a rebuild.
Optional embedding num_ctx override. Leave blank for Ollama/model default. Changing it requires a rebuild.
Chunks sent in one embedding request. Affects speed and memory use, not index semantics; no rebuild required.
Chunks processed before PLAI releases the shared AI slot. Larger slices improve continuity but can make OCR/metadata wait longer. No rebuild required.
How often PLAI checks for changed Paperless documents for incremental index sync. No rebuild required.
Structural embedding changes are saved immediately, but the active index remains in use until a rebuild finishes and activates the new index.
Index status
Loading…
Loading index state…
Sync updates changed documents. Rebuild creates a complete replacement index and activates it atomically when finished. Pause stops ongoing index work; the current active index stays available.