Processing App

Why a UI Matters

A document processing pipeline that only runs from the command line is a proof-of-concept. In production, operators need to:

The UI is the bridge between the automated pipeline and the human judgment that handles the 5-10% of documents the pipeline can't confidently process.

The Three-Panel Layout

Document processing UIs follow a consistent pattern across the industry:

Panel 1: Upload & Queue

The left panel handles input. Operators drop files (individually or in bulk), see upload progress, and view the document queue. Each document shows a status badge: green (accepted), yellow (needs review), red (rejected).

Panel 2: Extraction Preview

The center panel shows what the pipeline extracted. For the selected document, it displays:

Panel 3: Field Editor

The right panel (or below the preview) lets operators correct extraction errors. Each field is an editable input with a confidence badge. When an operator changes a value, the confidence is set to 1.0 (human-verified). This correction is valuable training data.

Wiring the API

The pipeline runs server-side through API routes:

POST /api/process

Single document processing. Accepts { filename, content } and returns the full pipeline output: classification, extracted fields, validation results, and confidence score. The frontend calls this for each uploaded file.

POST /api/batch

Batch processing. Accepts { documents: [...] } and returns a job ID. The frontend polls this endpoint for progress. When complete, the response includes all results with per-document status.

The Integration Point

The API route orchestrates the full pipeline:

Each step returns results that feed into the next. Errors at any step are captured (not thrown) so the pipeline can return partial results with explanations.

Batch Processing UX

Batch mode is where the UI proves its value:

Progress Tracking

A progress bar showing "Processing 47 of 200..." with estimated time remaining. The backend processes documents concurrently (Module 6's throughput optimizer) and streams progress updates.

Result Summary

After batch completion, a dashboard shows:

Review Queue

The review queue sorts documents by priority. High-priority (critical errors or low confidence) appear first. Operators work through the queue, correcting fields and approving documents. Each approval is logged for audit.

Export

The final step: getting data out.

JSON Export

Full structured output including all fields, confidence scores, validation results, and audit trail. This is the API format — consumed by downstream systems, databases, or other services.

CSV Export

Flat table with one row per document. Column headers are field names. Only accepted and reviewed documents are included (rejected documents are excluded because their data is unreliable).

API Integration

In production, you'd add webhooks or message queues. When a document is approved, the system pushes structured data to the ERP, accounting system, or data warehouse. Real-time integration means operators don't have to manually export and import.

UX Principles for Document Processing

Route Attention to Exceptions

The operator's job is handling the 10% that automation can't. The UI should surface low-confidence documents first, highlight uncertain fields, and make corrections fast. Auto-accepted documents should be invisible unless the operator specifically looks for them.

Show Provenance

Every field should show where it came from (template match, key-value detection, table parsing) and how confident the extraction is. This helps operators decide which corrections to make — a field from template matching at 95% confidence probably just needs a format fix, while a field from key-value detection at 65% confidence might be completely wrong.

Preserve Context

When correcting a field, the operator needs to see the original document text. A side-by-side view — extracted fields on the left, source text on the right — lets operators verify corrections against the source.

Make Corrections Training Data

Every operator correction is a labeled example. The system should track: which field, what the pipeline extracted, what the operator corrected it to, and from which document. This data feeds the retraining pipeline in Module 6.