Requirement Realization Rate
The share of what a product manager planned that ships as it was intended. Some of the loss is healthy, because discovery invalidates assumptions. The rest is translation cost, and it has been treated as a fixed cost of the job for about twenty years.
Teams measure velocity, cycle time, and throughput, all of which describe how fast work moved once it was already defined. None of them notice a requirement that arrived at production meaning something other than what it meant in the spec. That failure looks like delivery on every dashboard you already have.
The rate splits into two parts, and keeping them separate is the whole point. Some of what you planned should not ship, because discovery invalidated the assumption behind it or a priority moved for a good reason. That loss is the system working. The rest is translation cost: the constraint nobody wrote down, the architectural fact that only surfaced in the estimate, the ambiguous sentence that got read the other way. That loss is not a fact of the job, it is a fact of the process, and it responds to being looked at.
The reason to name it is that it changes what a post-mortem asks. Not why were we late, but which of these did we decide against and which did we simply lose.