Contract Intelligence for the LIBOR Transition

Finance · 2019-2020

PublicRepresentative · synthetic data
intakeregisterrouteformat gateextract-textvision OCRsegmentclauses + bboxanalyzeclause textextract-fieldsstructuredscoreconfidencetriage3 bandsrecordregistermetered · LLMdeterministic · $0
Live diagram - the 9-stage pipeline. TWO stages are metered - vision OCR on scans and clause text-analysis on all docs; the validation floor and triage are deterministic.
intake$0route$0$extract-textmeteredsegment$0$analyzemeteredextract-fields$0score$0triage$0record$0COST LEVER · format gate
Live diagram - two metered stages: a digital contract skips the vision OCR and incurs only clause analysis; a scanned one incurs both. The format gate decides.
ASPECTCLOUD · capable readOSS · recordedScanned-page detailparties · sections · clausesreads it, fewer detailsct-03 triage band→ reviewer→ exceptionPage confidenceslightly conservativemore confidentct-07 degraded scanreads structurenot captured - routed to a human
Live diagram - Cloud (claude-haiku-4-5) vs recorded OSS (qwen2.5vl:7b + qwen3:8b); the deterministic field-validation and triage floor is authoritative in both modes.

The 9-stage pipeline

One pipeline runs end to end: intake → route → extract-text → segment → analyze → extract-fields → score → triage → record. Two stages are metered - the vision OCR legibility read (on scanned pages) and the clause text-analysis (on every document) - which makes ② the portfolio's first dual-perception app. A deterministic validation floor (benchmark + fallback detection) plus the confidence floor and triage are authoritative regardless of mode; every other stage costs nothing.

The format gate - the cost lever

Routing is the cost lever. A digital PDF or Word document is parsed directly for $0 and never touches the vision model; only a scanned image is perceived. So vision spend accrues per scanned document, not per user action - the honest downscale of an OCR-plus-extraction stack, where the expensive perception is reserved for the inputs that actually need it.

The two metered stages are independent: a digital contract still incurs the clause text-analysis, but skips the vision OCR entirely; a scanned contract incurs both. The cost meter reflects exactly that split.

Dual approach - cloud vs on-prem OSS

The two metered stages can run on the cloud model (claude-haiku-4-5 - vision OCR plus text analysis, cost-capped and fail-closed) or on self-hosted open models (qwen2.5vl:7b for vision, qwen3:8b for text) recorded on local M4 hardware for the GPU-less host.

The honest finding, shown as recorded divergences in the inspector: both models read the scans, but the cloud model reads more detail - surfacing parties, sections and clause specifics the smaller open model leaves out - and on one borderline contract the cloud read routes to the reviewer queue while the open read routes to exception, a genuine band-level gap. The cloud's page-confidence is a touch more conservative. One heavily-degraded benchmark page is shown as “not captured” for the OSS run rather than inventing a read. The deterministic field-validation and triage floor is authoritative either way, and the models are swap-ready behind the toggle.

Out of scope (the real system)

Several production capabilities are deliberately excluded and represented honestly. Real document ingestion is stood in for by the synthetic corpus; a production OCR engine by the metered vision stage on rasterized synthetic pages; ticketing and amendment-export integrations by a simulated, labelled export; and model retraining by the wrong-read corrections plus the owner overlay and audit log. No real or copyrighted documents are used, and the figures are representative ranges.