Redline: AI Contract Review

Redline is a personal AI project. Not a demo or a concept, but a shipped product with inspectable code. It came from a specific question: what would it take to build an AI system that freelancers actually trust with their contracts?

Freelancers receive contracts written by the other party. The language that hurts them is not hidden. It is readable, specific, and sitting in a document they have access to. They do not lack the right to read it. They lack the time, the pattern recognition, and the confidence to know which sentences matter and what to say back.

71% of freelancers have experienced non payment. Only 28% use written contracts. Those who do reduce payment disputes by 73%. The contracts they receive are inbound, terms handed to them by someone with more leverage.

What freelancers do today: read the contract themselves and miss things, ask a friend who "knows legal stuff," pay $300 to $500 for a lawyer to review a $2,000 project, or sign without reading. That last option is the most common. Existing AI tools are either enterprise priced ($30,000+ per year) or too shallow ($29 to $99 per month with no counter offer drafting and no severity ranking). Every existing tool requires significant upfront configuration before producing useful output.

Courts do not care whether you read the contract. A ruling compelling arbitration against an employee stated plainly: "the mere fact that one does not read a contract which he has signed is not grounds to invalidate the writing." Redline exists so the reading happens every time.

The core design decision was trust first AI. Every risk flag must cite the exact source sentence from the uploaded document. A human can find that sentence in the original and confirm it exists verbatim. A flag that paraphrases instead of quoting is a bug. This is not a black box that says "this clause is risky." It shows you exactly which sentence triggered the flag and why.

Six default rules ship with the product, each chosen because of what it costs a freelancer when it goes wrong: overbroad IP assignment, unfavorable payment terms, termination without guaranteed payment, non compete restrictions, overbroad indemnification, and forced arbitration with class action waivers. Severity is assessed from the specific language in the contract (scope, duration, one sidedness), not from the clause category. Two clauses of the same type can have different severities.

The tool flags aggressively. False positives over false negatives. A false positive costs 10 seconds (read the citation, dismiss). A false negative costs whatever the contract costs. This only works because every flag cites its source. Without citations, aggressive flagging would be noise.

Gap analysis flags clauses that should exist but do not: IP assignment, payment terms, and termination. It does not flag absence of non compete, indemnification, or forced arbitration, because missing is the preferred state.

Full stack execution across nine tickets, from project scaffold through production deployment. Auth via Supabase with row level security across all tables. Browser side document parsing (no OCR; scanned documents break the citation requirement). OpenRouter for model access with strict JSON schema validation on every response. Structured output ensures no malformed analysis reaches the user.

The analysis engine constructs prompts from the user's rules, runs the contract through the model, validates the response against a strict schema, sorts flags by severity, filters gaps, and rebuilds the checklist. Tests mock the HTTP call to OpenRouter but not the engine itself. Prompt construction, result validation, severity sorting, gap filtering, and checklist rebuilding all run for real in the test suite.

Scale: 13 routes compiled. 68 tests across 8 test files, zero failures. Five Supabase migrations with row level security policies. The app works without Supabase for anonymous analysis; auth dependent features (library, rules persistence) degrade gracefully.

Key modules: Core analysis pipeline, OpenRouter API client, question answering logic, client side document parser, rules CRUD with local fallback, and a document library with title and date formatting. Every module is independently testable.

Beyond the analysis engine: editable red line rules that users can toggle, reword, add, or delete. A question box that appears after analysis and answers follow up questions grounded in the document and analysis context. A document library for saved past contracts. Counter offer drafting for each flag and gap, with language specific to the contract shape.

Redline is live and deployed. The code is public. Every claim on this page is verifiable.

AI product development that earns trust starts with research, not technology selection. The 71% non payment statistic originated the product. The trust first citation architecture shaped every design decision downstream. The six default rules were chosen because the research showed where freelancers get hurt, not because those are the easiest clause types to detect.

The pattern: start with the user's actual problem (documented in research, not assumed), make the system's reasoning inspectable (every flag cites its source), ship it (live URL, public repo, passing tests), and let the work speak for itself.