build.allanninal.dev

Part 1 of 7 · Contract summarizer series ~5 min read

A contract summarizer on AWS for a few dollars a month

A small business signs more contracts than anyone has time to read closely. The supplier agreement that auto-renews for two more years unless you cancel in a 30-day window nobody marked. The software order form with a late-fee clause buried on page nine. The lease, the service agreement, the NDA, the reseller deal with a liability cap that quietly puts your whole company on the hook. This post walks through the design of a small system that reads any of these, hands back a one-page plain-English summary, and flags the few clauses worth a closer look — without ever pretending to be your lawyer.

Key takeaways

  • Three ways a contract comes in: a Drive folder, an inbox forwarding lane, and an e-sign webhook.
  • Every contract runs the same flow: read the pages, pull the key terms, then flag the risky clauses.
  • The summary has six blocks: parties, deal, money, key dates, renewal and cancellation, flagged clauses.
  • Every point quotes the exact clause it came from. No quote, no point. It is never legal advice.
  • Designed on AWS for about $3/month at typical small-business volume.

The whole system on one page

Before any code, here’s the shape of what we’re designing.

System architecture: three sources, three pieces inside AWS At the top, three external boxes in a row. Far left, "Contracts in" — the documents arriving, via a Google Drive folder you drop files into, an inbox forwarding lane for PDFs, and a webhook from your e-sign tool that fires when an agreement is signed. Centre, "House style" — a Drive folder with a rules doc covering which clause types always get flagged and the escalate-to-a-lawyer thresholds, plus a voice doc with the summary layout and the not-legal-advice banner. Far right, "You" — the owner or office manager who reads the summary; it lands in a Drive folder, an email, or a Slack channel, each with an approve button before anything is filed. Each connects via an arrow to the AWS account container below. Contracts have an outgoing arrow into AWS. House style feeds in to ground every summary. You receive the one-page summary with the parties, deal, money, key dates, renewal and cancellation terms, and the flagged clauses, each with the quoted clause and an approve button. Inside the AWS account are three components in a row, mirroring the layout above. On the left, the Intake — receives the contract from each source, runs Textract to read the pages, and splits the text into numbered clauses. In the middle, the Reader — pulls the key terms with Haiku, then searches the clauses and reads the risky ones with Sonnet. On the right, the Summary — writes the one-page summary, drops the not-legal-advice banner, and waits for approval before delivering. Internal arrows flow left to right. A note at the bottom reads: every point quotes the clause it came from — the reader never just says "there is a penalty." Contracts in drive, inbox, e-sign House style flag rules, layout You where summaries land contract in grounds summary to approve AWS account Intake read pages, split into clauses Reader pulls key terms, flags risky clauses Summary one page, banner, approve to deliver clauses terms Every point quotes the clause it came from — the reader never just says “there is a penalty.”
Fig 1. Three sources outside, three pieces inside AWS. Contracts flow in from a Drive folder, an inbox forwarding lane, and an e-sign webhook. The Reader pulls the key terms and flags the risky clauses. The Summary writes one plain-English page and waits for a person to approve it.

What you set up once (the outside)

  • Contracts in. Three ways a contract reaches the system, covered in Part 2. A Drive folder you drop a file into. A dedicated inbox — forward a PDF to review@your-company.com and the system takes it from there. And a webhook from your e-sign tool (DocuSign, PandaDoc, and the like) that fires the moment an agreement is signed, so the summary is waiting for you before the ink is dry. You can use one lane or all three.
  • A house-style folder. Two short Google Docs in a Drive folder. The rules doc says which clause types always get flagged — auto-renewal, penalties and late fees, liability and indemnity, personal guarantees, exclusivity, termination — and the thresholds that mean “tell the owner to call a lawyer” (for example, any liability cap above the contract value, or any personal guarantee at all). The voice doc holds the layout of the one-page summary and the exact wording of the not-legal-advice banner that sits at the top of every one.
  • You. The person who reads the summary — usually the owner or the office manager. The summary lands wherever you asked: a Drive folder, an email, or a Slack channel. It arrives with an “Approve” button. Nothing is filed as final until a person taps it, so a summary is always a draft a human signed off on, never a machine’s last word.

