build.allanninal.dev

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

How the key terms get pulled

Now the system has the contract as a list of numbered clauses. The next job is to pull the handful of facts a busy owner actually needs — who is signing, what the deal is, the money, the dates, how it renews and how to get out — into a fixed shape. A single Bedrock Haiku 4.5 call does the reading. Haiku is the cheap, fast model; it is the right tool for fill-in-the-blanks work like this. The shape itself never changes; the model only fills it, and every field it fills has to name the clause it came from.

Key takeaways

  • One Haiku 4.5 call fills a fixed shape of six fields. The shape is decided in code, not by the model.
  • The six fields: parties, deal, money, key dates, renewal and cancellation, and a notes line.
  • Every field carries the clause number it came from. A field with no clause is left blank, not guessed.
  • The model is told plainly: do not invent a number or a date that isn’t in the clauses.
  • Haiku is the cheap path. The stronger Sonnet model is saved for the risk read in Part 4.

The fill flow, per contract

How a Haiku call fills the fixed term shape A vertical flow diagram. At the top, an input box "Clauses from intake" with the numbered clause list for this contract. Below that, a step "Load the fixed term shape" — the six empty fields read from the house-style doc: parties, deal, money, key dates, renewal and cancellation, notes. Below that, a step "Build the Haiku prompt" — the clauses plus the empty shape plus the instruction to fill each field and name the clause it came from, and never invent a missing value. The next step "Call Bedrock Haiku 4.5" — the cheap, fast model fills the shape. The next step "Check each field cites a clause" — every filled field must name a clause number that exists; if a field cites nothing, it is treated as missing. The next step "Drop or blank unsupported fields" — a field with no real clause behind it is cleared, not kept. The four terminal boxes show where each field lands: Parties and deal, Money, Key dates, Renewal and cancel — each written to the term sheet in S3 with its clause numbers attached. A note at the bottom: the shape is fixed in code; the model only fills it, and a blank field is honest where a guess is dangerous. Clauses from intake clause 1 · clause 2 · clause 3 … Step 1 Load the fixed term shape six empty fields Step 2 Build the Haiku prompt clauses + shape + rules Step 3 Call Bedrock Haiku 4.5 cheap, fast — fills the shape Step 4 Each field cites a clause? cited → keep not cited → blank Step 5 Drop unsupported fields no clause behind it → clear Parties + deal who and what Money price, terms, fees Key dates start, end, notice Renewal + cancel rollover, how to exit parties deal renewal money dates The shape is fixed in code — the model fills it, and a blank beats a guess.
Fig 3. The term pull, per contract. The shape of the summary is fixed in code; the Haiku call only fills the six fields, and every field has to name the clause it came from. A field with no clause behind it is left blank rather than guessed.

The fixed shape: six fields, decided in code

The summary always has the same six fields, in the same order, whether the contract is a two-page NDA or a forty-page master services agreement. Parties: who is signing with whom. Deal: what is being bought, sold, or agreed. Money: the price, the payment terms, any late fees. Key dates: when it starts, when it ends, and any notice windows. Renewal and cancellation: how it rolls over and how to get out. And a short notes line for anything that doesn’t fit the first five but a reader would want.

The shape lives in the house-style doc, so you can reorder it or rename a field without touching code. What you can’t do is let the model decide the shape. That’s on purpose. If the model picked the fields, two contracts would come back looking different, and the value of a summary is that it always looks the same — you learn where to glance for the money and it’s always there.

Cite the clause, or leave it blank

The single most important rule in this step: every field the model fills has to name the clause number it came from. The prompt is short and firm: “Fill each field from the clauses below. After each field, name the clause number you used. If a field isn’t in the contract, leave it blank. Do not invent a number, a date, or a name that isn’t in the text.”

After the call, a plain Python check reads each field. If a field is filled but names a clause that doesn’t exist, or names no clause at all, the field is cleared. A blank money field that reads “not stated in this contract” is honest and useful. A made-up payment term that looks right but isn’t in the document is the kind of mistake that costs real money. So the system always prefers the blank. This is the same idea you’ll see again in Part 5, applied here to the easy fields before the risky clauses get the stronger model in Part 4.

Why Haiku here, not the stronger model

Pulling the parties, the price, and the dates is fill-in-the-blanks work. The facts are usually stated plainly in the contract — “this Agreement is between X and Y,” “the Fee is $1,450 per month” — and the job is to find them and copy them into the right field with the clause number attached. That is exactly what a cheap, fast model is good at. Haiku 4.5 does it in a second or two for a fraction of a cent, and the citation check catches the rare miss.

Saving the stronger Sonnet model for the risk read in Part 4 is a deliberate cost choice. The risky clauses — liability caps, auto-renewal traps, personal guarantees — need real reading-between-the-lines judgment, and there are only a few of them per contract. Spending the bigger model where the stakes are high and the cheap model where the facts are plain keeps the whole thing in coffee-money territory, which Part 6 lays out in full.

What comes out

The output of this step is a small term sheet written to S3: six fields, each with the text the model pulled and the clause numbers behind it. It is not the final summary yet — the risky clauses haven’t been read and the not-legal-advice banner hasn’t been added. But it is the backbone: the who, what, money, and dates that anyone reading the contract would want first, every one of them traceable to a line in the actual document.

Next post: how the system finds the few clauses worth a closer look, and how the stronger Sonnet model reads each one and says why it matters — and when to call a lawyer.

All posts