DEV Community

Multigrid
Multigrid

Posted on • Originally published at multigrid.ai

Extracting Assignment and Change-of-Control Provisions From a Contract

The reason anyone extracts assignment clauses at scale is a transaction: somebody needs to know, across a few thousand contracts, which counterparties have to be asked for consent before a deal closes. That question is not answered by whether the contract is “assignable”.

The question the clause is asked

A boilerplate assignment clause restricts transferring the agreement to somebody else. On its own it says nothing about a share sale, because a share sale does not transfer the agreement — the same legal entity remains a party, with different owners. Contracts that care about this say so explicitly, either by adding a change-of-control clause or by writing a deeming provision into the assignment clause: “a change of control of a party shall be deemed an assignment for the purposes of this Section”.

That deeming sentence is the field. Its presence or absence, far more than the consent requirement itself, decides whether a corporate transaction triggers a consent process across the contract base. The corollary is that the extraction has to be able to distinguish three states, not two: change of control is expressly caught, change of control is expressly excluded (“for the avoidance of doubt, a change of control shall not constitute an assignment”), and the document is silent. Silence is not the same as either, and collapsing it into a false boolean is how a review produces a confidently wrong list.

Transaction structure interacts with all of this in ways that are genuinely contested — whether a merger transfers rights by operation of law can depend on which entity survives and on the governing law, and courts have not treated every structure the same way. This page does not resolve any of that and cannot. What it argues is the narrow consequence for the schema: because the answer turns on which words are present, the extraction must record which words are present. A field named assignable holding false throws away every input to the real question.

Trigger language, word by word

Extract each of these as its own flag, derived from the verbatim span and stored alongside it:

  • “by operation of law”. Its presence widens the restriction beyond voluntary transfers. Its absence is frequently the whole argument.
  • “directly or indirectly”. Reaches a transfer effected at a parent level rather than at the contracting entity.
  • “in whole or in part”. Catches partial assignments and novation of a single order form.
  • The definition of control. Usually a numeric threshold — more than 50% of voting securities, or the power to direct management and policies, or both joined by “or”. Extract the threshold as a number and the test as text, since a 50%-or-more test and a more-than-50% test differ at exactly the value that matters.
  • “all or substantially all of its assets”. The standard formulation covering an asset sale, usually inside a permitted-assignment carve-out rather than in the restriction.
  • Permitted assignees. Affiliates, successors in interest, a purchaser of the business to which the agreement relates. A permitted-assignee carve-out can neutralise the entire consent requirement for the transaction you actually care about, which is why it must be extracted as a list rather than as prose.

Who is bound, and what the consequence is

Assignment clauses are asymmetric far more often than liability clauses are. A supplier agreement may restrict only the customer, or only the supplier, or both, and the sentence signals it with a subject that is easy to lose in a summary. Extract restricted_party as an explicit value in { "customer", "supplier", "both" }, resolved against the defined party names in the document rather than against generic roles — the agreement calls them “Licensor” and “Licensee”, and your corpus needs to know which of those is you.

Then extract the consequence, which is a separate axis and takes more than two values:

  • Prior written consent required. The strong form. Note whether it is qualified — “such consent not to be unreasonably withheld, conditioned or delayed” — because the qualifier changes the practical burden substantially, and it is a separate boolean.
  • Notice only. The transfer is permitted provided notice is given, sometimes within a stated period after closing.
  • Free assignment to a defined class, consent required otherwise.
  • Termination right rather than a consent right. The counterparty cannot block the transaction but may terminate the agreement, often within a window after notice. Commercially this can be worse than a consent requirement, and a schema built around consent will not have anywhere to put it.
  • Price or terms reset. Rarer, but real: a change of control triggers renegotiation or the loss of a discount.

Joining two clauses that never touch

The single most common structural failure here is extracting one clause when the answer lives in two. The assignment clause sits in general boilerplate near the end. The change-of-control provision may sit in the termination section, in a separate clause of its own, in the definitions (where “Change of Control” is defined but the operative consequence is elsewhere), or in a side letter. Each of them is complete-looking on its own.

So the unit of extraction is the document, not the clause. Run a locating pass that finds every span mentioning assignment, transfer, novation, change of control, merger, consolidation or sale of assets, keep all of them with their clause numbers, and only then interpret the set together. Emit a single assignment_position object with an array of source_clauses, so a reviewer can see that the answer came from Section 14.3 and Section 9.2 jointly. That is also the only shape a schema covering several entities in one document has to take, and the only one in which a contradiction between two clauses is visible at all — and contradictions do occur, particularly where a change-of- control clause was added by amendment and the original boilerplate was left alone.

Amendments deserve their own note. If your corpus holds a master agreement and four amendments as separate files, the assignment position is a function of all five, and the last one that speaks to the point governs. An extraction that runs per file and stores per file will show you five answers; the join is yours to build, and it needs each extraction to carry a document date and a reference to what it amends. The published page on how to store extracted documents covers the storage side of that relationship.

Where it goes wrong

  • “Successors and assigns” is not a consent right. “This Agreement binds and benefits the parties and their respective successors and permitted assigns” is a binding sentence, not a restriction. Models regularly return it as the assignment clause because it is the sentence with the word “assigns” in it.
  • An anti-assignment clause with no remedy. Some clauses prohibit assignment without saying what happens if it occurs — void, voidable, or a breach. Extract the stated consequence and leave it null where none is stated, rather than assuming.
  • The consent is deemed given. “Consent shall be deemed given if the party does not respond within 30 days” turns the consent requirement into a notice requirement with a timer, which is the same deemed-outcome mechanism as deemed acceptance of a deliverable and needs the same date fields.
  • Data protection terms constrain it separately. A processor changing hands is a subprocessor question as well as an assignment question; the relevant restriction may be in the data processing addendum rather than in the assignment clause.
  • Clause numbering restarts. Exhibits and schedules often renumber from 1, so “Section 9.2” is ambiguous unless the extraction records which part of the document it came from.

Related

Top comments (0)