What runs on every contract (the inside)

  • The intake. Takes the contract from whichever lane it arrived on and gets it ready to read. Amazon Textract turns the pages into text — it reads PDF, PNG, JPEG, and scanned documents, so a photographed contract works as well as a clean PDF. A small Python pass then splits the text into numbered clauses, so every later step can point at “clause 7.2” instead of a page somewhere. No model runs here; it is plain reading and splitting.
  • The reader. Two passes. First, a Bedrock Haiku 4.5 call — Haiku is the cheap, fast model — reads the clauses and fills a fixed shape: parties, deal, money, key dates, renewal and cancellation. Each field carries the clause number it came from, or it is left blank. Second, a clause search finds the paragraphs that match the always-flag list, and a Bedrock Sonnet 4.6 call — the stronger model, used only where the stakes are higher — reads those few clauses and explains each in plain words: what it says, why it matters, and whether it is the kind of thing to run past a lawyer.
  • The summary. Writes the six-block one-page summary, puts the not-legal-advice banner at the top, and lists the flagged clauses with the exact text quoted underneath each note. Then it stops and waits. The summary goes to your Drive, email, or Slack with an Approve button; tapping it files the summary against the contract and logs who approved it and when. Nothing is treated as final without that tap.

In plain words

A supplier emails you a renewal of your warehouse software agreement — eighteen pages, dense. You forward it to review@your-company.com and go back to your day. Four minutes later a summary lands in Slack. Parties: your company and the vendor. Deal: the warehouse management software, same modules as last year. Money: $1,450/month, up 8%, net-30, 1.5% monthly late fee (clause 4.3). Key dates: starts July 1, runs 24 months, auto-renews for another 24 unless you give notice between 90 and 60 days before the end (clause 11.1). Flagged: auto-renewal with a narrow notice window — clause 11.1 quoted — mark April 2 to May 2, 2028 now; and liability capped at one month’s fees — clause 9.2 quoted — this is low for your exposure; worth a lawyer’s eye before you sign. You read it in two minutes, tap Approve, and forward the lawyer note to your attorney.

The cost of running this is about $3 a month at SMB volume. The cost of not running it is the auto-renewal nobody caught, the late-fee clause nobody read, or the liability cap that turns one bad shipment into a number with too many zeros.

Design rules that shaped every decision

  • Every point quotes the clause it came from. No quote, no point — the reader can’t make things up.
  • The same flow, always. Read the pages, pull the key terms, flag the risky clauses. There is no shortcut.
  • It is never legal advice. Every summary carries a banner saying so, and high-stakes clauses say “call a lawyer.”
  • A person approves before anything is filed. The system drafts; a human signs off.
  • The house-style folder lives in Drive. Changing a flag rule or the layout doesn’t need a deploy.
  • Every contract and every summary is logged and versioned. You can audit any reading later.

Why this shape

Most owners deal with a long contract in one of three ways: skim it and hope, pay a lawyer to read every page of a routine renewal, or sign it unread and find out later what was in there. Skimming misses the clause that mattered. Sending every routine document to a lawyer is slow and expensive for an NDA you’ve seen a hundred times. And signing unread is how a 30-day cancellation window slips past and a deal you wanted out of rolls over for another two years.

The setup above gives you a fast first read for everything. It pulls the handful of facts you actually need — who, what, money, dates — into one page, and it points a flashlight at the few clauses that tend to bite. It never tells you what to do, because that is a lawyer’s job and the system knows it; it tells you what is there and when the stakes are high enough that a lawyer should look. The expensive human read is reserved for the contracts that earn it, and nothing gets signed because nobody had time to read it.

The next four posts walk through each piece in turn: how a contract gets read, how the key terms get pulled, how risky clauses get flagged, and how the whole summary stays grounded in the actual text. One diagram per post. A cost breakdown and a final engineering reference at the end.

All posts