Prompt Pilotby Write.law
All prompts

Workflow

Turn a signed contract into obligations somebody owns

Extracts every dated, event-triggered, and standing obligation into a calendar with an owner and a consequence, and separates the ones a reminder can handle from the ones that need a system.

About 20 minintermediateIn-house, Transactional

Your prompt6,527 characters

Still to fill in: The signed agreement, Which side you are, Governing law

RoleYou are an in-house lawyer who has watched a company lose a right because nobody was watching for the event that started the clock. You separate obligations that fail on a date from obligations that fail because a condition quietly became true, and you know the second kind is where companies actually get caught. You refuse to compute a deadline from a date the document does not contain, and you will not leave an obligation without a named owner.What I needTurn the executed agreement below into the obligations calendar for Which side you are under Governing law, with an owner against each.InputsAgreement: The signed agreement Which side we are: Which side you are Governing law: Governing law Who could own these: Who could own these Related documents: Related documentsHow to work this1. Extract obligations into three buckets, because they fail in different ways and need different handling. Date-triggered: a deadline that sits on a calendar. Event-triggered: something happens and a clock starts, and nothing reminds you the event occurred. Standing: a state that has to be continuously maintained, where the breach is a condition rather than a missed date. Most calendars capture only the first bucket, which is why the other two are where the losses are. 2. For every obligation record: the section, the quoted operative language, who owes it and to whom, the trigger, the deadline computed from the trigger, the form required (written notice, a certificate, a specific address, a method of delivery), and the consequence of missing it as the document states it. 3. Compute nothing you cannot compute. Where a deadline runs from an event that has not happened, or from a date the document does not contain, record the formula and mark it [DATE NOT DERIVABLE - supply the effective date or the trigger]. Never supply a date from an assumption about when the agreement was signed. 4. Assign each obligation an owner from Who could own these by function rather than by an individual's name, because names change and calendars do not. Any obligation you cannot assign goes in its own list titled "unowned," because an unowned obligation is the finding, not an oversight in the table. 5. Name the obligations that need a system rather than a reminder: anything continuous, anything that depends on a threshold being monitored, anything requiring records to be kept and produced on request, and anything where the trigger is another party's act that you would only learn about if you were watching. 6. Flag the traps: notice provisions with a required address, recipient, or method; cure periods running from receipt rather than sending; the date a renewal window opens as well as the date it closes; audit and true-up rights lost unless exercised; and anything in Related documents that moves a date here. 7. Produce the handoff: which obligations go to the business with an owner, which stay with legal, what has to be entered into a system today, and the first date on the calendar.Close with these four sections, every time, without being askedAssumptions I made. Every date I derived, every owner I assigned by inference, and every obligation I read as running one way rather than mutually. Mark each [verify] or [safe]. If I assumed an effective date, say so, because every date-triggered row depends on it. Where this is weakest. The two or three obligations most likely to be missed even with this calendar in place: usually an event-triggered one whose trigger nobody is watching, or a standing one that has no owner because it belongs to everybody. What only you can decide. Options with tradeoffs, never a bare flag. At minimum: how far ahead of an automatic renewal window to set the internal reminder. A long lead gives procurement time to run a competitive process and means the reminder fires before anyone has the information to act on it, while a short lead arrives with the data and leaves no room if the counterparty slows down. Also yours: which obligations go into the contract system as tasks against which go to a person, since a system entry survives turnover and a person actually does the work. What would make this materially better. Ranked: the effective date if the document does not state it, Related documents so no date here is superseded, confirmation of who currently holds each function, and whether any obligation has already been triggered or missed.Output formatThree tables, one per bucket, with columns: Section | Quoted language | Who owes whom | Trigger | Deadline or formula | Required form | Consequence | Owner. Then the unowned list. Then "needs a system, not a reminder." Then the traps, each with the section and what it would cost. Then the handoff: business, legal, system, and the first date on the calendar with what has to happen before it.Never do this- If the calendar would fit any commercial agreement, it is too generic. Every row quotes this document and names its section. - No hedging filler. "Notice should arguably be given promptly" is not a calendar entry. Give the trigger, the formula, and the form. Do not tell me to consult an attorney; I am the attorney. - Never supply a date, a notice period, a cure period, or an effective date that the document does not state, and never state how Governing law counts days or computes receipt. Mark each [CONFIRM - governing law] and record the formula as the document writes it. Never invent a citation, and never quote language the agreement does not contain; anything you cannot find is marked [UNVERIFIED - check the executed document]. - Where you cannot tell whether an obligation is mutual or one-way, say you do not know and quote the sentence. Do not assign it to us to be safe, because an over-inclusive calendar gets ignored. - Do not pad. An agreement with eleven real obligations gets eleven rows. Length is not value.Before you answer- Did I compute any date from an effective date the document does not contain? - Is every obligation in exactly one bucket, and did the event-triggered bucket get as much attention as the dated one? - Does every row name a required form, or did I record a deadline with no delivery method? - Is there an unowned list, or did I assign owners to clear the table? - Would this calendar be useless for a different contract? It should be.

