The duplication
solveSymmetric in src/core/calibration.cpp is a second Cholesky implementation alongside the one in src/core/kinematics.cpp.
Why this duplication was accepted
ADR-0011 treats this as an acceptable duplication.
Cholesky factorisation is a textbook algorithm rather than an arbitrary convention.
Two independent implementations therefore cannot disagree about a convention that callers would need to reconcile.
This is different from something like a coordinate-frame convention.
Frame conventions are arbitrary and must be single-sourced because two spellings can silently represent different semantics.
A textbook numerical algorithm does not have that same ambiguity.
What would change the decision
A third caller.
Forward dynamics would be such a caller.
At that point, the argument changes:
Two independent textbook implementations can be defended.
Three copies become a maintenance surface.
If forward dynamics is implemented, the Cholesky solver should be factored into shared code as part of the same change rather than as a later cleanup.
Suggested handling
Leave this issue open as known tech debt.
Do not refactor the two existing implementations solely to remove duplication.
The current state is explicitly defended in an ADR, and changing it today would create churn without providing a concrete benefit.
Revisit this when a third caller appears.
References
docs/adr/0011-calibration-refuses-what-it-cannot-determine.md
The duplication
solveSymmetricinsrc/core/calibration.cppis a second Cholesky implementation alongside the one insrc/core/kinematics.cpp.Why this duplication was accepted
ADR-0011 treats this as an acceptable duplication.
Cholesky factorisation is a textbook algorithm rather than an arbitrary convention.
Two independent implementations therefore cannot disagree about a convention that callers would need to reconcile.
This is different from something like a coordinate-frame convention.
Frame conventions are arbitrary and must be single-sourced because two spellings can silently represent different semantics.
A textbook numerical algorithm does not have that same ambiguity.
What would change the decision
A third caller.
Forward dynamics would be such a caller.
At that point, the argument changes:
Two independent textbook implementations can be defended.
Three copies become a maintenance surface.
If forward dynamics is implemented, the Cholesky solver should be factored into shared code as part of the same change rather than as a later cleanup.
Suggested handling
Leave this issue open as known tech debt.
Do not refactor the two existing implementations solely to remove duplication.
The current state is explicitly defended in an ADR, and changing it today would create churn without providing a concrete benefit.
Revisit this when a third caller appears.
References
docs/adr/0011-calibration-refuses-what-it-cannot-determine.md