Semantic Completeness for Correct Maintenance: A Strict Hierarchy of Typing and Inheritance

Correct maintenance keeps required answers, excludes invalid states, and minimizes separately supplied answers and repair obligations across updates. A semantically complete mechanism derives every identity, membership, and implementation answer for every finite declared relation. Banning semantic completeness makes correct maintenance formally impossible. We give exact minima for answers that incompleteness leaves to code or tooling.

Same-looking meanings needing different answers need stable keys; graph coloring gives the fewest key values. Contract membership supplies no code. One contract parent handles tree-shaped membership; multiple parents handle every finite map.

For distinct, independently changing implementations, the ancestry gap is the fewest required implementation-class connections outside one provider chain per class. It is zero exactly when the implementations' class groups fit a tree. No correct repair with sound ancestry (supplying only required pairs) beats this bound, even with reparenting, infinite helpers, arbitrary delegation, or generators.

In a constructed history that fits a tree at every snapshot, multiple parents meet the one-operation floor at every step; one parent incurs an additional repair obligation at every step. Batching changes how obligations are met, not their minimum.

Across 20 pinned Python projects, code or tooling supplies all 12,880 source-class connections without implementation inheritance; multiple parents supply them all. Declared first parents leave 8,792 outside; the best sound one-parent hierarchy leaves 739, certified exact. After excluding order-sensitive lookups, a SQLAlchemy component has gap 520 with no lookup conflict. Lean 4 checks proofs and bounds; replay checks repairs. Source extraction remains external.