The Guidelines:

• Guideline: Appreciate the significance of the semantic contract.
• Guideline: Keep methods, objects, and packages focused.
• Guideline: Strive for interfaces that are minimal and complete.
• Guideline: Simplify, simplify, simplify.
• Guideline: Make the semantic contract as explicit as possible.
• Guideline: Make sure subtypes fulfill the semantic contracts of their supertypes.
• Guideline: Avoid optional clauses in semantic contracts.
• Guideline: Use deprecation, not a broken contract, if you have designer's regret.

Could mention that I didn't specify the details of the hashcode method algorithm in class Matrix, because I wasn't sure I was using a good algorithm and wanted to be able to change it later. If I did eventually decide, I could specify the exact algorithm in the javadoc, as is done for String, Boolean, Long, Double, Integer, and so on. Perhaps this goes in Packages and Evolution, in a discussion of how contracts do in practice get changed, or at least clarified, in future releases, and that you just consider how many clients will in practice have their code broken. If the pain will be slight in comparison to the gain (if the ends justify the means), in the real world you make those kinds of semantic contract changes.