Can a 1B Model Read Contracts? RedPen Rebuilds Contract Review with a Rules Engine + Small Model

A "Counterintuitive" Product Decision

RedPen is an offline contract review tool aimed at freelancers, and its core design philosophy can be summed up in one sentence: the model never judges which clauses are risky.

65 open-source rules handle identifying dangerous clauses, while a locally running Gemma 3 1B model is only responsible for reorganizing the conclusions found by those rules into language that can be sent to a client. The entire tool runs on the user's own laptop—no uploads, no per-use fees, a one-time $19.

This layered architecture isn't modesty about the capabilities of a 1B small model—it's a precise division of labor boundaries. According to a Dev.to write-up by developer Soumwadeep, a 1B model is not reliable enough to judge clause risk, and a rules engine is not good enough at writing a persuasive client email. Each layer only does the half it's truly competent at.

More crucially: even if the model layer is completely turned off, the review report remains fully usable.

How the Two-Layer Architecture Works

Layer One: 65 Open-Source Rules, No Model Required

The rules layer is written in pure Python and split into three rule libraries: freelance agreements, offer letters/internship agreements, and NDAs. Each rule carries its own explanation, a paragraph of ready-to-paste counter-language, and the words to say in an email.

Technically, PyMuPDF handles text extraction, and the segmentation module restores clause numbering while preserving each clause's page number and character span. Every finding quotes verbatim the source text that triggered it.

PyMuPDF is a Python library built on the MuPDF engine, dedicated to parsing, rendering, and text extraction from PDF and other document formats. Its advantages are speed, low memory footprint, no external dependencies, and the ability to precisely return the bounding box coordinates of every character on a page. RedPen uses this feature to achieve "verbatim quoting of the text that triggers the rules"—it doesn't just get the text, it can also locate the specific page number and character span, making every finding in the report traceable and verifiable. Compared to converting PDFs to images and then running OCR, PyMuPDF reads the embedded text layer directly—zero network requests, zero cloud calls, fitting the offline privacy requirement.

Layer Two: Gemma 3 1B via llama.cpp, Language Only

The model reads the findings from layer one and rephrases them for this specific contract: a three-line summary, clause-by-clause explanations, a negotiation email, plus a round of ambiguity checks that rule patterns can't cover.

The runtime environment is extremely lightweight: an 8GB Apple Silicon MacBook, no GPU, no Docker. Weights are 769MB, loading takes 2.3 seconds, resident memory is 0.83GB. Rule processing takes only 12–28 milliseconds, and a full review (including the model layer) takes 11–17 seconds. Results are rendered via SSE streaming, so the UI doesn't block while the model writes the email.

llama.cpp is an open-source LLM inference engine written in C/C++ that loads quantized model weights in GGUF format, runs efficiently on CPU, and supports Metal acceleration on Apple Silicon. It compresses model size to the hundreds-of-megabytes level, allowing a 1B-parameter model to run at acceptable speeds on an ordinary laptop. RedPen calls Gemma 3 1B via llama.cpp after Q4 quantization, with weights at just 769MB and resident memory at 0.83GB—no GPU, no Docker. SSE (Server-Sent Events) is a one-way HTTP-based streaming push technology where the server can continuously send text fragments to the browser, so the interface can render in real time as the model generates the email word by word, without freezing while waiting for the full response.

Six Bugs Exposed by Real Documents

After developing with self-made synthetic contracts, the developer tested with six real documents—and the result was six failures he had never anticipated.

Issue	Why It's Serious
Silently dropping page 1 of an offer letter	The segmentation logic only outputs text after the first numbered clause. Page 1 of a real offer letter is usually unnumbered prose, so an unpaid training period and a work schedule of 6 days a week, 11am to 8pm, were never analyzed
Telling an intern "there's no deposit clause"	Freelance rules ran on employment terms: no deposit, no late interest, no suspension right. True but useless—and the real finding was that the employer withheld their original degree certificate
Missing an impossible date	An internship offer was sent on June 29, 2023, but the term ran from July 3, 2022, to April 28, 2023—it had already ended before the offer was sent
Missing a "de facto perpetual" clause	An NDA wrote the termination condition for obligations as "until all confidential information becomes publicly known"—which will never happen
Flagging normal drafting as a risk	"The freelancer shall not incur new expenses without approval" triggered the expense-rejection rule because an unanchored no matched inside not
Treating blank fields as hostility	[City, State] has exclusive jurisdiction was scored at full severity. Unfilled fields are now counted and displayed separately, and related findings are automatically downgraded

Six real documents, six bugs. This is exactly why this architecture exists: when it misjudges the document type, the fix is a new rule, not retraining or filing a ticket.

Guardrails, All Born from Model Failures

