Auto-renew and anomaly detector

The job is quality, not volume. Flag auto-renew clauses, notice windows, price-increase mechanics, and term-end dates from the signed packet so a renewals or legal-ops lead can decide whether anyone should act. If the paper is silent on a date, leave the field empty. Do not invent a notice date to make the record look complete.

A detector that fills blanks will trigger calendars, Salesforce tasks, and customer emails on dates nobody can show in the PDF.

Treat clause extractors such as Sirion or LinkSquares as one class of input: they help you find language in a corpus. They are not a ranking, and they are not the contract of record. The signed packet is. Wire extraction to the same signed-contract data extraction fields your team already uses for term, product, and party, so an anomaly is a disagreement with the executed paper rather than a new parallel dataset.

Flag a queue item when auto-renew is on but notice timing is missing, contradictory, or tied to a document other than the in-force order; when a price-increase clause is unclear, or would apply only if a quote SKU is treated as renewing; when term-end and auto-renew disagree; or when the only renewal language sits in a draft, redline, or playbook. Everything else is context for the human, not an automatic outbound.

Start with the executed packet: the signed MSA or services agreement, the signed order or SOW that names SKUs and fees, and any signed amendment that changes term, notice, or price. If your CLM (Ironclad sits in this class with other repositories) stores multiple versions, pin the detector to the executed file, not the latest Word draft and not the preferred legal template.

Alerting on a draft is a primary failure mode. A draft may still show 30-day notice while the signed PDF says 90 days, or the reverse. The queue then trains people to ignore alerts, or to email the customer on the wrong clock.

Confirm the file is signed (wet-ink or certified e-sign). If signature blocks are empty, stop and do not extract dates from that file. Identify the commercial document that actually renews, usually the order, not MSA boilerplate that never attached to products the customer bought. List SKUs, quantities, and fees from that order and in-force amendments only. A SKU on a quote, a QBR slide, or a Salesforce opportunity but not on the signed order is not renewing. Treating it as in-term is the SKU failure mode: you flag a fake auto-renew and may quote an increase on something the customer never bought. Only then read auto-renew, notice, price-increase, and term-end against those SKUs.

If the MSA and the order conflict, flag the conflict. Do not pick a winner in the model. The human decides which document controls, using clause precedent retrieval when the question is whether the company has accepted a notice construct before, not when the question is what this customer signed.

Do not run four disconnected prompts that can disagree. One pass over the executed packet should fill one review record.

Auto-renew: is the term set to renew unless a party gives notice? Which party? Does it cover all order SKUs, a subset, or a threshold? Quote the clause. If auto-renew is absent, record absent. Do not infer it from a twelve-month term or from a Salesforce renewal date typed by hand.

Notice: what window is stated, how must notice be given, and who is the notice party? If notice is required but no number of days is stated, leave the date empty and flag that timing is not stated. Calculating a calendar date from a guessed standard window is inventing a notice date.

Price increase: is there a fixed percent, index, list-price reset, or then-current fees language? Is consent required? Is it capped? Do not apply an increase to a SKU that is not on the order.

Term-end: what initial end date is stated, and how does it interact with auto-renew? If the order states an end date and the MSA rolls successive terms, record both. Do not collapse them into a Salesforce close date until a person confirms.

Write each field as a value if the signed packet states it, empty if silent, and a short note if two signed pages disagree. That is the quality outcome: notice windows and anomalies from the signed packet, with blanks where the paper is silent.

If champion-departure monitoring shows the named notice contact has left, that is delivery risk on a real obligation, not a contract anomaly. Keep those queues separate.

A renewals lead opens an account whose Salesforce renewal date is already filled. The signed MSA says the agreement auto-renews for successive one-year terms unless either party gives written notice at least sixty days before the end of the then-current term. The signed order names two SKUs, a start date, and a twelve-month initial term. It does not repeat the notice period. An unsigned quote in the file adds a third SKU at a higher unit price. A Word draft of the MSA still shows thirty-day notice from an earlier redline.

The detector should bind auto-renew and the sixty-day written notice to the signed MSA, and bind the two SKUs and the twelve-month initial term to the signed order. Leave any notice-due-date calculation empty until a person confirms term-end from the order and applies the sixty-day rule. If the order has only a start date and a duration, not a calendar end date, do not invent the anniversary; flag that term-end is not stated as a calendar date. Ignore the draft's thirty-day language. Do not treat the third SKU as renewing, and do not flag a price bump on it. Note that the SKU is on a quote only, not on the signed order.

The human decides whether to send notice, offer a renewal, or ask counsel about the MSA and order. The model does not send the email. This is the shape of a correct pass, not a case study: signed packet over draft, order SKUs over quote SKUs, empty fields over invented dates.

Route every flag to a renewals or legal-ops review queue before Salesforce sequences, customer-success mail, or an auto-generated QBR mentions cancellation windows or next-year price. Use confirmed facts in the QBR only after that review.

Each queue item needs links to the signed PDF pages, not a draft; auto-renew as present, absent, or conflicting, with a clause quote; notice timing and method if stated, otherwise empty; price-increase mechanism if stated, otherwise empty; term-end as a calendar date only if the packet states one; SKUs limited to in-force order lines; and anomalies named as draft-versus-signed mismatch, SKU-not-on-order, silent notice, or conflicting term language.

Do not auto-create a customer-facing task that includes a date the model computed. If you use Salesforce as the system of action (the same class as other CRMs), create an internal review task. A person copies a date into a customer email only after they have opened the PDF.

Ironclad, Sirion, LinkSquares, and Salesforce can all sit on the path as repository, extractor, and CRM. None of them should notify the customer from an unreviewed extraction. If a churn-risk prediction model raises the priority of the review, it still must not skip the review or fill a blank notice date so a playbook can run.

Close the loop as reviewed, notice date confirmed or left empty, SKU list confirmed, and customer communication allowed or blocked. Quality is a signed-packet flag a lead can defend.