They sent it back "with your changes." Which ones, exactly?
The plan: Sidecar would compare their draft against yours and report what they took, what they refused, and what they changed without mentioning it. The comparison engine exists; the flow you would use does not, and the panel below says so.
In development — not available yet
The comparison engine is built and tested against real filed contracts. The part you would use — upload their draft, get the report — is not wired up yet. Agreement reviews, including the negotiation asks this builds on, are live today.
The second draft is where deals quietly get worse.
You asked for five changes. The revised contract arrives with a friendly note saying they have accommodated your feedback. It is forty pages. You have a call in twenty minutes.
So you check the two clauses you remember arguing about, see that they moved, and sign. What you did not check was section 11.2, where the cure period went from thirty days to ten, which nobody mentioned and which you will discover the first time you are late on something.
This is not sharp practice so much as ordinary drafting. It is also how the terms you negotiated for get handed back a little worse than you left them.
Every change accounted for.
Which asks they actually took
Every change you requested, marked accepted, partly accepted, refused, or quietly ignored — each one pointing at the language in their draft that settles it.
What they changed without telling you
The edits nobody flagged in the cover email. A cure period shortened from thirty days to ten. A cap that moved. This is the part that pays for the review.
An updated verdict
Whether the revised draft is now signable, and if not, precisely what is still in the way — on the same five-rung scale as the original review.
Your next move
What to push on in the next round, what to concede, and the talking points to send back.
Code finds the changes. The model only explains them.
This distinction is the whole product, so it is worth being exact about. Hand two long contracts to an AI and ask what changed, and you get a confident, readable, mostly correct answer — with no way to tell which edits it left out. The omission looks exactly like the absence of an omission.
Sidecar does the finding in code. Every changed region between the two documents is identified deterministically first, and the model is then asked only to explain regions it has been given. A change can end up poorly explained. It cannot end up missing.
The hard part turned out to be alignment, not comparison. Their draft comes out of a different system than yours: different line wrapping, different quote characters, sections renumbered because one got inserted near the top. Compared naively, every paragraph looks different and the answer becomes "everything changed," which is worse than useless because it looks like an answer. Sidecar's comparison ignores layout entirely — tested against real contracts filed with the SEC, re-wrapping a document, re-indenting it, and stripping out its blank lines produce no false changes at all.
Running headers and footers are the deliberate exception. A "CONFIDENTIAL" stamp repeated across forty pages does show up as forty additions when only one side is paginated that way, and filtering it out was built and then removed: doing so means reading page layout, which on a re-formatted document quietly deleted real contract text. Visible noise a reviewer dismisses in a second beats silence, in a feature whose entire promise is that nothing changes unseen.
The review this builds on already works.
Upload an agreement before you sign it and you get a verdict, a risk score, every deadline, and the prioritized list of changes worth asking for — each with a fallback position. That list is what Redline Review will check their draft against.
Not available yet. No card, no commitment, unsubscribe in a click.
Straight answers.
Is this available today?
Not yet. The engine that finds every changed region between two versions is built and tested against real filed contracts; the customer-facing part — uploading their draft, getting the report — is not wired up. Joining the list gets you an email when it opens.
How is this different from a track-changes diff?
A track-changes view only works when the other side leaves track-changes on, and it tells you what moved, not what it means. Sidecar compares two documents that have been through different systems entirely, then explains each change in terms of your position — whether it answers something you asked for, and what it costs you if you sign it.
Could it miss something?
The finding is done by code, not by a language model, and that is a deliberate design choice. A model asked to compare two forty-page contracts writes a fluent summary and can silently leave out the one-word edit that matters. Sidecar's comparison identifies every changed region first and then asks the model only to explain regions it has been handed — so a region can be poorly explained, but not omitted.
Does the vendor see any of this?
No. Your fallback positions — what you would settle for — never appear in anything addressed to a counterparty. Sidecar drafts what you send; you send it.
Is this legal advice?
No. Sidecar is business decision support, not a law firm, and no attorney-client privilege attaches to what you upload. Reviews come with a packet built to forward straight to your attorney, and for final contract language that is exactly what it is for.