Work
A tiered document intelligence pipeline
A working prototype: contract intelligence that routes clause extraction and redlining to a stronger model and summarisation to a cheaper one, with per-tenant rate limits and budget caps.
- What it proves
- Document intelligence with cost engineered into the architecture.
- Method stages
- Built from
- Tiered model pipeline: strong model for clause extraction, risk flagging and redlining
- Cheaper model for summarisation and classification
- Vector search for semantic retrieval
- Per-tenant rate limits
- Per-tenant budget caps
The problem
Most document-intelligence demos show what a model can extract: clauses, risk flags, redlines against a standard template. Few say what it costs to run that across many tenants at volume, month after month. Teams usually find out from an invoice.
What we built
The pipeline has two model tiers. A stronger model handles clause extraction, risk assessment and redlining against a governing template. A cheaper, faster model handles summarisation and classification, which gain little from the extra capability. The router picks the tier by task type before the request is sent. Users do not set it, and it is not a fallback for when the stronger model is unavailable.
Vector search finds the relevant clause or precedent across a contract library without sending the whole set through either model each time.
Per-tenant rate limits and budget caps are part of the architecture. Each tenant’s usage is bounded before a request reaches the stronger model. One high-volume tenant, or one runaway automated process, cannot use up a budget meant for everyone else, so cost stays predictable.
What it proves for a client
A model that reads contracts well but cannot be capped is hard to put into production. This prototype shows the tiering and the caps working together.
Method stages
The prototype sits in Stage 02 · Prove the value. The cost design is Stage 03 · Engineer the system work. See the KARPINITY Method.