A new contract lands on the reviewer's desk. It is a side deal that lowers one merchant's fee for a single quarter. The reviewer pauses. Didn't this same merchant sign something last year that changed how often they get paid out? Nobody remembers exactly how that one was resolved.
Several contracts with that merchant's name are sitting on file somewhere. The original agreement, a deal from when their business changed, a volume discount, a seasonal promotion. Each was written at a different time, by a different person, in different wording. The only way to check whether the new deal clashes with any of the old ones is for someone to remember all of them and go compare, by hand.
The material: a merchant’s contracts and amendments
A card company signs a contract with every merchant that accepts its cards. But it is rare for a merchant to end up with just one. On top of the original agreement, new terms get added whenever the merchant's business changes, a better fee gets attached once they process enough volume, and a seasonal promotion gets tacked on from time to time. Here is what usually piles up on a single merchant.
- The original contract, signed when the merchant first joined. Everything else builds on top of it
- A follow-up agreement from when the merchant's line of business changed
- A volume discount, added once the merchant was processing enough transactions
- A seasonal promotion, added separately each time one runs
- The same kind of term, such as how often they get paid or what the fee is, worded slightly differently in every one of these
- Many of these only exist as scans or PDFs, and the fee itself is often sitting inside a table, not written out as a sentence
- Each one written at a different time, by a different person, so nothing reads the same way twice
None of these terms exist in isolation. Add a new contract, and you have to check it does not clash with an older one for the same merchant. Two live fee rates on the same transaction. One contract says paid monthly, another says weekly. A seasonal promotion that quietly contradicts the original agreement. These conflicts do not announce themselves. They surface later, when the payout goes out wrong.
Manual comparison of current and past agreements
Today's process is simple to describe. A new contract comes in, and the reviewer tries to recall every existing contract tied to that merchant, tracks them all down, and lines them up to compare by hand. That works fine when a merchant only has two or three contracts. It stops working once a merchant has accumulated a stack of them, because remembering every one, without missing a single one, is not something a person can reliably do.
Searching does not save you here either. "Could this new contract conflict with something already on file?" is not a question keyword search can answer, because a conflict has nothing to do with which words match. It only shows up once you actually trace how the merchant, its contracts and their terms relate to each other. And even when two contracts describe the exact same condition, they rarely use the exact same words, so it is often unclear at a glance whether two clauses are even talking about the same thing.
Import contracts and connect their terms
The setup happens once. Every contract goes in, gets read, and the important pieces, the merchant, the contract, the fee terms, get pulled out and linked to each other. Different wordings for the same idea are folded into one. After that, the connections are just there to follow.
Getting the merchant contracts in
Feed the contracts to "Extract sources" (⌘⇧I)
Contracts that only exist as scans or PDFs are read with OCR, the technology that turns a scanned image into text a computer can search. The structure of any table holding a fee rate is kept intact, not flattened into plain text, because a fee rate loses its meaning the moment the table around it collapses.
Tell it which words mean the same thing, in "Domain vocabulary"
In the "Domain vocabulary" panel in the left rail, you can say that "monthly settlement" and "settled once each month" mean the same thing. From then on, both phrases collapse into the same single concept, no matter which contract used which wording.
Activity center's "Build this workspace's knowledge graph?" → "Build"
This pulls out every merchant, contract and fee term as its own item, and links them: this merchant has these contracts, this contract has these fee terms. The original contract files are untouched. This map sits alongside them.
Skim the results in the "Entity table"
This is where you check that merchants, contracts and fee terms came out the way you expected, and where you see for yourself, for the first time, just how many contracts had quietly piled up on one merchant.
Ask which contracts might conflict
"@promotional-fee-side-agreement Show me every contract signed with this merchant."
→ Starting from the merchant and following the connections, every contract
tied to them appears on one screen: the original agreement, the
business-change deal, the volume discount, the seasonal promotion.
Because it follows connections instead of matching keywords, contracts
the reviewer had forgotten about come up too.
"Could anything here conflict with this side agreement's fee rate?"
→ Wherever two fee rates would be live on the same transaction, or a
clause contradicts the original contract, it gets flagged as a possible
conflict, with the exact sentence and the contract it came from attached.
"How is this merchant's payout schedule written across their contracts?"
→ "monthly settlement" and "settled once each month" have already been
merged into one idea, so if one contract says monthly and another says
weekly, the two show up side by side as a contradiction.This works because the contracts are stored as connected facts, not as blocks of text to search. Start at one merchant, follow which contracts belong to them and which terms belong to those contracts, and everything connected shows up on one screen. Nobody has to remember the full list first.
Every fact still says which contract it came from. Hover over a connection and the exact sentence it is based on shows up, with a citation to the document and line. The page also has an "In your words" view showing the wording the contract actually used, so even after two phrasings get merged into one concept, you can still see what each contract originally said. Instead of checking every contract from scratch, the reviewer checks the spots the system points to.
What could change
| Before | Now |
|---|---|
| The reviewer tries to remember every related contract, tracks them all down, and lines them up by hand | Start at one merchant and every connected contract and term shows up on one screen |
| "Which contracts could conflict?" is not something keyword search can catch | Because it follows connections, even contracts the reviewer had forgotten about get pulled in |
| The same term is worded differently in every contract, so it is hard to tell whether two clauses even mean the same thing | Say once in "Domain vocabulary" that two phrasings mean the same thing, and every contract using either one lines up together |
| With no way to know whether you missed a related contract, every review starts from scratch | The system narrows down the spots worth a second look, and the reviewer's judgment goes on top of that |
Still, the reason this is worth trying on real data is the shape of the question itself. "Could this contract conflict with something else?" can only be answered by tracing from merchant to contract to fee term. Store the contracts as connected facts instead of documents, and that trace is simply there to follow.
Try this workflow with your documents
Learn the steps behind this workflow, then try them with your own sources.
Open the lesson ↗