The guardrails accumulated during development are also worth noting:

• Citing nonexistent clauses: parse against actual clauses, otherwise discard. The model often answers with a vague word rather than a clause number, which is also parsed—but only when that word happens to appear in exactly one clause
• Dropping three of six requirements: check coverage against the wording you were told to request. Format isn't checked—the first validator once rejected a perfectly good bulleted email because the requirement was numbered format
• Email signed "Max": strip and replace with [your name]
• Claiming to be a different model: when testing with Qwen weights, the UI still displayed "gemma." The label was hardcoded; it now reads from the actual running model
• Returning garbage or the engine not running: every role has a deterministic fallback, and the report is always complete

Why Open Source Is a Structural Advantage Here

The developer lists four things a closed-source API structurally cannot provide:

1. The client's NDA never leaves the laptop. The most sensitive document for a freelancer is one describing the work they did for a client who has already paid. "We promise to delete within 30 days" and "it was never transmitted" are not the same thing. This is enforced in code: the HTTP client throws an exception when the base URL is not loopback, and there's a test covering it. Uploaded files are parsed from bytes and never written to disk.

scripts/offline_proof.sh samples every socket held by the process while running a full review—all loopback, no request leaving the machine. The developer admits that the first version of this script passed because nothing was observed, because a literal bracket in the PID list meant lsof never received valid arguments.

2. Zero marginal cost makes one-time pricing viable. Hosting a server that can hold the weights costs about $25/month, and on shared CPU it only does 2–5 tokens/sec—slower than the user's own laptop, and every contract lands on a server they don't control. Running locally, the 500th user costs zero, which is the basis for $19 one-time pricing rather than a subscription.

3. Rules are editable, and that's the real moat. If you do video editing, "perpetual, all-media, worldwide usage rights" is a red flag you're familiar with but a generic API can't reliably flag. You can add a rule in JSON—no code, no approval.

4. Swapping models is a one-line config change. Verified: the same contract produces identical findings under Gemma 3 1B and Qwen 2.5 1.5B—same rules, same pages, same evidence, only the summary and email wording change. Choosing weights becomes a wording preference, not a correctness risk.

A loopback address refers to a network interface pointing to the machine itself, such as 127.0.0.1 or ::1, where packets don't pass through any physical network card. RedPen enforces a check at the HTTP client layer for whether the base URL is loopback, throwing an exception otherwise, guaranteeing at the code level that the review process never sends requests to external servers. scripts/offline_proof.sh uses lsof (which lists files and sockets opened by a process) to sample all network connections during a run and verify they're all loopback. This kind of "proving privacy promises with engineering" is more verifiable than any terms of service.

Honest Limitations

RedPen's limitations are equally clear: 8GB of memory is the floor, 1–3B Q4 quantized models can run, 7B cannot. Scanned PDFs are not supported—there's no selectable text, and RedPen won't send your pages to an OCR service, so it says so directly rather than returning an empty review.

The model layer is a 1B model, so explanations are sometimes generic, which is why the rule library's own wording sits underneath them. A clean review report is weak evidence—no rule match doesn't equal a fairness guarantee, and the UI says this explicitly rather than implying safety with a green gauge.

RedPen is a pattern-matching tool with an open-source rule library, not a lawyer.

Q4 quantization refers to compressing model weights from 16-bit floating point to roughly 4-bit integers, shrinking size by about four times and greatly reducing memory footprint, at the cost of slight precision loss. A 1–3B parameter model after Q4 quantization can run on an 8GB memory device, while a 7B model still exceeds that memory budget even after quantization—this forms RedPen's hardware floor. Scanned PDFs are another limitation: their pages are essentially images with no extractable text layer, so PyMuPDF can't read the text directly. RedPen chooses to clearly tell users it's unsupported rather than quietly uploading pages to an OCR service—consistent with its core promise that data never leaves the device.

First User and the Roadmap Ahead

Freelance developer Shreshtha Das tested RedPen and gave positive feedback, particularly highlighting the advantage of offline operation when handling confidential client agreements and NDAs. But the developer himself stays clear-eyed: this is a single data point, not validation; and the one false positive he most wanted to hear about was exactly what the other party didn't report.

The founding team at Actizant, after reviewing the codebase, gave a three-line roadmap: profession-specific risk rules, jurisdiction-aware guidance, and transparent declarations of the limits of automated analysis. The first two are exactly what an open-source rule library is naturally good at—a profession-specific rule set is just a JSON file, and a jurisdiction config file is a second set of rules with different safe harbors.

RedPen is MIT-licensed, 5355 lines of Python, 65 rules, 104 tests, no compiled bindings. Model weights follow their own licenses; RedPen doesn't bundle the weights, it downloads them for you.