Core user features

These outcomes are stable even when the routing technique, model, parser, or deployment changes.

Who calls this

Three consumers, all reaching the same four operations through HTTP, the CLI, or the in-process facade:

• A retrieval or agent pipeline wants chunk-level text and versioned embeddings for an index it controls, plus the query encoder needed to search those vectors later (outcomes 1, 2, 7).
• A document-processing application must account for what it spent, where the work ran, and what happened to each page — including the pages nothing could read (outcomes 2, 4, 6).
• An operator with a corpus and a budget wants the cheap path whenever it suffices and the expensive one only when it does not, with the difference measurable rather than asserted (outcomes 2, 4, 5).

None of them wants a router. They want these outcomes; routing is how the outcomes are reached, and it is replaceable.

1. Receive an actionable plan

An API or library user submits content and business constraints and receives a complete, explainable plan containing only capabilities present in its recorded snapshot. The plan can be returned without execution and is reproducible for the same source, constraints, policy, and snapshot.

2. Achieve the required result efficiently

Execution meets declared quality, latency, cost, hardware, and residency constraints without unnecessary heavy processing. Actual cost, latency, quality, resource use, and fallbacks are recorded. Unsatisfied constraints are reported explicitly.

3. Specialize without losing generic coverage

Recognized inputs may nominate a specialized parser or reusable configuration. Recognition never forces it: unavailable, disallowed, or invalid specialized paths retain an eligible generic fallback.

4. Prove the routing advantage

Planned and actual outcomes can be compared against a fixed dataset, capability snapshot, constraints, and heavy-pipeline baseline. Routing decisions and executor failures remain distinguishable.

5. Classify a corpus on CPU

Standard inputs can be classified and organized without GPU processing, with the CPU-only rate and total cost reported for corpus-scale runs.

6. Read difficult enterprise data

Priority documents—including scans, handwriting, spreadsheets, drawings, and large files—have an eligible reading path. Unreadable content is never silently dropped.

7. Make processed data agent-readable

Processed content carries metadata and versioned document/chunk embeddings that can be exported to a customer-controlled index. The response identifies the embedding space and query encoder needed to search those vectors later.

First validation slice

The initial executable specification covers features 1–4 with one native-text fixture, one scanned fixture, direct extraction, generic OCR, generic VLM, and one optional invoice specialization. Features 5–7 remain target requirements until the backbone has measured baselines.