The contract will most likely be done and dev are not normally involved and it'll be written after the process of the software being made. I don't think in 16 years I've ever gone through a legal contract and translated that into a technical requirement.
It's normally done the other way round that some requirement is translated into legalese. Reading legal documents is not a skill I would expect of any developer and I would be extremely wary of building software using this technique. Reading contracts requires many years of training that almost all developers do not have. Also note that laws are not universal and different jurisdictions will often allow different interpretations. An example of this is USA vs UK law, they are quite different and so if you are trying to interpret a USA contract as some from the UK you'll probably need a lawyer from the US on hand to help explain what they mean by certain terms. Without this training it can be very easy to misinterpret what is actually being said in a legal document. I'd also say that as a dev/po/pm/qa or basically anyone involved in the actual development it's not in my job description to be able to read legal documents so I'd be quite within my rights to refuse to do this work.
The point I made which you seem to be ignoring is that from the original Agile Manifesto:
"Working software over comprehensive documentation"
So you don't write a spec document up front but discover the requirements as you progress through the project. I suspect for Amazon this is exactly what they are doing there is no "spec document" and there was no contract but as they progressed through the project they just built a overly simplistic approach to the Royalty calc. Afterwards they got a contract written and the lawyer either wasn't told what the software actually done or just wrote what was the standard industry contract for Royalties.
Please Note: I'm not advocating for Agile vs any other technique but I was responding to the comment that you should just read a spec and code that directly into code that's just not the way you do things in an Agile environment.