A software licence is not one document, and that is the whole problem.
A master agreement grants a right. An order form narrows it for one product. An addendum controls where personal data is involved. A schedule defines the licence model the order is counted in. The answer to “are we compliant?” almost never lives in the document you opened.
I built this to understand that problem properly, not as a product. It is a work in progress, and the honest limits are set out at the bottom of this page rather than left for you to find.
Step one: read the agreements without a model
Before any AI is involved, the documents are parsed deterministically — the same input always produces the same output, and every field can be traced to the words that produced it. That pass classifies each document, splits clauses from the lists beneath them, extracts defined terms, resolves cross-references, identifies the parties, and reads each operative sentence into a structured rule.
- Effect
- OBLIGATION
- Modality
- SHALL
- Polarity
- POSITIVE
- Actor
- Customer
- Action
- pay for
- Object
- Excess Use based on SAP’s prices
- Effect
- Modality
- MAY
- Polarity
- POSITIVE
- Actor
- SAP
- Action
- include
- Object
- Customer’s name
The distinction that matters commercially is effect: an obligation you must meet, a permission you may rely on, a prohibition that ends a deal. Both examples above are checked twice — the deterministic reading and the model reading agree, and every field appears verbatim in the quoted sentence.
- 18contractual roles recognised
- 6 / 20document classes and types
- 20relationship types between clauses
- 0model calls in this step
Step two: AI sharpens each clause — it does not build the map
A local model re-reads each clause in isolation and re-derives what that clause says, inside a strict schema, validated against the exact quoted text it was given. Where it produces a reading that validates, that reading replaces the deterministic one for that clause. Where it does not, the deterministic reading stands.
What AI does not do here: it does not discover the relationships between documents. Precedence, which rule overrides which, which definition controls — all of that is computed by the same deterministic pass whether or not the model has run, and the results are rebased onto the model’s readings afterwards so that a difference in wording cannot silently sever a precedence chain.
A frontier cloud model could do this step well — that is not the constraint. The constraint is context: as an agreement family grows, the work is finding the handful of provisions that govern a question, not reading any one of them. Because the graph does that finding, the model reading each clause can be small — an open-weight model running on this machine, with agreement text never leaving it — and with that context the results hold up against far larger cloud stacks.
Step three: the part a single document cannot tell you
This is a real order of precedence, read out of SAP’s own published cloud agreement set — eight documents, forty-three pages. The ranking is stated in one paragraph of the shortest document, and it silently governs the other seven.
- 1 Order Form — where the ranking is stated
- 2 Supplemental Terms — referenced, not in the set
- 3 Support Schedule
- 4 Service Level Agreement
- 5 Data Processing Agreement
- 6 General Terms and Conditions — ranked last
The General Terms and Conditions is the longest document in the set and the one anybody would reach for first. It is bottom of the ladder. Nothing inside it says so — a reader who starts there has no way to find out. And Document 2 is referenced but absent, which the tool reports rather than quietly matching to the nearest similar-sounding document.
If the Support Schedule and the General Terms and Conditions disagree, which one controls?
The Support Schedule. It is Document 3; the General Terms and Conditions is Document 6. Nothing in either document says so — the ranking is only in the Order Form, and a reader who opens the two documents that are actually in conflict will not find the answer in either of them. This is the live answer, not a mock-up.
What it does not do yet
These are measured, not estimated, and they are here because a tool that hides its gaps is not one you should trust with a contract.
- Liability caps and exclusions are not represented. The rule vocabulary has permission, obligation and prohibition — there is no way to express “no obligation to” or a cap on damages, so the clauses a negotiator cares about most are the ones currently missing from the map.
- Negation is lost on some list items. Where a list sits under “Customer shall not:”, each item inherits the negation from the sentence above it. Measured on real vendor documents, 75% of those items keep it in one corpus and 40% in another. It should be 100%.
- The strongest override in this set is not on the map. SAP’s Product Development Schedule says “notwithstanding anything in the Agreement” and displaces the Data Processing Agreement for one narrow purpose. The tool answers that question correctly, but from retrieval — the graph holds no edge for it, because that document is not on the ladder and “notwithstanding” is not yet read as a precedence signal.
- The corpus is ten vendors, not hundreds. Roughly ninety real documents, with five further vendors held back and never tuned against, to check that the rules generalise rather than memorise.
See it work
The sample loads in one click — SAP’s own published cloud agreement set, the eight documents ranked above, already parsed and enriched. Nothing to upload. You can also load your own documents; they stay on this machine and are deleted when the session expires.
Open the live tool →Alpha software, and not legal advice. Automated extraction and language models can be incomplete or wrong. The exact agreement text remains the source of truth.