Okay, I understand the analogy. You imagine a world where there would be a "standard contract" that could be referenced by its name, just like the MIT license can be referenced by its name without having to read it every time. Would that be nice? Sure. But we didn't create anything like that. Our contract-generator can output many different kinds of contracts depending on the inputs. This was a design choice that we made early on: we wanted to support many different kinds of needs, as opposed to just creating a singular one-size-fits-all contract template. The whole point of having a web generator for the contract is that it gives you easy access to tweak all the different clauses. If it was just a one-size-fits-all contract template, why would there be any "generator" in the first place? So... I'm back wondering what it is you're asking me to do exactly.
This:
> Consider having some kind of version information, such as a date (more human readable) git commit id (unambiguous), or just 1.0.0.
Remember, the point is to make it easy for people who are familiar with the generator.
So, suppose you have 2 different contracts. One is extremely favorable to the freelancer, whereas the other one is extremely favorable to the client. And they both have the same git commit id. What does the git commit id help in this situation? What would somebody gain from seeing it?