A technical walkthrough of the eight-stage processing pipeline—from SPLITTER through EXPORT—covering the document status lifecycle, classification and extraction confidence scores, review task triggers, and how to build reliable automation around the analytics event stream.
Before TRUE, the process took almost an hour per loan. Since implementing, I'm now processing four loans in less than 20 minutes.
— Operations lead, First Continental Mortgage
When you upload a source file to POST /loans/{loanId}/source-files, MOS immediately queues it through a sequence of discrete processing stages. Each stage is an independent service that emits analytics events you can subscribe to. Understanding what each stage does and which API fields it populates is essential for building a reliable integration.
Segments large multi-document PDFs into individual document units. A single closing package PDF of 200 pages may split into 15 or more individual classified documents. The source file record (returned by GET /loans/{loanId}/source-files) reflects the overall upload status; individual document records are created after splitting completes.
Converts each document segment into a format suitable for recognition. This stage is internal to the pipeline and does not produce directly queryable output, but failures here surface as FAILED status on the document record.
Runs CV, OCR against each page. MOS runs two recognizer variants — RECOGNIZER_SMART and RECOGNIZER_GENERAL — depending on document complexity. Raw CV-OCR output is accessible via GET /ocr-data/documents/{documentId} or at the page level via GET /ocr-data/pages/{pageId}.
Classifies each document against the configured document type library and assigns a documentTypeId and a documentTypeConfidence score (float, 0–1). When this stage completes, the document's processingStatus advances to CLASSIFIED. A CLASSIFICATION_RESULT analytics event fires.
Extracts field values from the classified document. Each extracted field carries a fieldConfidence score and a manuallyCorrected boolean. When extraction completes, processingStatus advances to EXTRACTED. Extracted data is readable via GET /extractedData/documents/{documentId}. An EXTRACTION_RESULT event fires.
Runs cross-document and LOS consistency checks against the extracted data. For post-close documents this includes signature presence, notary completeness, and date validation. Validation failures surface as VALIDATION_ERROR events in the analytics stream and are captured in loan reports.
Applies versioning metadata to the document record, populating versionIdentifier and optionally versionCustomName. Each correction or re-upload that produces a new document version is tracked here. A VERSIONING_RESULT event fires on version creation.
Pushes classified and validated documents back to the LOS via the Encompass eFolder mapping. When export completes, processingStatus advances to EXPORTED. The processing report at GET /reports/loan-processing records the docPushDateTime timestamp for each document. Average end-to-end time from upload to push is 2 minutes 30 seconds.
Handles initial document ingestion from external sources. In most integrations this stage is transparent — documents arrive via the source-file upload API rather than a pull-based import. The docPullDateTime field on processing reports reflects when the import stage first received the document.
The processingStatus field on a document record reflects which pipeline stage has most recently completed. Poll GET /documents/{documentId} or GET /loans/{loanId}/documents to read current status. Your integration should handle all values, including FAILED, with appropriate retry or escalation logic.
| Status | Meaning |
|---|---|
UPLOADING |
The source file has been received but the splitter has not yet begun processing. Transient — do not read classification or extraction data at this stage. |
PROCESSING |
The document is actively moving through the pipeline (any stage from SPLITTER through EXTRACTOR). Poll at 1–5 second intervals. |
CLASSIFIED |
Classification has completed. documentTypeId and documentTypeConfidence are populated. Extraction may still be in progress. |
EXTRACTED |
Field extraction has completed. GET /extractedData/documents/{documentId} returns the full field set. Safe to read and act on extracted values. |
EXPORTED |
The document has been exported to the LOS. Processing is complete end-to-end. |
FAILED |
The pipeline encountered an unrecoverable error. Inspect the analytics event stream for the failing stage. |
The documentTypeConfidence field is a float between 0 and 1, returned on every classified document. Across all document types, MOS averages 89.3% classification confidence. W-2 Wage Statements reach 94.2% average confidence, the highest of any single type in the standard set.
MOS applies configurable thresholds to determine when a document requires human review. Three bands are meaningful for integration logic:
| Band | Range | Guidance |
|---|---|---|
| High confidence | 0.85 and above | Safe to use the assigned documentTypeId without requiring manual confirmation. |
| Medium confidence | 0.65 to 0.84 | Likely correct but warrants review for high-stakes processes (income analysis, LOS export). A review task is typically created below the configured threshold in this range. |
| Low confidence | Below 0.65 | Classification is uncertain. A review task is always created. Do not use the documentTypeId for automated routing until resolved. |
The exact threshold at which review tasks are created is configurable per tenant. Contact your MOS administrator to confirm the threshold applied to your environment before building threshold-dependent logic.
Each field returned by GET /extractedData/documents/{documentId} carries two quality signals: fieldConfidence (float, 0–1) and manuallyCorrected (boolean).
Overall extraction confidence averages 85.2% across all document types and all fields. Individual document types vary significantly: W-2 extraction averages 87.5% confidence while pay stub extraction averages 72.3%, reflecting the higher variability in pay stub layouts across employers.
The manuallyCorrected flag is set to true when a human reviewer has applied a correction via PUT /extractedData/documents/{documentId}. A manually corrected value is the highest-quality signal available for a field — treat it as authoritative for downstream processes regardless of the original fieldConfidence score.
Decision framework for consuming extracted values:
| Signal | Action |
|---|---|
fieldConfidence ≥ 0.85, manuallyCorrected: false, status EXTRACTED or EXPORTED |
Trust and proceed — safe to write to LOS or pass to downstream calculations. |
fieldConfidence 0.65–0.84 |
Surface for confirmation — show the value with confidence visible. Do not block the workflow. |
fieldConfidence < 0.65 or open USER_REVIEW_CREATED task |
Hold pending review — block automated downstream use until resolved with manuallyCorrected: true. |
manuallyCorrected: true at any confidence level |
Authoritative override — use unconditionally. |
MOS creates review tasks automatically when classification or extraction confidence falls below the configured threshold for a document type.
The lifecycle of a review task:
USER_REVIEW_CREATED analytics event fires and a task record is created.USER_REVIEW_RESOLVED event fires and the task is marked complete.manuallyCorrected: true.Your integration can subscribe to USER_REVIEW_CREATED events via the analytics event stream to build real-time notifications or queue management into your own workflow UI - without polling individual document records for status changes.
MOS emits structured events throughout the processing pipeline. Query them via GET /tenant/{tenantId}/analytics/events with eventType filtering and cursor-based pagination.
Fired when the CLASSIFIER stage completes for a document. Payload includes documentId, assigned documentTypeId, and documentTypeConfidence. Use this event to trigger downstream logic as soon as classification is available — before extraction completes — if your workflow requires early routing.
Fired when the EXTRACTOR stage completes. Payload includes documentId and a summary of extraction results. This is the signal to fetch extracted data via GET /extractedData/documents/{documentId}. Building your polling loop around this event rather than status polling reduces unnecessary API calls at scale.
Fired when a review task is resolved. Payload identifies the taskId and the associated documentId. Subscribe to this event to re-trigger downstream processes that were held pending human review — for example, re-running income eligibility checks after a W-2 classification correction.
Fired when a reviewer applies a field-level correction via PUT /extractedData/documents/{documentId}. Payload includes the corrected fieldTypeId and the new value. Use this event to invalidate cached field data in your application and re-fetch from the API to ensure you are working with the most recent human-verified values.
Production reporting in MOS gives developers a direct way to retrieve structured report data for tenant workflows, operational monitoring, and downstream analytics. This guide walks through discovering available reports, generating Bank Statement Analysis output, applying filters, and exporting report rows for your own systems.
Check which documents are income-eligible, trigger the Candor calculation, poll for results, and re-run after new documents arrive — with a full audit trail of every calculation run available via the history endpoint.
Walk through the complete Loan Setup pipeline — upload source files, poll processingStatus, fetch extracted field data with confidence scores, handle corrections, and monitor per-loan processing events via the analytics timeline endpoint.