The run walks turn one, the pressure test, the follow-up, and a check on what came back. The Cockpit adds driver's-seat tunes. Your values come with either one.

2

Pressure-test it

Makes the AI switch hats and attack its own answer.

Something was missed and nobody can say when. Take the file as the auditor reconstructing it a year later: which row in this calendar would you have no evidence anyone ever looked at, which obligation has an owner on paper and no artifact showing it was performed, and which trigger would have occurred without a single person in the company knowing? Then tell me what has to generate a record rather than a reminder.
3

Go deeper

Pushes the work further once the basics are right.

Calendars decay the moment the person who built them changes jobs. Write the handover note that goes with this one: what the agreement is in three sentences, the two obligations that will actually cause a problem and why, what has already been triggered, where each owner sits, the system entries and what they are named, and the one thing the next person should check in their first week.
4Check what came backPaste the answer here and work a checklist against this prompt's own rules.

Before you run it

What to gather first

  • The signed agreement including exhibits, schedules, and any order form
  • The effective date and the signature date, which are often different
  • Who inside the business could own each kind of obligation
  • The related documents: MSA, SOW, order form, side letter
  • Whether anything has already been triggered or missed

Watch for

  • How days are counted, when notice is deemed received, and whether a deadline falls forward over a weekend are governed by the contract and the governing law. Confirm both before relying on any date here.
  • The model will derive dates from an effective date it assumed. Check every computed date against the executed signature page.
  • Event-triggered obligations are the ones that fail. A calendar full of dates and empty of watchers is a calendar that gives false comfort.
  • Exhibits, order forms, and side letters routinely move the dates in the main agreement. A calendar built from the body alone is wrong in the places that matter.
  • Do not paste executed client agreements unless your company's or firm's AI policy and the engagement terms permit it.

What comes back

Three tables by bucket (date-triggered, event-triggered, standing), each with section, quoted language, who owes whom, trigger, deadline or formula, required form, consequence, and owner. Then the unowned list, a "needs a system, not a reminder" list, the traps with sections and costs, the handoff split across business, legal, and system, the first date on the calendar, and the four closing sections.

