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

How a summary stays grounded

The terms are pulled and the risky clauses are flagged. Now the summary draft has to become something you can trust enough to act on — and that means three things have to hold. Every point traces back to the actual contract. Nothing in it pretends to be legal advice. And a person signs off before it’s filed or sent anywhere. This post walks through the three things the system can do with a finished draft — approve, send to a human, or hold — and how the grounding, the banner, and the audit trail keep it honest.

Key takeaways

  • Three things happen to a draft: approve (file and deliver), send to a human (a lawyer should see it), hold (park it).
  • Grounding is the rule: every point quotes its clause, or it never reaches the draft.
  • The not-legal-advice banner sits on top of every summary, no exceptions.
  • A high-stakes clause routes the draft to a human before it counts as done.
  • Every action is logged with the contract version, who acted, and when.

Three things on a finished draft

Three things that happen to a finished summary draft A diagram showing one input on the left flowing into a finished summary draft, then branching into three action paths. Far left: a "Summary draft" box showing the one-page layout — parties, money, key dates, flagged clauses, each with its quoted clause — and the not-legal-advice banner across the top, with three button placeholders below: Approve, Send to a human, Hold. The owner taps one. The middle column shows the three branches. Branch one, Approve: a Function URL Lambda files the summary against the contract version in S3, delivers it to the chosen place (Drive folder, email, or Slack), and writes an approved event to the audit trail. Branch two, Send to a human: used when a flag is high-stakes or the owner just wants a second pair of eyes; the Lambda forwards the summary and the quoted clauses to the configured lawyer or manager, marks the job as awaiting a human, and writes a sent-to-human event. Nothing is filed as final until the human responds. Branch three, Hold: parks the draft without filing or sending; the owner can come back to it later. The chosen contract isn't changed. The right side shows the convergence: every action writes a row to the cs-audit DynamoDB table with timestamp, contract id, summary version, action, by-user, and notes. A note at the bottom: a summary is always a draft a human signed off on — the system reads and drafts, a person decides. Summary draft six blocks + banner [Approve] [Send to a human] [Hold] Action 1 Approve • File against the contract version in S3 • Deliver to Drive/email/Slack • Write approved event Action 2 Send to a human • Forward to lawyer or manager with quotes • Mark awaiting a human — not final yet Action 3 Hold • Park the draft, come back to it later • Nothing filed or sent — contract unchanged Audit trail DynamoDB cs-audit timestamp · contract_id version · action · by-user notes A summary is always a draft a human signed off on — the system reads and drafts, a person decides.
Fig 5. Three things an owner can do with a finished draft, three different effects. Approve files and delivers it. Send to a human routes it to a lawyer or manager. Hold parks it. Every action writes to the audit trail, and a high-stakes flag steers the draft toward a human before it counts as done.

Grounding: every point traces to the contract

You’ve seen the rule in Parts 3 and 4: every field in the term pull names its clause, and every risk flag quotes its clause. This is grounding, and it’s the single thing that makes the summary worth trusting. A model left to its own devices will write a confident, fluent, plausible summary — and quietly slip in a payment term that isn’t there, or a renewal date off by a month. Grounding makes that impossible to hide: if a point can’t point at the text it came from, it never reaches the draft.

The practical effect is that the summary is checkable. Next to every number and every flag is the clause it came from, quoted. You don’t have to take the system’s word for the late-fee rate — clause 4.3 is right there. This is why the read step splits the contract into numbered clauses in the first place: so that “trust me” is never the answer. The answer is always “here’s the line, read it yourself.”

Every summary carries a banner across the top, in plain words: “This is a plain-English reading of your contract, not legal advice. For anything that matters, talk to a lawyer.” It’s not fine print and it’s not optional — the summary writer adds it to every page, and there is no setting to turn it off.

The banner isn’t just a disclaimer; it reflects how the system is actually built. The flags say what a clause says and why it matters — never what you should do about it. “This caps the vendor’s liability at one month’s fees” is a reading. “You should reject this clause” would be advice, and the system never crosses that line. The wording is checked: the summary writer is told to describe and explain, not to recommend, and the rare sentence that drifts into “you should” is rewritten or dropped. The point of the whole system is to make a busy owner a faster, better-informed reader — not to replace the lawyer they should call when it counts.

When the stakes are high, a human decides

The middle branch — send to a human — is the system’s safety valve. It fires in two cases. First, automatically: when Gate 4 from Part 4 marked a flag high-stakes (a personal guarantee, an unusual liability cap, a short-notice auto-renewal), the draft is steered toward a human and isn’t treated as final until one has seen it. Second, on demand: any owner can tap “Send to a human” on any summary, for any reason, and the draft plus its quoted clauses go to the configured lawyer or manager.

This is the human-in-the-loop rule made concrete. The system is allowed to read fast and draft well, but it is never allowed to be the last word on something that could put the business at real risk. On those, a person who is qualified to decide is always in the loop before anything counts as done. The system’s job is to make sure that person sees the right contracts, with the risky clauses already quoted and explained, so their expensive time is spent deciding rather than hunting.

Every action logged, every version kept

The cs-audit table records every approve, send-to-human, and hold, with the contract id, the exact summary version, the user who acted, the timestamp, and any notes. S3 keeps every version of the contract and every version of the summary, so a summary approved in May can be pulled up next year exactly as it read then. If a contract is re-uploaded after an amendment, it gets a new version and a fresh summary; the old one stays on file.

This matters most for the contracts you’ll only revisit once — at a dispute, at a renewal, at an audit. The next person to ask “what did we actually agree to?” gets the summary, the quoted clauses, and the record of who approved it. The audit trail is the memory the business keeps long after the person who signed has moved on.

Next post: the cost breakdown. The whole pipeline above runs in coffee-money territory at SMB volume; Part 6 explains exactly where the dollars go and why the stronger model doesn’t break the bank.

All posts