Route the request before doing the expensive work: LiTiL Legal Request Router 1.5B

A legal intelligence system has to decide where a request belongs before it loads the right retrieval index, playbook, specialist model, or person. Sending every request through the same workflow wastes compute and makes ownership harder to measure.

LiTiL Legal Request Router 1.5B turns an incoming legal request into a JSON routing proposal. It covers six application domains: commercial, employment, corporate, technology/AI, crypto, and general legal work.

The adapter runs on Qwen/Qwen2.5-1.5B-Instruct, so the first decision in the stack can stay small.

What the route contains

The output includes domain, subdomain, complexity, proposed tools, a model-emitted confidence, an escalate flag, and a short reasoning field. Complexity is constrained to simple, medium, or complex.

Those fields are proposals, not commands. The application should parse the entire completion as JSON, reject missing fields or unknown domain codes, and then apply its own rules for escalation and tool selection. The included runner never executes a proposed tool.

That boundary is useful. The model handles language variation in the incoming request. Code handles the list of valid destinations and the current operating policy.

Where it fits

Put the router immediately after intake. Store its output beside the original request, the route eventually accepted, and any reassignment made by the team.

The accepted domain can choose:

• the intake questions that appear next;
• the retrieval index and playbook to load;
• a specialist model such as a clause classifier or Howey evidence router;
• the review queue that owns the matter; and
• whether a general legal fallback should take over.

This also gives operations teams a clean way to measure the front door. You can track how often requests move between domains, which subdomains create escalation, and where the proposed route disagrees with the route a person selected.

What was trained

LiTiL Legal Request Router is a rank-16 PEFT LoRA adapter. The task-specific training set contained 540 authored synthetic requests, and another 60 synthetic rows were used for validation. Review of the post-training set found no private client or user data.

The release selects checkpoint 200 from a 204-step run. Inference uses the published system instruction and greedy decoding, with up to 256 new tokens.

The card includes a recorded employment request. The adapter classified it into an employment handbook-update route and returned the complete JSON object expected by the application contract.

What to measure

Routing quality depends on the taxonomy the application actually uses. Build a test set from representative, cleared requests and score the fields separately.

Start with exact domain accuracy and valid JSON rate. Then measure subdomain accuracy, escalation agreement, and how often the proposed route needs reassignment. Tool proposals deserve their own check because a valid domain does not make every suggested tool appropriate.

Keep automatic dispatch behind a whitelist until those measurements are stable. A low-cost router can save work only if the receiving workflow trusts the route and can send bad ones somewhere safe.

What to build with it

The first implementation can be small: one intake box, a schema validator, six domain queues, and a general fallback. Add specialist retrieval and models only after the routing log shows where they will help.

That makes the router more than a demo classifier. It becomes the record of how a request entered the system, where it went, and why the application made that choice.

The LiTiL Legal Request Router 1.5B repository includes the Apache 2.0 adapter, the exact system prompt, runnable examples, and an offline runner.