FLUXX Classification Service---Low Level Design
FLUXX Classification Service---Low Level Design
Document Version
-
Version: 1.0
-
Date: March 6, 2026
-
Author: System Design
-
Status: Design Phase
1. Overview
1.1 Purpose
The FLUXX Classification Service is a standalone microservice that analyzes PDF documents to identify and classify individual forms/schedules with precise page ranges. This service is extracted from the existing ClassifyFileTool implementation to provide classification capabilities as an independent, reusable service.
1.2 Scope
This service handles:
-
PDF document analysis and text extraction
-
LLM-based form classification with chunk processing
-
Multi-form document detection
-
Classification result generation and storage
-
RESTful API interface for classification requests
1.3 Reference Implementation
This design is based on the existing implementation in:
-
/backend/src/api/v1/agent/tools/ClassifyFileTool.ts -
/backend/src/scripts/seed-agentic.ts(pdf_classification skill) -
/backend/src/utils/pdfProcessor.ts(PDF processing utilities)
2. Architecture
2.1 System Context
2.2 Service Components
2.2.1 API Layer
-
Express.js REST API
-
Request validation and authentication
-
Response formatting
-
Error handling middleware
2.2.2 Classification Engine
-
Orchestrates classification workflow
-
Manages chunk-based processing
-
Aggregates results from multiple chunks
-
Form merging and consolidation logic
2.2.3 PDF Processing Layer
-
PDF text extraction
-
Page counting and analysis
-
Chunk text segmentation
2.2.4 LLM Integration Layer
-
Azure OpenAI integration
-
Prompt construction
-
Response parsing and validation
2.2.5 Storage Layer
-
Azure Blob Storage integration
-
Classification result persistence
-
File metadata management
3. API Design
3.1 Endpoints
3.1.1 POST /api/v1/classify
Request:
Response (Success - 200):
Response (Error - 400/500):
3.1.2 GET /api/v1/classify/:classification_id
Retrieves a previously generated classification result.
Response (Success - 200):
3.1.3 GET /health
Health check endpoint.
Response:
4. Core Algorithm
4.1 Classification Workflow
4.2 Chunk Processing Details
Why Chunking?
-
Large PDFs (100+ pages) can exceed LLM context limits
-
Improves classification accuracy by focusing on smaller sections
-
Allows parallel processing in future enhancements
-
Reduces token costs
Chunk Size Selection:
-
Default: 10 pages per chunk
-
Rationale: Balance between context and LLM token limits
-
Configurable via API parameter
Chunk Overlap:
-
Current implementation: No overlap
-
Future enhancement: 1-page overlap to catch form boundaries
5. LLM Integration
5.1 Classification Skill Configuration
Skill Name: pdf_classification
System Prompt:
User Prompt Template (per chunk):
5.2 LLM Call Parameters
5.3 Response Parsing
6. Data Models
6.1 Classification Request
6.2 Classification Result
6.3 Chunk Classification (Internal)
7. Error Handling
7.1 Error Categories
| Error Code | HTTP Status | Description | Recovery |
|------------|-------------|-------------|----------|
| INVALID_INPUT | 400 | Invalid request parameters | Fix request |
| FILE_NOT_FOUND | 404 | File does not exist | Verify file reference |
| EMPTY_PDF | 400 | PDF has no extractable text | Use OCR preprocessing |
| SKILL_NOT_CONFIGURED | 500 | Classification skill missing | Run seed script |
| LLM_ERROR | 503 | Azure OpenAI failure | Retry with backoff |
| STORAGE_ERROR | 503 | Blob storage failure | Retry with backoff |
| PARSE_ERROR | 500 | Failed to parse LLM response | Fallback classification |
7.2 Error Response Format
8. Configuration
8.1 Environment Variables
8.2 Service Configuration File
9. Implementation Pseudocode
9.1 Main Classification Function
9.2 Chunk Classification Function
9.3 Merge Function
10. Deployment
10.1 Docker Container
10.2 Kubernetes Deployment
11. Testing Strategy
11.1 Unit Tests
-
PDF text extraction
-
Chunk text segmentation
-
Form merging logic
-
Error handling
11.2 Integration Tests
-
Azure OpenAI integration
-
Blob Storage integration
-
Full classification workflow
11.3 Test Cases
| Test Case | Input | Expected Output |
|-----------|-------|-----------------|
| Single Form PDF | 3-page Form 1040 | 1 form classification |
| Multi-Form PDF | 1040 + Schedule C (10 pages) | 2 forms, correct page ranges |
| Large PDF | 50-page combined tax return | Chunked processing, all forms identified |
| Empty PDF | Scanned images with no text | Error: EMPTY_PDF |
| Unidentified Forms | Custom business doc | “Extra form data” classification |
12. Performance Considerations
12.1 Expected Performance
-
Single-page classification: 2-3 seconds
-
10-page chunk classification: 3-5 seconds
-
100-page document (10 chunks): 30-50 seconds
12.2 Optimization Opportunities
-
Parallel chunk processing: Process multiple chunks concurrently
-
Caching: Cache classification results for identical documents
-
Streaming: Stream results as chunks complete
-
Batch API: Support batch classification requests
12.3 Scalability
-
Horizontal scaling via Kubernetes replicas
-
Stateless design enables load balancing
-
Azure OpenAI handles concurrency limits
13. Monitoring & Observability
13.1 Metrics
-
Classification requests per minute
-
Average classification time
-
LLM API latency
-
Error rate by error code
-
Blob storage operation latency
13.2 Logging
-
Structured JSON logging
-
Request/response logging (sanitized)
-
Error stack traces
-
Performance timing logs
13.3 Alerting
-
Error rate > 5%
-
Average response time > 60 seconds
-
Azure OpenAI 429 (rate limit) errors
-
Blob storage connectivity issues
14. Security
14.1 Authentication
-
API key authentication
-
Azure AD integration (optional)
-
User context validation
14.2 Data Protection
-
TLS in transit
-
Encrypted blob storage
-
Temporary file cleanup
-
PII redaction in logs
14.3 Rate Limiting
-
Per-user rate limits
-
Global service rate limits
-
Azure OpenAI quota management
15. Migration from Existing System
15.1 Migration Path
-
Deploy FLUXX Classification Service alongside existing system
-
Add feature flag to route classification requests
-
Run in parallel for validation period
-
Gradually increase traffic to new service
-
Deprecate old ClassifyFileTool
15.2 Backward Compatibility
-
Maintain same JSON output format
-
Support existing blob storage paths
-
Preserve classification_json_path structure
16. Future Enhancements
16.1 Phase 2 Features
-
OCR integration for image-based PDFs
-
Multi-language support
-
Custom classification rules per client
-
Confidence threshold tuning
16.2 Phase 3 Features
-
Real-time WebSocket streaming
-
Batch classification API
-
Classification result caching
-
ML model fine-tuning on classification data
17. Dependencies
17.1 NPM Packages
17.2 External Services
-
Azure OpenAI (GPT-4)
-
Azure Blob Storage
-
(Optional) Application Insights
18. Conclusion
The FLUXX Classification Service provides a robust, scalable solution for PDF document classification based on proven implementation from the Paperboy ClassifyFileTool. The service maintains the core chunk-based processing algorithm while offering improved modularity, observability, and deployment flexibility.
Key design decisions:
-
Chunk-based processing: Enables handling of large documents within LLM context limits
-
Stateless design: Facilitates horizontal scaling
-
Standard REST API: Easy integration with existing and new clients
-
Comprehensive error handling: Robust fallback and recovery mechanisms
-
Cloud-native: Designed for Kubernetes deployment with Azure services
Next steps:
-
Implement service following this design
-
Create comprehensive test suite
-
Deploy to staging environment
-
Conduct performance testing
-
Migrate production traffic