See an example of what you’ll get
Date-triggered | § | Quoted | Who owes whom | Trigger | Deadline | Form | Consequence | Owner | |---|---|---|---|---|---|---|---| | 3.2 | "Customer shall pay each invoice within thirty (30) days of receipt" | Us to Vendor | Invoice receipt | Receipt + 30 days [CONFIRM - governing law on when receipt occurs for electronic invoices] | Payment per § 3.4 | Late fee at § 3.5; suspension right at § 9.1 after 60 days | Finance | | 7.1 | "Vendor shall deliver its SOC 2 Type II report annually, on or before March 31" | Vendor to us | Calendar | March 31 each year | Written report | None stated. This is a right with no remedy, which means we have to chase it | Security | | 12.3 | "...at least ninety (90) days prior to the end of the then-current Term" | Us to Vendor, to prevent renewal | Term end | [DATE NOT DERIVABLE - the Effective Date is not in what you pasted. Formula: Term end minus 90 days, and the side letter you mentioned may extend it] | Written notice per § 14.2 | Automatic renewal for a further twelve months | Procurement | Event-triggered. This is the bucket that fails. | § | Quoted | Trigger | Deadline | Form | Consequence | Owner | |---|---|---|---|---|---|---| | 8.4 | "...shall notify the other party within five (5) business days of becoming aware of any Security Incident" | Becoming aware. Nobody is watching for this; it arrives as a Slack message | Awareness + 5 business days | Written notice to the § 14.2 address | Breach of § 8; possible indemnity consequences under § 10.2 | Security, with legal on the notice | | 9.2 | "...may terminate for cause if the breach remains uncured thirty (30) days after written notice" | Our own notice of breach | Notice + 30 days. Runs from receipt, not from sending [CONFIRM] | The original notice must comply with § 14.2 or the clock never starts | Termination right lost or delayed | Legal | | 11.1 | "Either party may audit... upon thirty (30) days' notice, not more than once per calendar year" | Our decision, and it expires annually | Use it or lose it each calendar year | Written notice | A year's audit right lapses silently | Procurement | | 6.3 | "Customer shall notify Vendor of any change in the Permitted Users exceeding ten percent (10%)" | A headcount threshold crossing. No person observes this; a system does | On crossing | Written notice | True-up at list price under § 6.4 | IT, systematically | Standing | § | Quoted | What has to stay true | Consequence | Owner | |---|---|---|---|---| | 8.1 | "Customer shall maintain commercially reasonable technical and organisational measures" | Continuous | Breach; indemnity exposure | Security | | 5.2 | "...shall not permit access by any Competitor of Vendor" | Continuous, and it depends on who a Competitor is, which is defined at § 1.6 | Termination for cause under § 9.2 | Unowned. See below | | 13.1 | "...shall maintain insurance with limits not less than those in Exhibit C" | Continuous, with certificates on request | Breach; possible indemnity gap | Risk or finance | Unowned. § 5.2, the competitor-access restriction. Nothing in {{internal_owners}} covers "who decides whether a new customer or partner is a Competitor under § 1.6." This is the obligation most likely to be breached, because breaching it requires nobody to do anything wrong and no function to be asleep. It needs an owner before this calendar ships. Needs a system, not a reminder. § 6.3 (the ten percent user threshold, which no human will notice), § 8.1 and § 13.1 (continuous states that need evidence generated, not a date), and § 5.2 (a check that has to run when a new relationship is onboarded, not on a date). Traps - § 14.2 notice address and method. Courier or certified mail only. An email notice of breach under § 9.2 does not start the cure clock, which means the termination right does not arise when you think it does. - Cure runs from receipt. [CONFIRM - governing law] Build the calendar entry from receipt, not from the day the letter goes out. - § 12.3 renewal window. The date the window opens matters as much as the date it closes; procurement cannot run a process in the last week. - The 2025 side letter. You mentioned it extends the renewal notice window. Until it is in front of me, every § 12.3 date above is provisional. Handoff. To the business: § 3.2 (finance), § 7.1 (security), § 12.3 and § 11.1 (procurement), § 6.3 (IT, as a system rule). To legal: § 9.2, all § 14.2 notice mechanics, and the § 1.6 Competitor determination once it has an owner. Into the contract system today: § 12.3 with a lead time, § 11.1 as an annual task, § 7.1 as an annual inbound expectation. First date on the calendar: whichever is earlier, the § 12.3 renewal window opening or March 31. Neither can be fixed until you supply the Effective Date. --- Assumptions I made. That "thirty (30) days" throughout means calendar days, since the document says "business days" where it means business days [safe, on the language you pasted]. That we are the Customer for all purposes and the licensor only under Exhibit D [verify: if Exhibit D reverses any obligation above, the direction of § 8.4 changes]. No effective date assumed anywhere, which is why three rows carry a formula instead of a date. Where this is weakest. § 5.2 will be breached, and nothing in this calendar prevents it, because an unowned continuous obligation is not on anyone's list by definition. Second, § 8.4's five-business-day incident notice depends on "becoming aware," which is a state of the company rather than of a person; in practice the clock starts before anyone tells legal, and a calendar entry does not fix that. Third, every § 12.3 date is provisional until the side letter and the effective date arrive, and § 12.3 is the obligation with the largest financial consequence on this list. What only you can decide. How far ahead of the § 12.3 window to set the internal reminder. Ninety days before the window opens gives procurement time to run a competitive process and means the reminder fires before anyone has usage data or a renewal quote to act on; thirty days arrives with the data and leaves no room if the vendor slows down. Second call that is yours: whether § 6.3's threshold monitoring goes into a system or onto IT's list. A system entry survives turnover and costs a build; a person on a list costs nothing and leaves with them. What would make this materially better. Ranked by impact: (1) The executed signature page with the Effective Date, which unlocks three rows including the renewal. (2) The 2025 side letter, which may already have moved the § 12.3 window. (3) An owner for § 5.2. (4) Confirmation of whether any incident, breach notice, or audit has already been triggered under this agreement, since this calendar assumes nothing has.
Why this prompt is built the way it is
## Framework 1. **Three buckets, because they fail differently:** date-triggered, event-triggered, and standing. The second and third are where companies get caught. 2. **Record for each:** section, quoted language, who owes it to whom, the trigger, the deadline computed from the trigger, the form required, the consequence of missing it. 3. **Compute nothing you cannot compute.** Record the formula where the trigger has not happened, and mark it. 4. **Assign an owner by function.** An obligation with no owner gets its own list. 5. **Name what needs a system rather than a reminder.** 6. **Flag the traps:** notice addresses and methods, cure periods running from receipt, auto-renewal windows, rights that require action to preserve, and related documents that move a date. 7. **Produce the handoff** and the first date.