What changed in Law Hired—and what the change actually means
A useful changelog distinguishes code, deployment, configuration, and verified production behavior. This page establishes that publication standard; dated release entries should be generated from deployed releases, not aspirations.
How it works
Added
New user-visible capability, with audience and availability stated.
Changed
Behavior, pricing, policy, or workflow changes that affect how customers operate.
Fixed
Production defects that were reproduced, corrected, and verified.
Readiness notes
Credentials, migrations, pilots, or external dependencies still required before a capability is treated as generally available.
What you can hold us to
Roadmap items are not release notes
Code presence is not deployment proof
Corrected claims remain in the historical record
Security-sensitive fixes are disclosed responsibly
Questions firms ask
Why are there no invented historical releases?
Release history should be reconstructed from deployment evidence, not commit volume or marketing memory.
Does every commit appear here?
No. The changelog focuses on customer-visible and operationally meaningful changes.
How can customers request detail?
Contact support for implementation-specific impact and migration guidance.