Clause extraction — no pinpoint, no claim (step 2/7) · legal studio

The playbook as data

Run it. Three extracted clauses, three different fates — and notice the shape of each entry before the loop even matters.

Every playbook clause carries four fields. source names the approved template and version the language came from — "MSA template v9 § 11", not "the version Dana emailed around in March." preferred and fallback are the two positions counsel will accept without a conversation. owner is the human, by name, who decides everything else. Nothing in this structure was generated; it's counsel's judgment serialized so a loop can read it. That division of labor is the whole design: the model extracts, the code compares, the playbook decides what's acceptable, and a named person decides what the playbook doesn't cover.

Now the three fates:

limitation_of_liability → MARK-UP. The counterparty's paper caps at 24 months — not our preferred 12, but exactly our written fallback. Acceptable, noted in the mark-up, no meeting required. This is the row that shows why the playbook has two positions: a one-position playbook escalates half the contract and trains everyone to ignore escalations.
indemnification → REOPEN. The model's summary is alarming — "customer indemnifies vendor for all claims" — and it has no pinpoint. Which means right now it's an alarming rumor. Maybe the clause really is that bad; maybe the model paraphrased three sections into one scary sentence. You don't argue with an unpinned row and you don't act on it either. You reopen the document at the indemnification section and extract again. Rejection here isn't distrust of AI; it's the same standard you'd apply to a junior associate's memo that cited nothing.
governing_law → ESCALATE → D. Chen. Texas is neither preferred (Delaware) nor fallback (New York), so the code's involvement ends and D. Chen's begins. Note what the code does not do: it doesn't rank how bad Texas is, doesn't suggest a compromise, doesn't draft the counter. Outside the playbook, the only correct machine output is a name.

One habit to carry out of this step: when a status prints OK, that's the triage passing, not the review finishing. The pinned clause still gets its pinpoint spot-checked against the actual § 9.3 before the mark-up goes out — same discipline as opening the cited case. The triage tells you where to spend your reading. It never tells you not to read.

The playbook as data

Run it. Three extracted clauses, three different fates — and notice the shape of each entry before the loop even matters.

Now the three fates:

limitation_of_liability → MARK-UP. The counterparty's paper caps at 24 months — not our preferred 12, but exactly our written fallback. Acceptable, noted in the mark-up, no meeting required. This is the row that shows why the playbook has two positions: a one-position playbook escalates half the contract and trains everyone to ignore escalations.
indemnification → REOPEN. The model's summary is alarming — "customer indemnifies vendor for all claims" — and it has no pinpoint. Which means right now it's an alarming rumor. Maybe the clause really is that bad; maybe the model paraphrased three sections into one scary sentence. You don't argue with an unpinned row and you don't act on it either. You reopen the document at the indemnification section and extract again. Rejection here isn't distrust of AI; it's the same standard you'd apply to a junior associate's memo that cited nothing.
governing_law → ESCALATE → D. Chen. Texas is neither preferred (Delaware) nor fallback (New York), so the code's involvement ends and D. Chen's begins. Note what the code does not do: it doesn't rank how bad Texas is, doesn't suggest a compromise, doesn't draft the counter. Outside the playbook, the only correct machine output is a name.

Clause extraction — no pinpoint, no claim — step 2 of 7

The playbook as data

The playbook as data