LiTiL Contract Playbook 3B: apply the rule and return the next action

Contract review gets inconsistent when the policy lives in a document but the decision lives in someone's head. The same clause can get a different answer depending on who reads it, which facts they remember, and whether they found the right fallback.

LiTiL Contract Playbook 3B is built for a narrower decision. Give it the clause, the relevant playbook excerpt, and the available deal facts. It returns a structured review action, the rule basis, risky language, fallback direction, missing facts, and a short explanation.

The model applies the rule supplied in the prompt. That lets the application choose the current policy and keep it beside the result. A change to the playbook does not have to disappear inside an untraceable prompt or a newly trained model.

Which playbook it uses

The adapter was trained on M9 Contract Action Policy, Playbook v1. It covers B2B SaaS, cybersecurity services, and data-processing agreements in a US commercial setting.

The playbook contains 70 rules across 13 clause families, including limitation of liability, indemnity, confidentiality, AI use of customer data, data processing and security, assignment and change of control, auto-renewal, termination, IP ownership, publicity, warranty disclaimer, subprocessors, and audit rights.

The caller still supplies the relevant excerpt on every request. That is the useful implementation detail. The model is an execution layer for the rule in front of it, while the application owns policy selection, versioning, and the deal facts.

Input and output

The user message contains six fields in a fixed order: contract type, company side, deal context, clause type, playbook excerpt, and clause text.

The response is one JSON object. Its action must be one of accept, redline, fallback_1, fallback_2, business_approval, legal_escalation, or reject. The object also contains a risk level, issue tags, quoted risky text, the playbook basis, a recommended fallback, missing facts, and an explanation.

Validate the JSON and every enumerated value before using it downstream. Keep the clause, playbook version, supplied excerpt, deal context, and model revision with the parsed decision. If a required fact is missing, the published system prompt directs the model to select business approval and name the missing fact.

Where it fits

Contract Playbook belongs after classification and extraction. A clause model identifies the provision. An extractor captures the important term. The workflow chooses the matching company rule and supplies any deal context that changes the answer. Contract Playbook then recommends the next action.

That action can populate a review screen, draft a redline task, request a business approval, or send the clause to a specialist. The model should not directly change a contract record or approve language. The workflow validates the object and applies the organization's current authorization rules.

What the measurements support

On the published 925-case evaluation, Contract Playbook reached 84.97% exact action accuracy, compared with 25.41% for the Qwen base. Binary decision accuracy was 87.89% versus 72.54%. The adapter returned valid JSON in all 925 cases.

The evaluation decisions came from the same versioned playbook resolver used to build the synthetic examples. That makes the result a measurement of rule execution under this interface. It supports using the adapter as a first-pass policy component when the caller supplies the rule and facts in the expected format.

Training used 5,560 programmatically generated examples. A row-level lineage check matched every training row to deterministic generators, and the reviewed post-training set contained no client files or client contract text.

A practical implementation

Begin with one clause family whose review policy is already written down. Convert the rule into a short excerpt, define the allowed issue tags, and identify the deal facts that affect the action. Run the model on a representative set of clauses and compare the action, basis, fallback, and missing-fact behavior with the decisions your reviewers expect.

The 3B base is about 6 GB in BF16 weights, and the adapter adds about 114 MB. The card suggests roughly 8 to 10 GB of accelerator memory for the tested 2K-token envelope. A four-bit setup may fit in less, but it should be measured again with the exact prompt and parser.

The public repository includes the adapter, M9 Playbook v1 description, complete output schema, tested prompt, and a saved decision example: LiTiL Contract Playbook 3B on Hugging Face.