Ask a design team what the aircraft's endurance is and you will get a number from an analysis. Ask the operations team and you will get a different number, from experience. Both are right, nobody reconciles them, and the gap between them is where a great deal of money goes.
Two populations, two toolsets
Design tools model an aircraft that does not exist yet. They are precise about geometry, mass and predicted performance, and they stop caring the moment the design is frozen.
Operations tools manage aircraft that do exist. They are precise about hours, cycles, defects and crews, and they have no idea what the design intended. To a fleet system, an airframe is a serial number with a maintenance schedule attached.
Between them sits a seam that almost no organisation crosses. The design team learns how their aircraft actually performs through anecdote, if at all. The operations team sets limits by observing behaviour rather than by reading the analysis.
What falls into the gap
Several specific things, all expensive.
Validation of the model. A sizing analysis predicted an endurance. Hundreds of flights later, nobody has systematically compared prediction against outcome, so the next design starts from the same unvalidated assumptions.
Operational limits. Exceedance thresholds get set from fleet behaviour rather than the design envelope, so they encode what has been survived instead of what was designed for.
Configuration truth. The aircraft as designed and the aircraft as maintained diverge steadily: a replacement component with a slightly different mass, a payload change, a firmware revision. Six months on, the flying aircraft is not the one that was analysed, and no document records the difference.
Feedback into the next programme. The most valuable output of operating an aircraft is knowing where the design was wrong. That knowledge lives in the heads of the people who flew it.
Why the seam persists
Not because anyone thinks it is fine. It persists because the two toolsets are bought by different budgets, chosen by different people, and integrated by nobody. Each is individually reasonable, and integration is somebody's project that never quite starts.
The usual attempt is an export: design produces a document, operations reads it once, and it is stale within a month. A document is a snapshot of a relationship that keeps changing.
A shared definition, not an interface
The alternative is for both sides to reference the same airframe definition rather than exchanging copies of it. When the definition is shared, a geometry change flags the load cases it invalidates. Exceedance limits derive from the design envelope automatically. Actual performance is compared against prediction as a matter of course, because both live in the same place.
None of this is conceptually difficult. It is unusual mainly because the tools grew up on opposite sides of a boundary that nobody designed and everybody inherited.