RC_TPI = 0.2 waives the resource-constraint check at every period, not just the terminal one

[vahid-ahmadi]

Summary

_build_specs sets p.RC_TPI = 0.2:

https://github.com/PSLmodels/OG-UK/blob/main/oguk/api.py#L979-L983

The accompanying comment is explicit that only the terminal period is at fault and that "all other periods are well within 1e-4". But RC_TPI is a single scalar compared against the whole error path with np.any in OG-Core:

# ogcore/TPI.py:1839
if (np.any(np.absolute(RC_error) >= p.RC_TPI)) and ENFORCE_SOLUTION_CHECKS:
    raise RuntimeError("Transition path equlibrium not found (RC_error)")

so setting it to 0.2 to accommodate t = T-1 also waives resource-constraint violations of up to 0.2 at every interior period. The originally failing terminal error was ~0.109, i.e. the same order as violations that would now pass silently mid-path.

This sits in the default path for every run_transition_path call, so a transition that has genuinely gone wrong in the interior returns numbers rather than raising.

Upstream dependency

OG-Core currently has no way to express "exempt the terminal period only" — I've filed PSLmodels/OG-Core#1210 proposing a period-indexed check (RC_error[:-1] against a tight tolerance, terminal period handled separately).

Suggested change here

Two options, depending on how #1210 lands:

1. Once OG-Core supports a separate terminal tolerance, drop RC_TPI = 0.2 and set the terminal parameter instead, restoring a tight interior check.
2. In the meantime, keep the loose RC_TPI for the solver but add an explicit post-solve assertion in run_transition_path that max(|RC_error[:-1]|) is within ~1e-4, so an interior failure surfaces rather than passing.

Option 2 is available without waiting on upstream and without lifting the ogcore<0.18 cap.

[vahid-ahmadi]

One thing that strengthens this and that I missed originally: RC_TPI carries a paramtools validator of range: {min: 1e-13, max: 0.01} (ogcore/default_parameters.json, default 1e-4).

0.2 is 20x the maximum the parameter schema permits. It only takes effect because _build_specs sets it by direct attribute assignment after update_specifications — going through the supported API would reject it outright.

So this isn't only a loose tolerance, it's a value outside the parameter's declared contract that bypasses validation. That makes option 2 in the description — keeping the check tight on the interior of the path and treating the terminal period separately — the better fix rather than merely a stopgap, since there's no in-contract value of RC_TPI that accommodates the terminal artifact.